We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I am using Phytec LPC3250 board for my design and I have a very important problem that I have been spending time on for days.
I want to modify my bootloader_NOR code so that I can send my application code image from the serial port.
However, when I define a global variable and use this variable in a function it gets wierd values. My code can be simplified as below:
#include "LPC318x.H" int m = 0; void MyFunction(int value) // do nothing function { } int main(void) { for(;;) { m++; // <- Breakpoint MyFunction(m); } }
When I debug the code, I see "m = 0xE0000420" at the breakpoint where I expect to see 0x00.
This ruins all my intention and I cannot proceed to modify the code.
I think the data in the RAM region is corrupted but I dont know why and I have no sensible solution for this.
Thanks for your helps in advance.
Are you using the 'standard as supplied' bootstrap code as your example?
Have you tried disabling ALL optimizations?
Have you tried making your 'm' variable volatile?
I have previously modified the 2nd level boot loader by putting serial debug facilities in. The one thing I had to do for it to work successfully was to increase the size of the USR stack.
Thanks for your reply.
Yes, I am using the standard bootstrap code. I have no optimization in the project options. And yes, I tried volatile for m.
The problem is that the memory region is corrupted as soon as the bootloader program starts running. For example, the value at address 0x08000004 immediately becomes "0xE000032F". If my variable is located at that address then my variable is gone forever.
The more important thing is that, I cannot get serial data. because in order to get the serial data I have to read memory. And as it is corrupted, I get nonsense values. I send 10 from the PC and get 85 at the mcu.
The memory regions should be changed maybe I dont know. I terribly need help.
Thanks.
What I suggest you do is single step through the startup code, watching the memory location of the variable becoming corrupt and see where that corruption occurs.
In the standard startup code, it jumps to main with the sequence:
LDR R0, =__main BX R0
Select the dis-assembly window and single step there. Then I would expect you to enter the scatter load code.
It's a while since I modified my bootstrap, but I seem to remember that doing this brought me to the conclusion that the stack was originally only just sufficient for the unmodified bootstrap code. My first small additions took it over the edge.
What exactly did you expect to happen? The bootloader, once called, owns the entire CPU, including all the RAM. It has to. And yes, that means you can not rely on any RAM contents being untouched after the bootloader has run unless the documentation of the bootloader explicitly stated that it's going to leave certain locations unmodified. Does this bootloader make that kind of promise about that particular memory region?
I have assumed the OP is talking about the 2-nd level bootloader and he is modifying that.
If those assumptions are correct then he can rely on the contents of RAM since his application is the bootloader - So long as they are within the bounds and knowledge of his modified bootloader.