Bootloaders

[Oznog]

I finally figured out how to use a bootloader with PICC18! Hooray!

OK, I have some questions now. This setup is such that the bootloader will delay startup of the main code until a timer has expired or the serial port receives a character. This looks painful for the product to sit there waiting every time in normal use, but if I reduce the counter to 1/10 sec or so it would be tough to hit the spacebar in Hyperterminal in time.

Also I want to use that same RS232 port for talking to a GPS through the NMEA-0183 serial protocol. By the rules the bootloader uses, it seems that if the GPS were already plugged in and sending data as the PIC is powered up, it would go into bootloading mode upon receipt of the first character, not only failing to execute code but putting it in grave danger of overwriting the program with misinterpreted GPS data.

It occurs to me that the thing to do would be to have the bootloader only respond if it sees "THIS IS A PROGRAM" somewhere in the data stream as it powers up, if it doesn't occur in the first 20 characters immediately, go into normal mode. It is quite unlikely the GPS data will randomly come up with this string of character. The bootloader is in C, I can recode it to do this (and recognize "IS A PROGRAMTHIS" as valid too). But I do not know how to handle the computer side of it (Hyperterm); it seems it will need to continuously loop sending "THIS IS A PROGRAM" until it sees the part respond with a "READY TO PROGRAM" string. This would be something an end-user will need and I'd like it to be supported on a Mac too, so it would need to be a "generic" solution. Is there a scripting language I could use with Hyperterm so I don't have to learn to write a whole damn windows program?

Or should I just send them a .hex file with 10,000x "THIS IS A PROGRAM" before the code, and just say that you must start the "Send Text File" with the part powered down and then power up the part within x seconds so it catches the string? Seems a bit confusing to a non-user, especially if they're fiddling the with baud rate settings.

 

[Oznog]

I did have one thought just now- if the baud rates and all the other factors are compatible, perhaps the main code trying to interpret the data as GPS data could also watch for "THIS IS A PROGRAM". If it sees it, it would immediately execute the reset command, which would start the bootloader code again. As long as "THIS IS A PROGRAM" were repeated enough times to cover the delay before the bootloader begins reading the serial port again, it should be able to catch the fact that it's supposed to program the code space without any complicated sequence of events from the user working the Hyperterminal.

Thus the user could just plug in the serial port at any time and Send Text File should be able to program it reliably. Am I right?

 

[Mike - K8LH]

You might consider having your bootloader look for a switch to be pressed during power up... If the switch is pressed at power up you go into bootloader mode, if the switch is not pressed you go into normal program operation...

Does your design have any switches?

Regards, Mike

 

[Nigel Goodwin]

The 16F bootloader from https://www.microchipc.com only waits a very short time for a serial byte, and it has to be the correct one. To use it you run the PC bootloader program, then power-up the PIC, it detects the correct byte from the PC, and sends a reply - then enters the bootloader sequence.

As also suggested, you can use bootloaders triggered by a button press, but these waste an I/O port.

 

[Mike - K8LH]

you can use bootloaders triggered by a button press, but these waste an I/O port.

Not necessarily Nigel... It won't waste an I/O pin if he has a switch in his project already... And that would make the operational logic quite simple;

<1> Connect to PC RS232 port... Apply power to unit while pressing switch "X" to enter bootloader mode.
<2> Connect to XX RS232 port... Apply power without pressing any switches to enter normal run mode.

And if he doesn't have any switches in his project, it could be a nice creative exercise trying to figure out which used I/O pin could support a switch or jumper and pull-up resistor to provide the bootloader 'trigger' function, without affecting the circuit adversely...

In one of my projects I installed a jumper between RB3 and a microminiature direct drive Soberton GT111P speaker on the PCB (wired to ground)... With the jumper in place for normal operation RB3 input reads as '0'... With the jumper removed for the bootloader 'trigger' the RB3 input reads as '1'...

I suspect there are many creative ways to provide a hardware bootloader 'trigger' if he can't overcome his current RS232 'trigger' problems...

Regards, Mike