memcpy causes NMI fault in H563

[Justin3]

I’m currently debugging an H563 NMI issue. When I execute

memcpy((uint8_t*)record, (uint8_t*)latest_record_addr, 128), the program jumps to the NMI_Handler().

I have already confirmed using the debugger that record = 0x20002608 and latest_record_addr = 0x81ED000, and both are valid addresses. After execution, I observed that the first 16 bytes were correctly copied to the corresponding address, but for unknown reasons, the program jumps to NMI_Handler().

I set a breakpoint in the assembly code of memcpy() and found that the program jumps to NMI_Handler() after executing the cmp r1, r2 instruction. I also confirmed that r1 = 0x81ED011 and r2 = 0x81ED080, both of which are valid addresses.

   

After executing cmp r1, r2, the program counter will point to 0xFFFFFFA8, and then jump to NMI_Handler().

The first 16 bytes of memory were successfully written.

Has anyone encountered this issue with the H563? Any clues or solutions?
I would greatly appreciate it!

[SofLit]

I don't see you are reading from OTP / RO regions:

See this article. But check in any case.

[TDK]

Let's be objective here: the chance of a bug in the memcpy code is nil. So it has to be caused by that only indirectly.

Did you write to the same flash location multiple times without erasing? That could be trigger an ECC error and produce the behavior you describe.

[Tesla DeLorean]

Or a line that's partially written