I am trying to determine what base address I need for my program (built with GCC) so it is workable with the mikroBootloader. I looked at the examples provided, and they have the base address of 0x0800000 but how is this possible since this is the processor's base flash?! I even opened the bootloader hex file itself and it is 0x08000000!
How does this work? The loader and deployed program through that loader have the same base address?
I still compiled my code with base 0x0800000 and loaded it. It loaded fine using the mikro tool but my program did not execute.
Loading a program built with GCC
-
darko.ilijevski
- Posts: 581
- Joined: 21 Mar 2017 16:57
Re: Loading a program built with GCC
Hello,
Before we proceed, I have to ask you what MCU were you trying to program ? Did you try to open the "bootloader" example in mikro C ? You can see how the memory is organized for a specific MCU there, but mind you - not every MCU has the same memory structure, so you have to modify your code to work.
In general - there's two declarations, one for the main program location and the other is for the bootloader location. If you want to set up your own code which wouldn't violate our bootloader, you simply have to open up the example and see how the "START_PROGRAM_ADDR" compiler directive is defined for it. Also in general (I have used the PIC18F45K22 MCU):
Bootloader is loaded into memory. We telling it explicitly to be at some specific address, defined via the compiler directive as BOOTLOADER_START_ADDR (for the PIC18F45k22 it's 0x7CC0). When you reset your MCU, it jumps straight to that address, as the main loop is located there, assembler listing shows that at the address 0x0000, we have a single GOTO instruction (PIC18) which points to the bootloader start address (0x7CC0). It waits for the proper response on the uart, if it fails, it calls a function which is actually empty, but located at the START_PROGRAM_ADDR (0x7FC0), again in assembler, that's RCAL of the function located at the 0x7FC0. So as you can see, not much interrupt redirection, when bootloader starts, it simply fills in the custom program data at the START_PROGRAM_ADDR, function gets called after the reset, if there's not response back from the UART to start uploading another hex. Easy as that.
Best regards
Before we proceed, I have to ask you what MCU were you trying to program ? Did you try to open the "bootloader" example in mikro C ? You can see how the memory is organized for a specific MCU there, but mind you - not every MCU has the same memory structure, so you have to modify your code to work.
In general - there's two declarations, one for the main program location and the other is for the bootloader location. If you want to set up your own code which wouldn't violate our bootloader, you simply have to open up the example and see how the "START_PROGRAM_ADDR" compiler directive is defined for it. Also in general (I have used the PIC18F45K22 MCU):
Bootloader is loaded into memory. We telling it explicitly to be at some specific address, defined via the compiler directive as BOOTLOADER_START_ADDR (for the PIC18F45k22 it's 0x7CC0). When you reset your MCU, it jumps straight to that address, as the main loop is located there, assembler listing shows that at the address 0x0000, we have a single GOTO instruction (PIC18) which points to the bootloader start address (0x7CC0). It waits for the proper response on the uart, if it fails, it calls a function which is actually empty, but located at the START_PROGRAM_ADDR (0x7FC0), again in assembler, that's RCAL of the function located at the 0x7FC0. So as you can see, not much interrupt redirection, when bootloader starts, it simply fills in the custom program data at the START_PROGRAM_ADDR, function gets called after the reset, if there's not response back from the UART to start uploading another hex. Easy as that.
Best regards
BR,
Darko
Darko
