Hello.
I'm using µVision 5.27.1.0 with the default compiler (I assume MDK-ARM) on an LPC4078 project.
I would use one of the RTC GPREGs if only the VBAT pin was connected in the hardware. (Used to do it that way but the hardware changed. Variable name stayed.)
I'm afraid updating µVision is not an option I can choose.
I have modified my scatter file to contain:
RW_RAM1 0x20007FF0 UNINIT 0x00000010 { ; noinit data *(.bss.noinit)}
RW_RAM1 0x20007FF0 UNINIT 0x00000010 { ; noinit data
*(.bss.noinit)
}
And I place it in code with:
__attribute__ ((section (".bss.noinit"))) U_INT lpcRestartModeRegister;
According to the map file the variable is placed just where I want it:
lpcRestartModeRegister 0x20007ff0 Data 2 main.o(.bss.noinit)
So everything seems fine. But the variable is zero after a watchdog reset.
I have found https://community.arm.com/support-forums/f/keil-forum/54408/uninit-section-gets-zero-filled and tried to set an access areakpoint on the variable in the watch window as suggested but in the Command Window I get:
BS \\ic2Fe1p\main.c\lpcRestartModeRegister, 1*** error 129: target does not support conditional breakpoints
BS \\ic2Fe1p\main.c\lpcRestartModeRegister, 1
*** error 129: target does not support conditional breakpoints
What else can I try?
Thank you.
Garry
You are trying to create a variable to pass information that survives C startup? This has been discussed a few times and I don't remember all the solutions. One that I did use at one time was to use a variable that was clear of the stack, heap and global variables area. Probably you can figure out such an area in SRAM. Then you can name and access that RAM:
static volatile uint16_t MailBox __attribute__ ((at(0x20004FFEUL))); // Compiler v5 //static volatile uint16_t MailBox __attribute__ ((section(".ARM.__at_0x20004FFEUL"))); // Compiler v5 or v6
Hello, the solution in the other thread was that there was in fact something in the users code initializing the variable, and so nothing to do with scatterloading. You say the value is zero after the watchdog reset - can you verify that it is non-zero when the application first reaches main(), by which time scatterloading has been complete.
If scatterloading is the culprit, I see you are using an older MDK, so you may well be building with the older Arm Compiler 5 (armcc). Can you add the compiler option --bss_threshold=0 to see if that fixes the problem (though I am still concerned if the UNINIT qualifier is not being honored.https://developer.arm.com/documentation/dui0472/m/Compiler-Command-line-Options/--bss-threshold-num