Skip to main content
EScho.2
Associate
May 18, 2021
Solved

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?

  • May 18, 2021
  • 4 replies
  • 1326 views

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?

This topic has been closed for replies.
Best answer by Andreas Bolsch

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.

4 replies

waclawek.jan
Super User
May 18, 2021

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

Tesla DeLorean
Guru
May 18, 2021

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 VenmoUp vote any posts that you find helpful, it shows what's working..
Andreas Bolsch
Andreas BolschBest answer
Lead III
May 18, 2021

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.

waclawek.jan
Super User
May 19, 2021

Wow.

EScho.2
EScho.2Author
Associate
May 19, 2021

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!