STM32H7 RAMECC failing address register (FAR)

[rammit]

Is the failing address register (FAR) of the RAMECC monitor an absolute or relative address?. In other words, for SRAM3 for example would FAR contain 0x3004xxxx or 0x0000xxxx?

[waclawek.jan]

I don't know, but it should be fairly easy to check, just try to read an uninitialized RAM position.

JW

[rammit]

True. Did that but didn't trust it because the data register FDRL did not match the data at either 0x00001072 or 0x30041072. Perhaps it was overwritten by the time the debugger viewed it. Seems to be a relative address.

[waclawek.jan]

rammit,

the 'H743 doesn't appear to contain this feature. Which 'H7 are you talking about, exactly?

@Imen DAHMEN,​  Can this please be clarified?

Thanks,

Jan

[Imen.D]

Hello @rammit​ , @Community member​ ,

Thanks @Community member​ for bringing this post to my attention, and sorry for the delayed reply on this.

@rammit​ , some of assumptions made are correct, the address is relative and it’s counted by words.

In fact, it is not clear why you see this behavior of wrong address, but CPU and debugger are reading the memory.

Perhaps, you could try clearing the registers after each incident to see if that helps.

Some uncertainty about address is reportedly related to unaligned memory access. Please check this point, is the access aligned to word width?

I agree that the RM should be more specific and clearer in the register description.

I escalated this request to involved people to take a closer look at the problem.

I'll make sure to post any updates here as soon as I hear back from them.

Imen

[rammit]

I'm using the H743. See section 3 of RM0433. Seems to work. Although, I'm currently getting an ECC double error in ECC monitor RAMECC1_Monitor4 (periph address 0x52009080, memory address is DTCM1 0x20010000 ) at FAR address of 1 on startup after initializing the RAM.

[waclawek.jan]

I'm not using the H7, and this section is entirely new in rev7 of RM0433, not a single mention of it in rev6...

JW

[rammit]

One more strange thing, when the debugger stops at a breakpoint it seems to trigger a single-error interrupt at that same address 0x20010001. If I have no breakpoints I only get the one double error.

I am enabling the following ECC monitors and their respective RAM start addresses:

RAMECC1_Monitor1, 0x24000000,

RAMECC1_Monitor2, 0x00000000,

RAMECC1_Monitor3, 0x20000000,

RAMECC1_Monitor4, 0x20010000,

RAMECC2_Monitor1, 0x30000000,

RAMECC2_Monitor2, 0x30010000,

RAMECC2_Monitor3, 0x30020000,

RAMECC2_Monitor4, 0x30030000,

RAMECC2_Monitor5, 0x30040000,

-Dave

[rammit]

Here is some more info. The FDRL register Of the DTCM1 monitor is shown below.

But the matching data is in DTCM0 which I have not enabled monitoring on.

DTCM1 does not contain the matching data.

-Dave

[rammit]

Looks like my copy & pasted images were removed. Trying again. Didn't notice the big red pop-up warning message about pasting images.