Flash Memory access when >512k

[TheRaprus]

Hi to everybody.

I'm struggling to figure out this issue: I got a "NMI_Handler" error...

uint32_t *p = (uint32_t*)0x08080000UL;
uint32_t val = *p;  //here jump to NMI_Handler

If I put the addr to 0x08070000UL (e.g.) no probelm.

I'm using a STM32H562RGTX with 1MB of flash. I know that a 2MB need a back swtich... But why in 1MB?
How I can handle this?

Thanks in advance.

[Tesla DeLorean · Accepted solution]

Make sure the Flash has valid content written to it. Blank memory may fault due to lack of valid ECC data.

Not sure if this a feature that can be turned off.

[TheRaprus]

Thanks Tesla DL.

I tried with full chip erase, then execute again the test, and now it work wo NMI interrupt. So you're right.

Now the question should be: How I can detect if the flash (in any point) is not corrupted? Because tn that case the only way is reset the uC in the nmi ISR and handle it.

[Pavel A.]

@TheRaprus Your question is equivalent to this: if/when the program detects the flash corruption, what can it do, besides of endlessly restarting or shutting down?

[STOne-32]

Dear @TheRaprus , @Tesla DeLorean ,

This NMI protection is thanks to our Flash ECC that as it detects a non Written Memory and so ECC is not initialized . So it protects the CPU to jump to non valid Address , such is EMC etc.

Hope it helps you .

ST1 

[Tesla DeLorean]

It could output an error, perhaps indicating the address or current registers, advance the PC address on the stack frame, and return.

[TheRaprus]

@Pavel A. @STOne-32 @Tesla DeLorean 

Yep! The situation is in a custom bootloader (I'm doing a porting from a M4 solution).

If the bootloader check the CRC32's application in flash it simply remain in bootloader and don't jump. What Is necessary is doing the same thing with ECC. There is also a bitmap image to display, and this can open different perspective.

In my code I'm using the function
"HAL_StatusTypeDef HAL_FLASH_Program(uint32_t TypeProgram, uint32_t FlashAddress, uint32_t DataAddress)"
where DataAddress "shall be 32-bit aligned". I'm not checking it, and this is probably the cause.

I'll keep this issue open, and in the next days I want use this mistake to find a solution - starting from TeslaDL's last post - And I'll write here (if any :grinning_face_with_sweat:)

Thanks for help!

[Pavel A.]

> where DataAddress "shall be 32-bit aligned".  I'm not checking it, and this is probably the cause

This is unlikely if the source data is in "normal" or cached memory. CM33 can load from unaligned address. The flash address must be aligned.  Anyway, unaligned access should not cause NMI.