bootloader problems - thebytefactory codeloader

[josh]

Dear all

Please assist me with the correct procedure when programming/using bootloaders.

I downloaded the bootloader from THEBYTEFACTORY and recompiled it for the 16F876. I then programmed it into the pic. When I power up the pic with an open Hyperterminal connection (19200, 8, N, 1, XON/XOFF,LINE DLY 10 ms), I get the prompts to load, but what ever file I try to send is rejected with a write failure message.

[ckielstra]

The original code from ByteFactory was most likely developed for a UNIX or Linux environment because it doesn't accept the hex-files from a Microsoft environment where the lines end with CR/LF instead of only CR.
I also added a test for hex-files with an invalid line length, for example caused by wrong baudrate settings.

In the top of the source file add a

[ckielstra]

As a remark for other people interested in this bootloader:

This is a free bootloader for the CCS compiler and can be found at http://www.thebytefactory.com/dl_codeloader.asp

This bootloader sits high in memory.

Positive issues:
- Written in C for the CCS compiler (PIC18)
- Free
- Well documented (in source)
- And a whole other list of issues mentioned on their website that I'm not going to copy.

Negative issues:
- This code is like a Beta release. It functions but has many issues open for improvement. The first release was October 2003, no updates since. It's a good starting point for writing your own bootloader though.
- Large (3400 bytes)
- Terribly slow data programming, about 16 times slower than the Picstart Plus programmer. This is caused by an inefficient programming algorithm which programs a whole 64 byte block for every byte read from the input file.
- The original version boasts to be nice in programming the Flash memory only when bytes are changed, this is too much pride! It's true that it's not programming when data is the same, but with a single byte changed, it must program a whole block of 64 bytes, and with all 64 bytes changed it's doing this 64 times!!!

[Guest]

Sorry about the inefficiencies of the PIC18 version of CodeLoader. It was a quick rewrite of the PIC16 version so that High-range folks would have something to work with. It's true that I don't review it regularly and it's true that any given version of PCM/PCH may slow it down or even break it. I do still believe that the principals it is built on are sound.

In the PIC16 version I had the luxury of erasing and reprogramming a single memory location. For the PIC18, I went with the current 64 byte block erase/modify because write_program_memory works that way; and that's because Microchip redesigned the way FLASH works in the PIC18. I could have filled a 64 byte buffer and written everything at once but then boundaries have to be considered. Does every byte of this new packet belong to the current memory block? Was that the last packet but the buffer wasn't full so that block hasn't been written yet? There is certainly room for improvement but most would come at the expense of code size, and as you know, that's one of the biggest drawbacks of CodeLoader already.

The little feedback I've had about CodeLoader has been mostly positive. I wouldn't mind making it better when time permits so feel free to make suggestions and report bugs. I already have some ideas about using a union to reduce the need for make16 and make32 so when my current project concludes I may make revisions.

All the best,
Gary Smithson