cancel
Showing results for 
Search instead for 
Did you mean: 

RAM parity function on the STM32G071RB breaks code execution? In short: When i clear the RAM_PARITY_CHECK bit in the option bytes (FLASH_OPTR bit 22), the program (in flash) will not run. Is this a hardware bug or am i doing something wrong?

EScho.2
Associate

I'm working on the NUCLEO-G071RB development board, using the IAR-EWARM (8.50.9) tool-chain.

I've created a very basic program that only toggles user led (LD4) at 500ms intervals (using a wait loop with NOP instructions).

The program doesn't use RAM (however it is initialized by the start-up code from IAR).

With the RAM_PARITY_CHECK option bit set, the program runs as expected and the led blinks every 500ms.

When i clear the RAM_PARITY_CHECK option bit (using STM32CubeProgrammer) the program doesn't run,

and the debug environment of IAR points to address 0xFFFFFFE when i halt the processor.

When the RAM_PARITY_CHECK option bit is restored (set) again, the program again executes as expected.

What can be the cause of this strange behavior?

1 ACCEPTED SOLUTION

Accepted Solutions
Andreas Bolsch
Lead II

You did take into account that RAM size changes when toggling the RAM_PARITY_CHECK bit??? Typically, stack pointer is initialized to point to end of RAM. When RAM size shrinks ... So the linker script has to be adjusted accordingly.

View solution in original post

5 REPLIES 5

Single-step the code in disasm view, starting at the reset vector, to find out the instruction which reads uninitialized RAM to cause the parity error.

JW

I'd expect you'd need code very early in Reset_Handler to clear all of RAM without reading it, or using the stack, ie no subroutines.

Perhaps ST has an App note, or examples, or explains expectations in the RM?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Andreas Bolsch
Lead II

You did take into account that RAM size changes when toggling the RAM_PARITY_CHECK bit??? Typically, stack pointer is initialized to point to end of RAM. When RAM size shrinks ... So the linker script has to be adjusted accordingly.

Wow.

EScho.2
Associate

Thank you all for replying!

@Andreas Bolsch​ was right, the stack pointer (loaded from the interrupt vector) pointed to the end of the maximum RAM size (and therefore invalid memory with the parity option enabled). This also explains why the debugger could not make sense of it all.

I did (attempt) to account for this but there was an error in the linker script which always allocated the maximum RAM, and i forgot to check the initial stack pointer value :S (feeling a bit stupid now). Anyway thanks for the reminder!