Page 1
In our last tutorial, we showed how to program our new firmware into the target area of the PIC processor's Flash program memory. When we told BLPro.exe to run the new target firmware, the device stopped running the bootloader code, and started running the new target firmware instead.
We saw that the bootloader effectively disappeared, and was replaced by the new target firmware that we just programmed into the device. That target firmware will always run automatically, even if the device is powered down and up again, or is reset.
So, an important question arises:
"How do we get back to the bootloader when it is time to do a field upgrade?"
Page 2
The answer is that the target firmware must have some way of jumping back to the bootloader code (which is still in place, close to the top of the PIC processor's Flash program memory) at the appropriate time.
YOU, the developer, must decide what "at the appropriate time" means. It could be a press of some secret button, or a special command from the PC, or something else you decide.
Whatever it is, it must be something that your end user can easily do without special equipment, yet it must be something he would not ordinarily do, so the device doesn't suddenly switch over to bootloader mode during normal use. (Customers don't like surprises like that!)
Page 3
Here is how we do the switchover from target device to bootloader in the sample program, AryTst5_2550.hex.
This sample program is a HIDmaker project, so we expect that this device will be connected to a PC. We further expect that a special program is running on the PC that can send data to this device, and read data from it. This particular device expects the PC to occasionally send it an array of bytes called Data1[ ].
The arrow points to a small "if" statement we have added to the source code, where the firmware has just received a complete Output Report of data from the PC. This code says:
IF the first two elements of the array we just received from the PC are 101 (decimal) and 102 (decimal) respectively,
THEN go into assembly language and perform a far jump to the start of the bootloader code, which in this case is located at absolute address 0x6800.
This causes the device to switch to running the bootloader. If the target device was a USB device, the previous device will appear to electrically detach itself from the USB, and the bootloader will electrically attach itself and present itself to the PC.
Click on the image for page view.
Page 4
Let's watch that in action.
To review where we left off, we had programmed this target firmware into the device and we ran it, so the PC program BLPro.exe thinks that the bootloader is disconnected or inactive...
Click on the image for page view.
Page 5
... and the AnyHID program sees that the new firmware has appeared and connected itself.
Select the new device in the drop down list labeled "Step 1," and click the Open button.
Click on the image for page view.
Page 6
Perform these steps:
- Select the Output Report, so we can send data to the device
- Click the button labeled "< Set ARRAY elements"
This will bring up a dialog box, shown on the next page.
Click on the image for page view.
Page 7
We need to enter the special values 101 (decimal) and 102 (decimal) into the first two elements of this array.
Highlight the first element in the list box...
Click on the image for page view.
Page 8
...and type in 101 (without the 0x prefix, AnyHID assumes that you mean that the number is a decimal value) in the first array item.
Repeat the process for the second array element, then click the OK button.
Click on the image for page view.
Page 9
Now click the button labeled "Send this Report" to send the data, and watch what happens.
Click on the image for page view.
Page 10
When you send the Output Report, AnyHID sends the data to the device, and that special IF statement sees the special values and jumps to the bootloader.
AnyHID also shows that the PC has recognized that our target device, called "Demos arrays of values, & Buffered Bytes," has electrically disconnected itself (has thus been closed and disconnected), AND the bootloader device has come back and is now connected again.
Click on the image for page view.
Page 11
Our bootloader PC program, BLPro.exe, now sees that the bootloader device that it knows how to talk to has come back, so the program has opened this device for I/O again.
We are now ready to use the bootloader (again), possibly to perform an upgrade of the firmware in the field.
We could repeat the steps in these tutorials over and over again as much as we want, switching the device back and forth between running the bootloader and then programming and running the target device firmware.
As long as we have some special code in the target firmware to jump to the bootloader at the appropriate time, the switchover process is easy and reliable.
Click on the image for page view.
| 
