Helpful ReplyHot!Help understanding Pic24F Hex file format for an over the air bootloader

Page: 123 > Showing page 1 of 3
Author
binaryman
Super Member
  • Total Posts : 185
  • Reward points : 0
  • Joined: 2015/11/19 17:11:04
  • Location: Saint Louis, Missouri USA
  • Status: offline
2017/11/24 14:55:26 (permalink)
0

Help understanding Pic24F Hex file format for an over the air bootloader

Greetings from St Louis Missouri
 
I'm working with a pic 24FJ64GA004 and the boot loader app AN1157.  I have a beta boot loader that works very well with a serial port connected to PC running the microchip P24QP.exe Visual Basic Pic 24 programmer.  The problem is it doesn't work over the air yet.  Attached to this message is a zip file which contains a hex: Pic24F.hex and a boot loader log file.  I need to replace the P24QP.exe Visual Basic program with my own C++ class that can open up the attached hex file and then create the exact same data you see in the attached log file.  The boot loader log file first entry shows life begins at address 0C00
 
WritePM Len=1  Addr=0C00  Row=256
---------------------------------
WL 0C00:0000 0000
WL 0C02:0004 7F62
WL 0C04:0000 0000
WL 0C06:0004 7F62
...
 
The hex file does not have an interrupt vector table. (MPLAB-X project properties, XC16 linker options, NO Interrupt vector table is check on.  The Linker script for this hex file is set with a AIV at 0C00  I need to emulate how the Pic24 Visual basic program processes the attached hex file.  The first thing it transmits is the above
WL 0C00:0000 0000
 
Where in this attached hex file, what line does this occur ?
 
I read old threads from this forum about the hex file format - One suggest looking at the Intel document Hexadecimal Object File Format Specification, Rev A januar 1988 with the name intelhex.pdf
 
I looked it over and the Micro chip hex file doesn't seem to conform to that exactly, or does it ?
Is this ancient (1988) document really the best explanation of the attached Pic24 hex file ?
 
My target has an integrated EM250 Zigbee co-processor connected as a UART.  This EM250 has a network stack frame which will emulate a comport.  Ultimately my app hex files need to be send over the air by PC based windows application written in C++ that has a TCP network api and stack frame.  All I am missed is a C++ code can emulate Visual Basic Pic 24 programmer and serialize the actual data.  For security purposes all of the code for the entire project needs to be in C/C++.  I want help learning how to read and process a hex file for my boot loader. 
 
My target has a 2nd serial port just for debugging.  My target has printf mapped to a dedicated UART TX output going to a PC running a terminal program which captures the data.  This is particular Pic24 F chip has latches which buffer an entire PAGE of flash program memory before the actual write commit function.  I have modified the microchip boot loader example C function:  void WritePM(...) to echo back a hex dump. 
 
This attached hex file (Pic24F.hex) is from a working Pic24 bootloader app.  It is not not supposed to have anything below the address 0C00.  Life starts there for my app.
 
Are there any utility programs that will display a hex file in a better?  Or is this similar then that ?
 
Maybe somebody with experience will read this and can reconcile the attached hex file into the first 10 lines in the log file.
 
Monkey see monkey do.  If you can reconcile just 1% of this hex file for me,  separate the sections like this
 
:10 1800 0000  000  000627f0400  00  00  0000627f04000e
 
( I just made up those spaces just to emphasize all I need is for someone to  actually for real break down the entire line with spaces for each step this monkey can write the C++ class to do it automatically.    If you have suggestions of abstract functions a C++ class should have I'd appreciate it.
 
My server side Windows application is written in C++ builder.  It has a network stack frame and API that will accept serialize data and can transmit it to the target mac address.  The target zigbee firmware I developed will reassemble the data and present it to the Pic24 as a UART running at 115200 baud.  All of that part is all done.  All I need know is to learn how to process the hex file in C code for my target UC
 
If you have any suggestions, tips or links to things that will teach me how to open and process a hex file I would appreciate some suggestions.
 
Dan
St. Louis Missouri
post edited by binaryman - 2017/11/24 15:04:52
#1
NKurzman
A Guy on the Net
  • Total Posts : 15105
  • Reward points : 0
  • Joined: 2008/01/16 19:33:48
  • Location: 0
  • Status: online
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/24 15:02:58 (permalink)
3 (1)
The ivt will be the bytes right above the reset vector. The original intel hex only goes up to 64k. Make sure you have support for the upper word record. The Wikipedia entry is pretty good.
#2
BobAGI
Super Member
  • Total Posts : 1650
  • Reward points : 0
  • Joined: 2011/03/09 00:04:35
  • Location: Texas and Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/24 15:45:04 (permalink)
4 (2)
I have created my own PIC boot loader based on AN1157.
For this I also created a PC application to handle the hex file and convert it to a proprietary format for distribution to customers. The PIC boot loader communicates with a PC program I also wrote, whic uses the special format files as input.
Basically what I do regarding the hex file is that I read its contents into a memory byte array, which has first been reset to contain all 0xFF data (like a completely erased flash will).
I have supplied the functions that reset the RAM image and fill it with content of the hex file (all in Object pascal) to you via a PM. You may be able to use it for your C++ project.
 
 
post edited by BobAGI - 2017/11/24 15:57:48

--
Bo B
Sweden & Texas
 
#3
BobAGI
Super Member
  • Total Posts : 1650
  • Reward points : 0
  • Joined: 2011/03/09 00:04:35
  • Location: Texas and Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/24 15:58:23 (permalink)
0
I tried adding this text as an edit to my post but got a forum exception...:
 
Edit: This forum did not accept if I put the Pascal code in code tags in the body and it would not accept a zipfile either so I had to change the extension of the zipfile to txt in order to send the file...

--
Bo B
Sweden & Texas
 
#4
binaryman
Super Member
  • Total Posts : 185
  • Reward points : 0
  • Joined: 2015/11/19 17:11:04
  • Location: Saint Louis, Missouri USA
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/24 16:22:51 (permalink)
0
Hello  Bob
Sweden & Texas? Do you live in the country Sweden part time ?
 
You can email it to me if that is easier:  dga1965 at yahoo dot com
 
I have always used Borland ( Embarcaderro ) tools.  Mostly C++ builder.  I have the latest professional versions which include Delphi.  If you have Delphi code that processes the hex file I might be able to read it.  But truthfully what would be even better is for you to just give me an abstract description. 
 
My Target pic only has 64k of memory.  There is no eeprom  space. Starting off with a buffer of 64k and then starting initializing it to 0xFF is a great idea.
 
Could you look at the attached hex file and tell me how to pause the first record ?
Here is line 1
 
 
:1018000000000000627f040000000000627f04000e
 
Could you separate out the above ascii bytes into sub records that show me how to decode them and write to a 64k buffer that represents the image ?
 
Dan
St Louis
post edited by binaryman - 2017/11/24 16:24:28
#5
BobAGI
Super Member
  • Total Posts : 1650
  • Reward points : 0
  • Joined: 2011/03/09 00:04:35
  • Location: Texas and Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/24 16:40:40 (permalink)
4.5 (2)
No attached file....
And I live in Sweden but work with a company in Texas, so I go there regularly.
The PM should contain a zipfile in which is a pascal file with two functions from my TPic24Programmer class.
The one loading the hex file is rather heavily commented (for my own use), so if you read that you will understand what the record you shown means.
Your record
:10 1800 00 00000000627f040000000000627f0400 0e
breaks down as follows:
10: byte count = 16
1800: address = 0x1800
00: record type = data
00 00 00 00 62 7f 04 00 00 00 00 00 62 7f 04 00: 16 bytes data
0e: checksum
 
Read the comments in the LoadFromIntelFile() method.
 

--
Bo B
Sweden & Texas
 
#6
binaryman
Super Member
  • Total Posts : 185
  • Reward points : 0
  • Joined: 2015/11/19 17:11:04
  • Location: Saint Louis, Missouri USA
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/24 17:44:05 (permalink)
0
Bob, 
I got the file and it unzipped just fine.  You did a great job documenting it.  This will help out significantly.
 
I will get started on a C++ class and use this as a template. - My pic is a 24FJ64GA004 which is only 64k.  There is no EEPROM memory.  I wont be using config bits or words,  My APP firmware only uses about 32k of memory so making this work for up to 64k is all I need.  I don't need this to work for anything else but the 24FJ64GA004.  Is there anything else you suggest ?
 
Dan Ambrose
St Louis, Missouri USA 
 
#7
BobAGI
Super Member
  • Total Posts : 1650
  • Reward points : 0
  • Joined: 2011/03/09 00:04:35
  • Location: Texas and Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 00:20:03 (permalink)
4.5 (2)
Well, when transferring the data to the PIC following chip erase of the app area I scan the flash image in RAM and skip any block that only contains 0xFF bytes. Only blocks where there are bytes other than 0xFF are sent to the PIC BL.
And I do not transfer the config bytes either, our system requires the application to use the same config as the boot loader.
You might also want to check if the firmware on the chip is the same version as the hex image, in which case you can skip the flashing altogether. This means that you must set aside a known section in flash to always contain your firmware version so you can read back that from the chip and compare to the loaded hex image.
 

--
Bo B
Sweden & Texas
 
#8
maxruben
Super Member
  • Total Posts : 3132
  • Reward points : 0
  • Joined: 2011/02/22 03:35:11
  • Location: Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 03:21:40 (permalink)
3 (1)
Hi Dan,
 
Note also that two bytes makes up for one 16 bit program address in the PIC and you need two addresses for a complete 32 bit program word. Only 24 bits of the program word is used which is why every fourth byte in the data part of the hex file is always 0.
 
Since the addresses of the hex file is byte oriented and the addresses of the PIC is 16-bit word oriented, the address in the hex file needs to be divided by two in order to match the PIC. 0x1800/2=0x0c00.
 
The four bytes of one 32 bit program location (2 addresses in the PIC) in the hex file are read out, from left to right as: Low byte low word, high byte low word, low byte high word and high byte high word (which is always 0).
 
/Ruben
#9
binaryman
Super Member
  • Total Posts : 185
  • Reward points : 0
  • Joined: 2015/11/19 17:11:04
  • Location: Saint Louis, Missouri USA
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 05:52:48 (permalink)
0
Hi Ruben,
Your talking about ...."The four bytes of one 32 bit program location"...Ok wait ...I'm working with the Pic24FJG64-004 which is only 64k.  As a matter of fact you gave me example boot loader code for this pic.  Which I am VERY  thankful.  I'm on a mission to replace the Visual basic serial port utility program with a C/C++ app.  All I care about is this 64k PIC, does this is a 16 bit require 32 bit program locations as described in your message ?
#10
aschen0866
Super Member
  • Total Posts : 4182
  • Reward points : 0
  • Joined: 2006/01/08 22:18:32
  • Location: San Diego
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 08:46:42 (permalink)
5 (1)
Read Section 4. Program Memory
 
When you parse a hex file generated by the compiler tool chain, pay attention to the Type 4 record, which not only sets up the upper address but also serves as a section delimiter.
#11
BobAGI
Super Member
  • Total Posts : 1650
  • Reward points : 0
  • Joined: 2011/03/09 00:04:35
  • Location: Texas and Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 08:55:42 (permalink)
0
Regarding flashing principles I have this in my comment for method ProgramDevice in the TPic24Programmer class:
 
function TPic24Programmer.ProgramDevice(FileName: string): boolean;
{Program the device from data in supplied hex file.
Only program section from $1200 (word address). Erase must start at 0x1000 due to
device requiremets (granularity is 2048 bytes) so the boot loader is now limited to
the flash area below 0x1000.
Steps to take:
- Load hex file
- Compare hex file product code with existing code, do not allow write if different
- Read the program end address from flash at address 0x140C
- Erase flash from 0x1000 to the prog end page
- Write flash memory from loaded image starting at address 0x1200 (with verify)
  (Skip sections that contain no data)
}

HTH

--
Bo B
Sweden & Texas
 
#12
NorthGuy
Super Member
  • Total Posts : 4590
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 10:30:54 (permalink)
3 (1)
BobAGI
- Erase flash from 0x1000 to the prog end page



This is not a good idea for PIC24FJ64GA004. This chip contains config bits at the end of the last page (0xabfc). This page shouldn't be erased under any circumstances.
#13
T Yorky
Super (Thick) Member
  • Total Posts : 458
  • Reward points : 0
  • Joined: 2012/08/28 02:07:35
  • Location: UK
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 11:15:45 (permalink)
4 (1)
"Hexadecimal Object File Format Specification, Rev A january 1988".
Well I would say that you can't really get a better reference than the specification itself.
To be fair, I don't see the complication in intel-hex. There was a previous post by Dave Nadler which had the source code for parsing an Intel Hex file. Could you not use this?
 
 
#14
BobAGI
Super Member
  • Total Posts : 1650
  • Reward points : 0
  • Joined: 2011/03/09 00:04:35
  • Location: Texas and Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 11:24:06 (permalink)
3 (1)
NorthGuy
BobAGI
- Erase flash from 0x1000 to the prog end page

This is not a good idea for PIC24FJ64GA004. This chip contains config bits at the end of the last page (0xabfc). This page shouldn't be erased under any circumstances.

Well, my system is using a PIC24FJ256GB206 chip with 256 KB of flash.
The comments were for that chip...
 

--
Bo B
Sweden & Texas
 
#15
NorthGuy
Super Member
  • Total Posts : 4590
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 11:34:48 (permalink)
4 (1)
BobAGI
Well, my system is using a PIC24FJ256GB206 chip with 256 KB of flash.
The comments were for that chip...



PIC24FJ256GB206 also has configuration bits in program memory (at 0x2abf8). Therefore, you cannot erase the last page (the one starting at 0x2ab800). I guess your actual code doesn't really go that far.
#16
T Yorky
Super (Thick) Member
  • Total Posts : 458
  • Reward points : 0
  • Joined: 2012/08/28 02:07:35
  • Location: UK
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 11:46:20 (permalink)
0
Northguy/Bobagi,
I maybe repeating myself/others here...
I never erase the last page due to advice in the manuals, BUT it is possible, BUT risks bricking the device. The memory area (virtually a full erase page) that is associated with the config can be used to store 'system routines' that never change. Referencing them as 'far' ensures an absolute jump/call.
Coincidently, the erase/flash routines are stored here in my apps. A client i work for, has these routines in the first page with the vectors...
#17
BobAGI
Super Member
  • Total Posts : 1650
  • Reward points : 0
  • Joined: 2011/03/09 00:04:35
  • Location: Texas and Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 13:24:07 (permalink)
0
NorthGuy
BobAGI
Well, my system is using a PIC24FJ256GB206 chip with 256 KB of flash.
The comments were for that chip...



PIC24FJ256GB206 also has configuration bits in program memory (at 0x2abf8). Therefore, you cannot erase the last page (the one starting at 0x2ab800). I guess your actual code doesn't really go that far.

Correct, the config bytes are not touched as I explained in an earlier post.
There is one borderline case I never have come to and that is when the code expands into the last page.
In that case there would be a problem programming the chip. But so far there is no real risk of that for us, we have plenty of space left....
The erase is only done up until the page containing the last program instructions:
- Erase flash from 0x1000 to the prog end page


--
Bo B
Sweden & Texas
 
#18
NorthGuy
Super Member
  • Total Posts : 4590
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/25 15:02:05 (permalink)
3 (1)
T Yorky
I never erase the last page due to advice in the manuals, BUT it is possible



The change to the config is effective immediately, so if you can live with config of all "1", you probably can do that.
 
Some Microchip docs say that to prevent security breach through the erase of the last page they set security protection to On if you erase the last page. This may be true on some chips, or may be not.
#19
maxruben
Super Member
  • Total Posts : 3132
  • Reward points : 0
  • Joined: 2011/02/22 03:35:11
  • Location: Sweden
  • Status: offline
Re: Help understanding Pic24F Hex file format for an over the air bootloader 2017/11/26 04:42:28 (permalink)
4 (1)
dambrose
Hi Ruben,
Your talking about ...."The four bytes of one 32 bit program location"...Ok wait ...I'm working with the Pic24FJG64-004 which is only 64k. 



I was trying to explain how the byte addresses of the hex files corresponds to the 16 bit word addresses in the PIC24.
 
Each instruction word is 24 bits (3 bytes) on the PIC24 devices but occupies 32 bits (4 bytes) in the address space for the program memory and 2 address locations of 16 bits each. Every odd address location only contains 8 programmable bits but is still 16 bits wide.
 
In the hex file each byte has its own address and one instruction word consists of 4 bytes, where the upper byte is always 0. Since one PIC24 program memory address is 16 bits wide you have to divide the hex file address with 2 to get the PIC24 program memory address.
 
The PIC24FJ64 family is erased in blocks of 512 instructions (one page) at a time. This equals 2048 1024 addresses (of 16 bits each). Since you don't want to erase the lowest page which contains the reset address and the interrupt vectors, your application needs to start at least on address 2048 (=0x0800) 1024 (=0x400). Locations 0x200 to 0x7ff 0x3ff, after the alternate IVT, can then be used for part of the bootloader.
 
Your 64k PIC24 actually only has around 22k instruction words (3 bytes for each instruction).
 
/Ruben
 
Edit - Corrected after T Yorkys post #21 below.
 
 
 
post edited by maxruben - 2017/11/26 06:45:49

Attached Image(s)

#20
Page: 123 > Showing page 1 of 3
Jump to:
© 2017 APG vNext Commercial Version 4.5