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 working on LPC2368 microcontroller. I was supposed to develop 2 firmwares in the same controller. I had developed a bootloader code and the actual code. The bootloader runs at 0x0000 and the actual code is at 0x2000. Now when i start the system it runs from 0x0000 and passes the execution to 0x2000 if there is no firmware upgradation. The actual code takes the upgration through serial port and stores at an address of 0x28000 and after succesful writing at 0x28000 it simply passes the execution to 0x0000 as follows
#define BOOTLOADER_START_ADDRESS 0x00
void execute_bootloader_code(void) {
void (*bootloader_code_entry)(void);
VICIntEnClr = 0xFFFFFFFF; // disable all interrupts;
bootloader_code_entry = (void (*)(void))BOOTLOADER_START_ADDRESS;
bootloader_code_entry(); }
so when the bootloader runs and checks if there is a new firmware avaliable it erases the actual code at 0x2000 and starts writing the code from 0x28000 to 0x2000. Hence my new firmware has been upgraded and the execution is passed to 0x2000.
Now my problem is when i upgrade the code, my code is running upto a certain point in the intialization. The certain point is i am actually disbaling all interrupts and enabling only UART-2 and UART-0 interrupts. When the execution comes to enabling of these interrupts the execution is passed to 0x000 i.e., reset vector... I couldnt find the reason why my code is being reset. I had observed the RSIR and didnt find any thing suspicious.. How do i find why my code has jumped to 0x0000. can anyone suggest me to solve this problem.
Regards, Srinivas.R
1) Do you remember to remap the interrupt vectors? The boot loader owns the original interrupt vector table at address 0 in flash, so the processor needs to overlay a piece of RAM on top of the flash with your 0x2000-located interrupt vectors.
2) Note that if the code initializes interrupts in the wrong order, you can get into big troubles since the boot loader has already initialized peripherials. Your boot loader did only disable all interrupts - it didn't fully disable the UART etc. So the same moment your application enables the UART interrupt vector, your UART is already initialized and might want to issue an interrupt - but with the vector still pointing into your boot loader.
1) "Do you remember to remap the interrupt vectors? The boot loader owns the original interrupt vector table at address 0 in flash, so the processor needs to overlay a piece of RAM on top of the flash with your 0x2000-located interrupt vectors."
There is a startup file for both Bootloader and Actual code.. and also the MEMMAP is mapped to flash, PLL is reintialized and VIC is also intilaized in the Actual Code. So do i need to remap again? Please tell me how to remap.
After successful upgradation i.e, code being copied from 0x28000 to 0x2000 i am again calling the below function
so again the bootloader code is executed, but this time since there is an updated code in the flash it will directly pass the execution to 0x2000.
As you said i did not disable UART interrupt. Yes i forgot to disable the interrupts before calling the execute_bootloader_code() function. Now before calling this function i have disabled all the interrupts and loaded the code. but still the problem persists. Now i had another observation. There is a difference in the startup codes. The bootloader startup code is from UV3 and the actual code startup is from UV4.
Will it make any difference. I have another doubt that the two codes have two startups. The bootloader startup code resides from 0x0000. The actual code startup resides from 0x2000 right??
It doesn't matter if the bootloader and the application have startup code from different versions of uvision.
What matters is that the bootloader code - or the application code - does map a piece of RAM (the 23xx datasheet tells you exactly which address range of RAM that will be remapped) on top of the flash vector table. And that you have code that copies the vector table from the start of the application code to the RAM region, before the application has reached code that requires the interrupt system to be up and usable.
And of course that the application was linked with a project file that reserved this RAM region so the copying of the application vectors from flash into RAM doesn't overwrite any application variables - or the reverse, i.e. no application variables overwrites the interrupt vectors.