Bootloader question

benoitstjean · Posted: Sun Mar 16, 2014 7:34 am

COMPILER: 4.141
PIC: 24HJ128GP306

Hello,

I looked at the CCS example for the bootloader and it is pretty straightforward. However, I do have a question about memory management which I cannot seem to find... or perhaps I'm not understanding something.

In example EX_PCD_Bootloader.c, basically, it's a simple program checks a pin and if high, it jumps to the bootloader section. The actual bootloader code is written at the end of the PIC memory. This example has a simple main() section and that's about it and is written at the beginning of the memory at 0x400. Fair enough.

This is basically similar to what I want in my application. But, this is where I am not sure... If I re-program everytime *that* piece of code that checks the pin at startup, then in a successful upgrade, that code along with my own code would be upgraded... but if anything was to go wrong while doing a firmware upgrade, especially if it is a remote upgrade, then the PIC could become completely unaccessible if the problem occurs while the upgrade is writing that main() function that reads the pin. Understand what I mean?

What I want is that simple program (that reads the pin) along with the bootloader to be written once and only once with the CCS programmer (I have the ICD-U64). Then, all other programming afterwards will be done through the serial port (PINS F4 and F5 using an FTDI cable). After the initial programming with the CCS programmer, the PIC should basically become a device that waits for a firmware upgrade OR starts a piece of code at address X... in other words, the PIC will now be a generic device that has a simple program in it that, when powered-up, checks a pin and if high, starts the bootloader otherwise, runs another program.

When I write my own program (the real program), how do I specify that it should start at some other address? And since my own program also has a main() in it, will it go bonkers after the FW upgrade? Does any of this make sense?

As a test, using the CCS example, I wrote the initial program using the U64 programmer and displayed "Hello world" right after that *if* statement that checks the pin... so, at power-up, if the pin is low, my terminal console writes <Hello world>. Then, I changed to "Hello Benoit" and hit the compile button but this time, I reprogrammed everything using the serial port through the bootloader and it worked - at power-up, if the pins is low it now says "Hello Benoit". However, this is where I'm confused - I don't want to have to overwrite that piece of code intrinsically to the programmer - that initial code should be written once.

Does any of this make sense?

Thanks,

Benoit

temtronic · Posted: Sun Mar 16, 2014 8:34 am

Yes it makes sense to me and I haven't used bootloaders since the 68HC11 dayze! Seems everyone puts blind faith in the bootloader completing the upgrade without problems. Silly things like an EMP 'glitch', soft power supply,bad connection can easily trash the 'upgrade'. If you consider 'BIOS' upgrades on PC, I'm pretty sure they keep the current FW active until the new FW is fully downloaded and verified(checksum OK ?).ONLY after verification does the new FW become the real FW.
Since I haven't used bootloaders on PICs I don't know what 'safety' precautions they use,others will though.

hth
jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19509

You don't reprogram the bootloader. This is written once (with a conventional programmer). The main 'runtime' code, does not include the bootloader. Often the bootloader will be written to refuse to overwrite the program area where the bootloader itself is held, and (if this is in low memory - the PIC has instructions to write protect this separately from the rest of the memory), it'll often be write protected. This is why 'low memory' bootloaders are more common than high memory ones on the PIC. Only the PIC24 and later (hence PCD), have the ability to protect the upper memory separately, and hence on these it is worth putting the bootloader here. This also helps since the configuration data is held in the same area, allowing both to be in a similar protected area.

The #BUILD instruction allows you to set 'where' the compiled code locates.

You can do 'transfer then write' bootloaders, where the receive component writes something like an external EEPROM, and then the actual reprogramming is done from this, only if it's checksum is correct, but simply protecting the bootloader, and then having this verify that the write was correct is the simplest approach.

No, people don't rely on the bootloader always being right. It is protected, so it'll still be present, if something does go wrong.

No, main has no 'meaning'. It is just a code name for 'this is where the code is to start'. When you #build, you specify where the initial jump is placed, and _this_ jumps to the 'main' in the code compiled at this point. Once the bootloader jumps to the initial jump location (which has to be where it expects it to be), this then jumps to the new 'main'.

ex_pcd_Bootload.c, shows a program to be loaded _with_ the example bootloader. pcd_bootloader.h, ensures that this won't overwrite the bootloader.

benoitstjean · Posted: Mon Mar 17, 2014 6:18 am

Hmm... So if the #build instruction sets *where* the code is written, what's the difference with the #org instruction?

PCD_bootloader.h contains these lines:

Ttelmah · Joined: 11 Mar 2010 Posts: 19509

Very different from ORG. As I said it sets where the _initial_ jump to the main code resides. The rest of the code comes after this. You can't #ORG the initial jump.

The bit you have snipped out of bootloader.h, is only used if you are defining a _low memory_ bootloader. Hence the main code is put after this.

benoitstjean · Posted: Mon Mar 17, 2014 9:44 am

Hi again Ttelmah...

Ok, so, going back to my problem... This is what I'm reading in Microchip's docs (AN1094: Bootloader for dsPIC30F/33F and PIC24F/24H Devices):

"The bootloader target application is located in the dedicated program memory region, starting at address 0x400. On start-up, the bootloader reads program memory address 0xC00, which contains a bootloader delay value. If the bootloader fails to detect UART activity within the time period specified by the delay value, it suspends itself and transfers execution to the user application located at program memory address 0xC02".

Fair enough... but I guess I'm missing something here... Take the most basic program (not even the bootloader, just the most basic a program can be):

Hello.c:
---------------------------------------
#include "HelloWorld.h"
void main( void )
{
fprintf( MONITOR_SERIAL, "\n\rBenoit!" );
while( 1 );
}
---------------------------------------

Hello.h:
---------------------------------------
#include <24HJ128GP306.h>
#fuses HS, WDT, PR, WPOSTS16
#use delay( crystal = 36864000, clock = 73728000 )
#use rs232( UART2, baud=9600, parity=N, bits=8, STREAM=MONITOR_SERIAL, ERRORS )
---------------------------------------

When I compile and run this, I see "Benoit!" on my serial terminal.

The .hex file generated by the program above is this:

:080000001602040000000000DC
:100400003220EF00C3202000008041001040BA00DD
:100410000160EF00000006000A0D000042650000C8
:100420006E6F0000697400002100000081E0A800E8
:1004300034002000243A880024012000343A880047
:100440000E00FC00301020003174200082072000D4
:10045000A3092000824878008348780043E7B7006A
:100460004800DE0021742000620420007305200093
:100470008248780083487800804878000028EF00A0
:100480000400280084118800044020009411880092
:10049000F40E2000C41188002CA3EF002AA3EF0063
:1004A0000FF82300F0FF230020A0B7000000000099
:1004B0000FF82300F0FF230020A0B7000000000089
:1004C00001002000010078000160EF00000202003E
:1004D000000000008100E8003322AF00FEFF37007B
:1004E00034A2B700800020000008E600F5FF3700C6
:0C04F00078020400000000000040FE0044
:0200000401F009
:10000000CF0000FFCF0000FF070000FF800000FFCF
:10001000460000FFDF0000FFE70000FFC30000FF15
:00000001FF
;PIC24HJ128GP306
;CRC=A96F CREATED="17-Mar-14 11:36"

Let's say that _this is_ the program I want to upload using the bootloader, I would assume that somewhere in either the .c file or the .h file I have to specify *where* I want this program to be located in memory, right?

So in the HEX code above, the second line indicates that there are 16 parameters (0x10) and the start address is 0x400. Right there, this is inconsistent with Microchip's explanation: it says the code will check the delay at 0xC00 and if there is such delay and it expires, then it will run the user application at 0xC02. The bootloader should be at 0x400.

So in the case of my application above, I don't have a bootloader so shouldn't the program be at 0xC02? I'm really confused here because my program does start at 0x400, not 0xC02.

Ttelmah · Joined: 11 Mar 2010 Posts: 19509

bootloader.h does this for you.
If you load this in the bootloader code, it sees that there isn't a define for _bootloader_ (so knows this is the run time code), and for high memory bootloader, there is not a define 'BOOTLOADER_AT_START', (if there is, then it uses #build to locate the start of the code above the bootloader). If the bootloader is at the end, it doesn't have to relocate the initial jumps, and just uses #ORG.

benoitstjean · Posted: Mon Mar 17, 2014 10:34 am

But what I'm trying to say/explain/understand is since I need a "default program" that checks the input pin to know if it should go in boot loader mode or not, then this program cannot be overwritten hence my second post where I show some code:

benoitstjean · Posted: Mon Mar 17, 2014 10:58 am

Ok, here's a little exercise I did to perhaps explain better:

I compiled ex_pcd_bootloader.c and burned it to my PIC using the U64 programmer. Note that I added plain text for the sake of knowing where I'm at in the code... so, on power-up, I see this on my serial console:

Hit any key when ready...

At this point, if I read the contents of the PIC using the U64 programmer, the result is a 495,547 bytes-long file with what I presume to be the "main(void)" code starting at address 0x400... here's the line in the dumped hex file:

[...]
:1003E000FFFFFF00FFFFFF00FFFFFF00FFFFFF0019
:1003F000FFFFFF00FFFFFF00FFFFFF00FFFFFF0009
:100400003220EF00C3202000008041001040BA00DD (start of main)
[...]

Now if I scroll down to the very end of this dump, I see the following, which I presume is the bootloader code:

[...]
:10A7E000FFFFFF00FFFFFF00FFFFFF00FFFFFF0075
:10A7F000FFFFFF00FFFFFF00FFFFFF00FFFFFF0065
:10A800004055020001000000FFFFFF00FFFFFF00B6 (start of bootloader)
all the way down to
:10AEB000B01180000000FE00FFFFFF00FFFFFF0059
:10AEC000FFFFFF00FFFFFF00FFFFFF00FFFFFF008E
then it's blank all the way down to 0xAFF0. Fair enough.

Now, this is where I do a "firmware upgrade".

I tie an alligator clip to my prog pin to make it go HIGH and hit spacebar. Then, the serial console displays:

Firmware upgrade - hit any key to continue...

So now, I hit spacebar and now it says:

Upload file NOW

and it just sits there waiting. So, in TeraTerm, I click FILE > SEND FILE and choose "hello_world.hex".

IMPORTANT NOTE: That same "hello_world" application, if I was to compile and burn it alone with the U64 programmer, at power-up, I'd see "Hello world" on my serial console, that's it. And if I do this and look at the hex dump, I will see, again starting at 0x400, the start of THIS program (I can actually find the "hello world" hex character in the hex dump.

But here, the excercise is to program "hello world" using the bootloader...

So, now, I upload the file using TeraTerm through my little FTDI to serial converter. It goes all the way up to 100% and then the PIC reboots.

The result? Nothing!! Nothing gets printed! No "hello world" nor "Hit any key when ready...". Nothing.

At this point, if I now re-read the entire contents of the PIC, the _ONLY_ data starts at address 0xA800 - that's the bootloader code that got programmed initially with the U64 programmer.... but there' no other code nowhere. Everything else has been overwritten.

Does this make more sense?

jeremiah · Joined: 20 Jul 2010 Posts: 1347

jeremiah · Joined: 20 Jul 2010 Posts: 1347

As an example, if you told me you wanted a hello world application that was to be run by a bootloader and the bootloader had the following requirements:
1. timeout at 0xc00
2. New firmware starts at 0xc02
3. All firmware interrupts remapped at 0x0c06
4. Crystal frequency = 36864000, but multiplied to 73728000 by PLL

and you haven't given me a bootloader.h

Then I might do the following:

jeremiah · Joined: 20 Jul 2010 Posts: 1347

If instead you told me you were going to use the example bootloader from CCS, with

Crystal frequency = 36864000, but multiplied to 73728000 by PLL

I would suggest the following:

benoitstjean · Posted: Mon Mar 17, 2014 11:55 am

Hi Jeremiah,

I need the "selector" program to be the very first thing to start at power-up. That program should never be overwritten.

What you just explained to me sparked something:

The other alternative could be to use the bootloader delay but I'm starting to think that this is not set to anything by default.... is this possible?

In Microchip's AN1094, <TABLE 4 - Boot Delay Configuration>, it indicates that 0xC00 stores the delay for the bootloader and <TABLE 5 - Valid Delay Values> shows that valid values are from 0 to 255, 0 being <Suspend bootloader and transfer execution to the user application>. After a full hex dump, unless I'm reading this wrong, address 0x0C00 is always 0.... which leads me to think that perhaps I should put a value in there?

[...]
:100BF000FFFFFF00FFFFFF00FFFFFF00FFFFFF0001
:100C0000FFFFFF00FFFFFF00FFFFFF00FFFFFF00F0
:100C1000FFFFFF00FFFFFF00FFFFFF00FFFFFF00E0
[...]

Ideally, when the PIC boots, the entire PIC could be blank except for the end portion that contains the bootloader. At power-up, if I have a bootloader delay of 10 seconds and there is UART activity before 10 seconds, then theoretically, the bootloader code will kick-in and store the main application in the right location.... does this make any sense? That would be the most logical way to do it, right? Therefore if the main code gets corrupted, you can always trust that the bootloader code will always work no matter what (assuming that nobody wrote over it).

benoitstjean · Posted: Mon Mar 17, 2014 11:58 am

Sorry, I re-wrote after you posted your comments. Let me have a look...

benoitstjean · Posted: Mon Mar 17, 2014 12:02 pm

Regarding your line:

#rom int16 0x0C00 = {10000} //timeout value

I think this is a key element that would prevent me from having to read my PROG_PIN therefore the bootloader would always be available even if the FW upgrade crashed. However, why the value 10000? Valid values are from 0-255 unless the '1' of your 10000 is little endian (I doubt because it's a decimal value).