Hi,
If you use some of our Bootloader examples (source which can be found in our compilers or HEX file), Bootloader is placed at the last page of the microcontroller flash.
Your program which you load via Bootloader, should be placed from the beginning of the flash memory, so there shouldn't be any collision between your project and part of the memory where Bootloader is placed.
You can take a look at Bootloader example in compiler:
...\mikroBasic PRO for PIC\Examples\Other\USB HID Bootloader\Projects
and of course adjust the example for your needs if it's necessary.
Best regards,
Marina
MikroBootloader issue
Re: MikroBootloader issue
OK I'm not altogether clear on the details, but it looks like the code to invoke the bootloader is compiled and linked into the main program, and gets replaced when a new build of the program is transferred. That wasn't what I was expecting but presumably it works or you wouldn't supply it. If I installed a program image that didn't include code to call the bootloader then I'd be unable to replace it.
I understand that Microchip went a different route, if I follow them correctly they move the origin of the main program image up in memory by a small amount and the pre-compiled wedge to invoke the loader sits at the bottom of flash. I think the actual loader is still at the top of flash but I might have misunderstood that bit. The advantage is that if the code at org 0 never gets overwritten then it is harder to "brick" the device, but it needs tweaks to preserve the interrupt vectors and of course the linker needs the ability to build code for a different "origin" value.
I understand that Microchip went a different route, if I follow them correctly they move the origin of the main program image up in memory by a small amount and the pre-compiled wedge to invoke the loader sits at the bottom of flash. I think the actual loader is still at the top of flash but I might have misunderstood that bit. The advantage is that if the code at org 0 never gets overwritten then it is harder to "brick" the device, but it needs tweaks to preserve the interrupt vectors and of course the linker needs the ability to build code for a different "origin" value.
-
marina.petrovic
- Posts: 2986
- Joined: 18 Apr 2013 08:11
Re: MikroBootloader issue
Hi,
Indeed there is a little difference in implementation of the bootloader.
You can find some useful explanations on this forum topic:
http://www.mikroe.com/forum/viewtopic.php?t=7370
Also, on our forum you can find some other discussion which can be helpful.
Best regards,
Marina
Indeed there is a little difference in implementation of the bootloader.
You can find some useful explanations on this forum topic:
http://www.mikroe.com/forum/viewtopic.php?t=7370
Also, on our forum you can find some other discussion which can be helpful.
Best regards,
Marina
Re: MikroBootloader issue
Bootloader is a fairly simple thing but appears complicated.
When you compile your normal code and program it, the first instruction is a jump over the interrupt vectors (0x04 for 16Fxxx and 0x18 for18Fxxx)
The program starts to run from here, so the first instruction executes at 00, then jumps to the program start, maybe at 0x20 for example.
The bootloader starts first with an instruction to jump to the bootloader program which is a few hundred bytes at the top of the memory stack.
This then writes to the serial port (or USB) and looks for a response from the PC. Initially it sends 256 "g" characters, and this can be seen using the usart to view the serial port. If there is no response, the bootloader then jumps back to the loaded program which then runs as normal.
If it does see a response to the string of "g"s then the bootloader program calculates a suitable offset for the new data and writes the data from the PC to the PIC program memory. Note it cannot program the Config or EEprom section.
The new start location is stored. On reset the process repeats, and if the PC no longer responds, the new program runs from its new address.
If you examine the data for the first lines with a directly programmed program and then for a bootladed program, the initial jump will be different, and for the latter will point high in the memory. The former just jumps over the interrupt vector(s). If you also erase the memory before programming the bootloader, you will find that the top page of the memory will have data written, not the usual 3FFF before the bootloader has been run. The jump address should remain the same after the bootloader has been used. Read the program memory using the PIC programmer to verify this.
You cannot bootload the bootloader . It has to be programmed using a PIC programmer with the correct oscillator speed for the target (user) program (unless you are controlling the PLL in software). The bootloader has to be set for the correct port and baudrate as programmed with the PIC programmer.
The baudrate (if using the Usart) can be changed after the program is loaded but studying the results in the Usart tool can be a challenge then.
There was an issue with the 16F1xxx enhanced chips where the erases to memory were done in blocks of 32 bytes, but writes were done in blocks of 8. This caused some errors in the upper page addresses as they had to be a multiple of 32 or data got erased wrongly and the programs would fail or run in strange ways.
I think the 18Fxxxx do use a similar method.
Hope this clarifies things a bit.
When you compile your normal code and program it, the first instruction is a jump over the interrupt vectors (0x04 for 16Fxxx and 0x18 for18Fxxx)
The program starts to run from here, so the first instruction executes at 00, then jumps to the program start, maybe at 0x20 for example.
The bootloader starts first with an instruction to jump to the bootloader program which is a few hundred bytes at the top of the memory stack.
This then writes to the serial port (or USB) and looks for a response from the PC. Initially it sends 256 "g" characters, and this can be seen using the usart to view the serial port. If there is no response, the bootloader then jumps back to the loaded program which then runs as normal.
If it does see a response to the string of "g"s then the bootloader program calculates a suitable offset for the new data and writes the data from the PC to the PIC program memory. Note it cannot program the Config or EEprom section.
The new start location is stored. On reset the process repeats, and if the PC no longer responds, the new program runs from its new address.
If you examine the data for the first lines with a directly programmed program and then for a bootladed program, the initial jump will be different, and for the latter will point high in the memory. The former just jumps over the interrupt vector(s). If you also erase the memory before programming the bootloader, you will find that the top page of the memory will have data written, not the usual 3FFF before the bootloader has been run. The jump address should remain the same after the bootloader has been used. Read the program memory using the PIC programmer to verify this.
You cannot bootload the bootloader . It has to be programmed using a PIC programmer with the correct oscillator speed for the target (user) program (unless you are controlling the PLL in software). The bootloader has to be set for the correct port and baudrate as programmed with the PIC programmer.
The baudrate (if using the Usart) can be changed after the program is loaded but studying the results in the Usart tool can be a challenge then.
There was an issue with the 16F1xxx enhanced chips where the erases to memory were done in blocks of 32 bytes, but writes were done in blocks of 8. This caused some errors in the upper page addresses as they had to be a multiple of 32 or data got erased wrongly and the programs would fail or run in strange ways.
I think the 18Fxxxx do use a similar method.
Hope this clarifies things a bit.
-
petar.timotijevic
- mikroElektronika team
- Posts: 1739
- Joined: 19 Feb 2014 13:46
- Location: Serbia
- Contact:
Re: MikroBootloader issue
Hi,
Also please see this document:
A FLASH Bootloader for PIC16 and PIC18 Devices
http://ww1.microchip.com/downloads/en/A ... 00851b.pdf
Best regards,
Peter
Also please see this document:
A FLASH Bootloader for PIC16 and PIC18 Devices
http://ww1.microchip.com/downloads/en/A ... 00851b.pdf
Best regards,
Peter
