Hex2Bin for bootloader

[georpo]

Hello,

I am trying to understand the binary file generated by Hex2Bin.
Any help appreciated.
Below are the start of each file.
Thanks for any tip!

From Hex:

[temtronic]

OK, I have to as where does the 'Hex2Bin' program come from ??

As I see it, somehow it 'parses' ..strips or removes the data that the bootloader program needs leaving just the machine language code that the PIC uses. Though in the example shown it has only done the first line of code..

well, that's my guess

[georpo]

http://hex2bin.sourceforge.net/

I am just trying to make the file smaller so as to fit to the external flash.
I do not see the address in the bin file and I see many 0xFF bytes.
_________________
George.

[PCM programmer]

Your hex file has record types of 08 and 10. I don't see those record
types listed in this explanation of hex file format:
https://www.keil.com/support/docs/1584/
It only lists record types of 00 to 05.

Is it possible that you have edited the real hex file, to produce the file
in your post ?

Because you have a weird hex file, it gives errors when running it with hex2bin.exe:

[georpo]

The 08 and 10 are the data size of each line.
All lines of my example are type 00 = data.
I figured it out, I understand how it works.
My new question now is how to add CRC16 to the generated bin file so that I can check it before actually writing to the PIC.

Thanks.
_________________
George.

[PCM programmer]

You're right, I misinterpreted the type location. I can't believe I did that.

There have been some recent topics on CRC code. Here is one:
http://www.ccsinfo.com/forum/viewtopic.php?t=59105

[temtronic]

hmm.
.. re:

[Ttelmah]

Understand that for a bootloader, the loaded data for the application has
to start after the bootloader. If you convert this to binary, you will have
bootloader size bytes filled with FF, before the start of the actual code.
Then if your code has const data structures stored at the top of memory,
you will have another huge swathe of FF bytes between the code and this
data.
What you send to the bootloader, needs to include address data for the
packets to avoid this. So you would have to take the binary result, and
find every location that contains data, and send some form of address
data before the actual data. You'd also need some way of telling addresses
from data. This is what the hex format gives you.
There are more compact ways of coding this (depending on the actual data
size in your storage medium), but binary is not an effective or good choice...
The posted .hex would not be suitable for loading by a bootloader, since
the program is not offset to clear the bootloader.

[temtronic]

Hmm Mr T brings up a lot of critical issues to deal with and got me thinking, while the coffees dripping...

It might be possible to have the PC burn the flash as an 'image'. IE the flash would be the same size as the PIC program memory. We don't know your PIC size but say it has 64KB of pgm space. The bootloader would copy 64KB from the external flash (less bootloader space and size...).
While this would mean a smaller external flash, the bootloader would take time to copy the entire 'image'.
So you have to do some 'math' and decide which is better, a larger external flash costing a bit more but uses 'old' bootloader or a smaller flash using the 'new' bootloader. Keep in mind to include R&D costs ! I'm betting most here never put a value on the 1,000s of hours we spent working late into the night doing R&D and adding that to the cost of the product.
This boils down to 'time and money'. The 'old' way costs more and is faster, the 'new' way is cheaper but slower.
It would be intersting ,as an exercise, to see the 'numbers'..
Jay

[georpo]

Hello and thanks everybody for taking the time to reply.
Yes I understand that the actual firmware is located after the bootloader.
I will take care of this because I know where the firmware should be located.
It is not that simple for my case to send line by line because a PC application sends the firmware to my "transmitter" board through W5100 ethernet.
Then the "transmitter" board sends the firmware with AT86RF212B to many AT86RF212B "receivers" using "basic mode" which means they can all receive the data simultaneously but there is no acknowledge that they did.
And of course I cannot have 100 devices reply at their own will that line X did not arrive correctly.
So! I must send the hex file to the receiver and save to an external flash and after that the code calculates the hex file CRC and compares with the CRC written at the end of the file. It there is a match, then it passes to the loader.

One question that just came in mind.
The loader code checks each line checksum and if correct, it writes the data.
What if some lines are bad but the previous correct lines are already written? Do I get a bricked PIC?

As about the binary file, it is smaller than half the hex. It fits the receiver flash memory and with some barrels of coffee and late night work I will make it work. That is why I ask for CRC for the binary file. When I receive the binary file, I will check for correct CRC and then program to the PIC.

Sorry for the long post.
Any comments are very welcome.
_________________
George.

[temtronic]

General comment on bootloaders:
1) I'd use a PIC big enough to allow two copies of the program, 'old' and 'new'. The bootloader would receive and store the new program in the 'newprogram' partition. ONLY after it's verifed to be 'OK', then the 'press to run' button would 'point' to the 'NEW' program. If for any reason the new program can't work (bad CRC, ??), then the PIC runs the 'old' or current version of the program. I think this is how upgradabel BIOS EEPROMS work in PCs as there has to be some method to not 'brick' the PC.

2) I'd expect the bootloader to have some 'retry' code though the last one I worked on was for a 68HC11 project and it didn't have ANY retry. Maybe you could retry a line 3 times then it's a hard failure, forcing the PIC to retry from the start ? 3 failed 'restarts' and bootloading is terminated ?

[Ttelmah]

No, you don't get a 'bricked PIC', you just have to run the bootloader again.
Remember the bootloader is run 'before' the main code, and is not writable
by the bootloader. So it always remains there as your 'rescue' route.

[georpo]

Yes, I know that the bootloader is always there.
In my bootloader code, I check for a specific value in the first location of the ext. flash to see if it should run the current application or go for the loader.

Let's say that I receive and write the hex file to the ext. flash with some error bytes.
So the bootloader code starts actually writing to the program memory line by line.
After 100 lines it finds a "bad" line and does not write it.

How does the bootloader save me from this?
The first 100 lines are already written resulting in a bricked PIC.
Am I wrong?
_________________
George.

[temtronic]

As long as the bootloader is in the PIC, it can't be 'bricked',you simply 'press the new download key' or whatever method coded to start the entire download all over again.

It's critical that the bootloader can either retry an 'bad line', or start over as there's lots of reasons for a 'bad line' to occour.

Hopefully whoever coded the bootloader has thought of these problems !

Jay

[Ttelmah]

What you do is have the 'specific location' only erased, if the whole
file has written correctly to the chip. You checksum the data that is to
be written, and have the bootloader checksum what is in the chip. You
only turn off the flag when it does match. This way the bootloader keeps
being called till the data is correctly written.