PIC18 Bootloader

[Jon Wilder]

I've just about finished up a bootloader firmware for a reverse engineering project I'm doing for a company. In their bootloader, they had it set up to deal with the configuration word embedded in the hex file. I've also written my bootloader to do the same. I've tested it and it works quite well.

But then I got to thinking...is there really even a good reason why field updating firmware should also include changes to the configuration word? I would think that you flash the bootloader firmware in, have it set the configuration word, and it's basically set and forget. I honestly cannot think of any scenario where a field update would also require a configuration word change.

What say all of you?

 

[Pommie]

I can't think of any reason it would need to update config registers. If the bootloader runs then the new code will be able to run. Maybe the original used a chip that couldn't write its own config registers.

Mike.

 

[Jon Wilder]

The original used a 18F2525, which can write to its configuration registers during runtime. In their main application hex files, the extended address record and the configuration word data record are both present. I just cannot figure out any reason why you'd want to change it from how the bootloader firmware sets it up.

 

[Jon Wilder]

In looking at the differences in the bootloader config word record and the main application config word record, the only differences are the brown out reset and the watchdog enablement. The bootloader application disables the watchdog while enabling brown out reset, while the main application disables brown out reset and enables the watchdog.

Both of these allow for software control with the correct configuration word setting, rendering the need for config word changes moot.