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.
Maybe the OP should clarify what he's actually wanting to do.
The 2-nd level bootloader would not normally require IAP functionality, though I cannot think of any reason why there would be a problem with it specific to it being done within the bootloader.
There is nothing magical or different about this 2-nd level bootloader - It is simply a normal application that would (at it's conclusion) execute another application.
He mentioned earlier:
"the value at address 0x08000004 immediately becomes "0xE000032F"
With the Keil bootloader source code, that address would be part of the vector table image (which can be mirrored at 0x00000004) so I would be surprised to see a variable exist at that location.
As I suggested before, single stepping through the startup code would be a sensible thing to do.
It is simply a normal application that would (at it's conclusion) execute another application.
Let's not forget remapping of interrupt vectors...
Sorry, but I'm not sure what you're saying there.
The bootloader can update the interrupt vectors to be used during the bootstrap which can then be updated again by the subsequent application.
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.
You're talking in too simplistic a manner.
Speaking of which, you're contradicting yourself stating:
I'm not saying this would always be the best solution,
since that's quite exactly what you did say before when you replied "Nor do I" to Mr. Karas' statement that he "never uses static initializers".
You'll have to forgive me for simplistically assuming you actually meant what you said.
"You'll have to forgive me for simplistically assuming you actually meant what you said."
I said that I never use static initialisers.
I said that it gives me what I need.
I said that it would not always be the best solution.
Surely you can see the implication that it may not always be the best solution for other situations for other people.
No contradiction there.
What I said is what I meant.
I have also tried to be accurate when responding to the original problem posted by the OP - I'll refrain from passing comment on your first post regarding the matter!
I found something like this in www.phytec.com/.../TN-021e_3(KPCM-040-Keil).pdf. Maybe this is the reason for this problem.
It says do not build the bootloaders using he evaluation version of uVision. But, I am using it.
Problem Description: The KEIL ARM Evaluation Software contains bootloader projects for NAND and NOR Flash memory (Bootloader_NAND.Uv2 and Bootloader_NOR.Uv2). Although there should be no need to re-build the provided Bootloaders, these Bootloader projects cannot be built with the Keil Evaluation version tools. If projects are built with the Keil Evaluation Software this could override functioning Bootloader .axf files. Workaround: Do not attempt to build the Bootloader projects with Keil Evaluation Software. In the event that Bootloaders are corrupted, download the Bootloaders from: www.phytec.com/.../3250_KEIL_Bl.zip
So what did you expect?!
It would have been so much better if you had mentioned the little detail of you using evaluation software at the start.
Sorry but I did not think using the eval version would ever cause such a thing. Therefore I did not mention. I hope the problem gets fixed when the full version is used.
As said before, I have successfully modified, compiled and executed the bootloaders - And there was no drama.
You really should not find any problems.