CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Hex2Bin for bootloader
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
georpo



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

Hex2Bin for bootloader
PostPosted: Fri Dec 18, 2020 1:42 pm     Reply with quote

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:
Code:

:08180000763204000000000034
:0818E0005C110400000000008F
:08192800D410040000000000CF
:081BF8003220EF0083E0200021
:101C0000008041001040BA000160EF0000000600B3
:101C10000A0D0000495000003A250000753A000006
:101C2000257500003A250000753A00002575000072
:101C3000000000003220EF0063E22000008041003D
:101C40001040BA000160EF00000006000A0D00001D
:101C5000506F0000727400003A250000750000000B


Bin:
Code:

76 32 04 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 5C 11 04 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF D4 10 04 00 00 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

_________________
George.
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Dec 18, 2020 1:49 pm     Reply with quote

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



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Fri Dec 18, 2020 1:57 pm     Reply with quote

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. Rolling Eyes
_________________
George.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Dec 18, 2020 2:47 pm     Reply with quote

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:
Quote:

hex2bin v2.5, Copyright (C) 2017 Jacques Pelletier & contributors

Allocate_Memory_and_Rewind:
Lowest address: 00001800
Highest address: 00001C5F
Starting address: 00001800
Max Length: 1120

Binary file start = 00001800
Records start = 00001800
Highest address = 00001C5F
Pad Byte = FF

Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
Overlapped record detected
georpo



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Fri Dec 18, 2020 3:03 pm     Reply with quote

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



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Dec 18, 2020 3:42 pm     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Dec 18, 2020 4:35 pm     Reply with quote

hmm.
.. re:
Quote:
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.

What might be important is HOW does the PIC bootloader decide the incoming data IS a valid program ? Normally they check each line(CRC ?). If you just send a .bin file how is it checked at the PIC ?

I'm thinking you want to download the entire file at once ? Perhaps to speedup the bootloading process ??

if done line by line, a bootloader could ask to resend a 'bad' line, if done in one big file, the entire file would have to be resent.....if so, it could take a lot longer...

Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 19553

View user's profile Send private message

PostPosted: Sat Dec 19, 2020 2:59 am     Reply with quote

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. Sad
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Dec 19, 2020 5:39 am     Reply with quote

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



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Sat Dec 19, 2020 10:22 am     Reply with quote

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? Rolling Eyes

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



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Dec 19, 2020 10:36 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19553

View user's profile Send private message

PostPosted: Sat Dec 19, 2020 10:48 am     Reply with quote

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



Joined: 18 Nov 2008
Posts: 281
Location: Athens, Greece.

View user's profile Send private message

PostPosted: Sat Dec 19, 2020 11:11 am     Reply with quote

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



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Dec 19, 2020 11:26 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19553

View user's profile Send private message

PostPosted: Sat Dec 19, 2020 11:26 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group