Max10 RSU post config status

I have a similar query and observations that the documentation for the Remote System Upgrade registers makes no sense.

Even the answer above that Tables 11, 12, and 13 somehow should make sense of these registers seems to be incorrect.

For example Table 11:

From observation it would seem that this is wrong since the only bits in register 1 that seem to be active are [1:0] and these seem to map into ru_boot_sel (bit 0) and ru_boot_sel_overwrite (bit 1). Moreover, that register is clearly not "Read Only" as but in fact RW. This seems to be an arbitrary mapping unrelated to this table.

For Table 12 (supposedly for offset 4):

I seem to only read back values of 0x00004FFF or 0x00008FFF. My design does not have the watch-dog enabled so I would expect that ru_wd_en is always zero. I would also expect that wd_timeout_value would be maximum and not changing. Now clearly the Avalon-MM register is only 32-bits wide so what we are supposed to interpret from a 34-bit wide table is beyond me. Based on the evident bit patterns I would have to guess that the actual register has some other mapping. The bits [31:16] seem to always be zero and the bits [15:0] do not seem to make sense since the only bits that should really change in my design might be the msm_cs bits and those are not seemingly in the right place.

For Table 13 (offsets 5 & 6):

I get a variety of values depending on the validity of CFM1/CFM0 and how the device was triggered to configure but these values are always non-zero bits in the LSB (e.g. [7:0]) like 0x00000028 or 0x00000058 or 0x00000044 etc. How those map into Table 13 is a mystery to me. I have yet to reverse engineer what the mapping might be.

So frankly I don't know how you could possibly think that

> the query has been answered

since as best I can tell, this is equally confusing and wrong. Is there some special bit ordering that is not evident? Does the document specify bits in some strange way such that perhaps the Most Significant Bit is 0 and the Least Significant Bit is 31 (or 33 or ???)

There is no driver header file to make sense of this.

There is no sample that demonstrates the interpretation of these bits.

The documentation is a complete falsehood.

How can anyone be expected to make any sense of this?

OP: Did you actually find an answer in this that allowed you to interpret the values in the status registers and figure out the state of the RU logic?