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.
What I actually want to do is to send the application image to the 2nd level bootloader through the serial interface and then write the code to the SDRAM and start executing it. The second thing will be writing the image to the flash.
In the project options, the RAM start address seems to be "0x08000000" and the length seems to be "0x40000". My global variables start being located at 0x08000000 addresses (0x08000004, 0x08000008, etc). But, this region is suddenly spoiled with irrelevant data such as "0xE000032F".
Not only this memory region, but also the serial receive buffer memory contents are spoilt. So, when I try the serial communication the code realises that data comes but when it reads the data it does not read correctly.
Although I change the RAM regions to different places, I have the same thing.
Normally this very simple piece of code runs perfectly well in the application but when it is implemented in the bootloader suddenly everything is ruined.
Thanks for your helps.
It kind of funny; I just did the very same for a LPC2468/78 (in addition to the USB bootloader - we have two!), soon will start porting the code to a LPC1768. I'll drop a line if I come up with something...
I'm starting to feel that you're taunting me :(
What you need to determine is where and when exactly the memory is becoming corrupt. I would suspect that it is prior to entry to main, probably during the scatter load.
An easy way to do that would be to plug your ULINK (or equivalent) into the Phytec and start debugging.
I no longer have access to the Phytec board and our board only has NAND for boot, but when I did implement my additions on that I did have it working on NOR - And I still have it working on NAND.
As I mentioned before, my modifications required me to increase the USR stack - Have you considered trying this?
Many of the ARM chips have support for remapping of the interrupt vector table. Many of these ARM chips are using the first bytes of RAM. So the first bytes (for example 64 bytes) may be replaced by bootloader/startup code to allow an application in RAM or at the wrong location in flash to still contain an interrupt vector table.
If the start of your RAM suddenly seems to hold something that looks like pointers into a RAM or flash memory region, then you really have to consider if this is an interrupt table you are seeing. The ARM core expects the interrupt table to be at a fixed location, but external hardware can perform remappings so that a part of the RAM can "move" and overlap the interrupt vector table at the normal place in flash. The ARM core will not be able to notice this, and will hence be able to handle interrupts even if the interrupt handlers was developed, downloaded and registered long after the flash got it's final contents.
The normal way for a bootloader/startup code is to copy the interrupt vectors stored at the start of an application into the first part of RAM. As soon as the RAM has been initialized with the vectors, a special register is then updated to remap this RAM so it will be visible instead of the flash interrupt vector table.
An application developed for standalone use don't need to do anything special. An application developed for use with a boot loader needs to make sure that it stays away from the RAM used for the duplicated interrupt vector table. If the project specifies the use of all bytes of RAM, you will get overwritten variables. The datasheet/user manual for the chip will tell if it's the first or last bytes of the RAM that are needed for the interrupt-vector copy. Note that there may exist ARM chips that can remap an address area directly from flash instead of requiring a remap of a fixed-address RAM region. In that case, no RAM must be reserved.