Hi
thank you for your reply but in the meantime i think i've found out how your bootloader is working.
The hex file is indeed transferred to the PIC as it is but there are some things you need to know and i'll try to write that down for others.
Inspecting the code on the PIC32 before and after transferring a hex-file via the bootloader showed me, that the mikroe Bootloader has some big disadvantage.
It "can" brick it's own bootloader if there is something going wrong while uploading a hex-file. More details later.
This was the point where i've decided to design my own bootloader.
After studying a lot of datasheets i've got it to work and i'll describe a few important steps you need to know.
1. On a Reset, a PIC32 starts program execution at 0xBFC00000 (KSEG1) or 0x1FC00000 (PHY). Knowing this is extremely usefull.
2. Now that we know where our PIC is starting we need to place a method there which starts (jumps to) our real bootloader application which can then be placed anywhere.
If we take a look at the function-table in the statistics dialog of a standard mikroC-project we will see that there is a method called "__BootStartUp" placed at 0xBFC00000. So this is the first method that will be executed after startup. This method will initialize some basic settings (memory setup) of the MCU.
But, as i've told before, we need to place a method there which jumps to our bootloader. So i've started to try to move this method around and this works very well. 0xBFC00000 is located in the Bootflash-Area of the processor but you can also move it to the program flash.
3. Ok. So i've moved my whole bootloader-code and the __BootStartUp-method to one of the last pages in the program flash by using the orgall directive.
Then i've placed a small method at 0xBFC00000 which simply jumps to the address of the __BootStartUp-method which looks like this:
Code: Select all
void BootResetVector ( void )
{
// This is the first pice of code executed on a POR.
R30 = BOOTLOADER_START; // Address of __BootStartUp
asm JR R30;
asm NOP;
}
Now our PIC32 will directly jump to out bootloader-application.
4. So now our bootloader is working but we have another problem: The user-app has it's own __BootStartUp-method so we need to decide where to put this one.
And this one is the part where the mikroe-bootloader is doing something else. The mikroe-bootloader also has placed the BootResetVector-method at 0xBFC00000 when initially flashing the bootloader to the PIC.
But when uploading a user-app via the bootloader it simply overrides the boot-flash starting at 0xBFC00000 and places it's own __BootStartUp-method here.
I'am not 100% sure but i think it then modifies the jump-command which originally jumped to the main()-method of the user-app so it'll jump to the bootloader again.
So this modification is the critical part here. If there is something going wrong in the meantime of writing to 0xBFC00000 and updating the jump-to-bootloader command you've broken your bootloader because it will never jump to the bootloader anymore after startup.
5. So my bootloader will allways leave the BootResetVector-method alone an will never touch it when uploading a user-app.
Instead i've decided to org the user-app's __BootStartUp-method one page beyond 0xBFC00000 (0xBFC00000 + _FLASH_ERASE).
This has a little bit of disadvantage because you need to do a small modification of your user-app to org it's own __BootStartUp-method to this address. But for me this is totally acceptable.
6. The rest of the user-app is regularly placed at 0x9D000000 (KSEG0) as it comes from the hex-file.
7. To start our user-app from the bootloader we simply need to jump to 0xBFC00000 + _FLASH_ERASE. Remember this is the address of the user-app's __BootStartUp-method.
So, for me this is working great but it still needs a bit of testing but at the moment it looks good, even using interrupts in the user-app.
