This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Wierd problem in modifying the bootloader code

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.

Parents
  • 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.

Reply
  • 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.

Children
No data