SRAM data is lost after soft boot
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 12:12 AM
Hi,
I have a problem with the SRAM. I use a stm32f303CCT and Keil. I write a value in the SRAM memory. (0x20000000 - 0x20000008) However, after a soft reset, the SRAM value will be deleted. How can this be prevented so that the data is preserved?
The data is stored as shown in the image below.
After soft reset the SRAM is deleted.
What do I need to change in the Patter File or the startup File so that the data is not lost?
Thank you for help
- Labels:
-
STM32Cube MCU Packages
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 5:43 AM
Global variables are initialized to 0 by default at the start of the program. You can carve out a ram section and mark it as NOLOAD if you don't want that to take place.
https://mcuoneclipse.com/2014/04/19/gnu-linker-can-you-not-initialize-my-variable/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 5:54 AM
Doesn't Keil use NOINIT not UNINIT
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 6:56 AM
In the "Options for Target" there is a box "NoInit" and Keil generates the UNINIT in the scatter file.
The line with UNINT should actually work, but the RAM memory area is always deleted after the software RESET.
The link https://mcuoneclipse.com/2014/04/19/gnu-linker-can-you-not-initialize-my-variable/ is only suitable, if you use the stm32CubeIDE program. At Keil the scatter file has a different syntax.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 7:10 AM - edited ‎2023-12-06 11:20 AM
Please set a breakpoint on the reset handler in the asm startup and look at the SRAM at that point. If the data is already lost, it is something hardware (power loss). Else it is software (initialization of this area still runs somehow).
-- Addition--
If the data is lost at this point, it can be also artifact of the debugger. Just because debuggers can do this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 10:19 AM - edited ‎2023-12-06 10:27 AM
What is "soft reset"? OK I see in screenshot, some HAL function, presumably just calling the standard CMSIS software reset function.
What hardware is tied to NRST pin?
Sorry, this is all nonsense. Just have a look at disasm of the startup code (reset handler) and/or do what Pavel A. suggested above.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-06 10:46 AM
The __main called in startup.s is what calls the scatterload function, and subsequently user's main() function.
Would suggest unpacking the initialization tables, might need to review .MAP, and disassemble .AXF via
FROMELF -csd foo.axf >foo.lst
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-12-07 12:59 AM
Thanks for your help. I solved my problem using the following link
https://developer.arm.com/documentation/ka003046/latest
I made the declarations like in Compiler 5, but I have Complier 6. So the declaration must look like this:
// Arm Compiler 5
// Arm Compiler 6
