• AVR Freaks

Helpful ReplyHot!PIC16F Intel Hex File Questions

Page: 123 > Showing page 1 of 3
Author
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
2020/07/12 12:24:27 (permalink)
0

PIC16F Intel Hex File Questions

Here's a little program, with the program data entries condensed for brevity. (2-5)

I'm using the documentation found at keil.com/support/docs/1584/

Lines 2 - 6 are data.
The last line indicates end of record.
Line 1, is that to indicate the start of data? It is only a digit difference from line 7.

:020000040000FA
:0400000080311A2809
:100008007E1480314E010C1E10287E015510D5102B
:1000180055114E0190109A149A18901C1828803186
:1000280093204E019A1090107E10090080311C28F0
:0C030800003401348C3052018C000800DD
:020000040001F9
:0A000E00EC3FFF3F9F3FFF3FFF3F25
:00000001FF

Another confusing paragraph...

"In the hex file there are two bytes per program word stored in the Intel ® INHX32 hex format. Data is stored LSB first,
MSB second. Because there are two bytes per word, the addresses in the hex file are 2x the address in program
memory. For example, if the Configuration Word 1 is stored at 8007h, in the hex file this will be referenced as
1000Eh-1000Fh."

I'm not following why that means the addresses are doubled, but for this line

:100008007E1480314E010C1E10287E015510D5102B

So the address is 8000h, and it looks like it doesn't need to be halved?




post edited by acharnley - 2020/07/12 12:43:34
#1
Bob White
Super Member
  • Total Posts : 336
  • Reward points : 0
  • Joined: 2010/11/06 19:52:38
  • Location: Denver, Colorado
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/12 12:40:44 (permalink)
0
You state you are asking about the PIC16F but the document you reference clearly states:
 
"Information in this article applies to:
  • MDK-ARM All Versions
  • C166 All Versions
  • C251 All Versions
  • C51 All Versions"
I don't see PIC16 on that list.
 
#2
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/12 12:41:21 (permalink)
0
Encountered the 500 bug, here's some more resources.
 

 
 

Attached Image(s)

#3
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/12 12:42:45 (permalink)
0
robertvwhite
You state you are asking about the PIC16F but the document you reference clearly states:
 
"Information in this article applies to:
  • MDK-ARM All Versions
  • C166 All Versions
  • C251 All Versions
  • C51 All Versions"
I don't see PIC16 on that list.
 



I thought the Intel hex format was universal.
#4
upand_at_them
Super Member
  • Total Posts : 585
  • Reward points : 0
  • Joined: 2005/05/16 07:02:38
  • Location: Pennsylvania
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/12 12:46:07 (permalink)
0
[deleted]
 
post edited by upand_at_them - 2020/07/12 12:57:58

Attached Image(s)

#5
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/12 12:57:55 (permalink)
0
Here's the code I have thus far so you can see what I'm aiming at. I have the hex file embedded into a c array so it's just a case of understanding those additional lines (1, 2, 7+)


post edited by acharnley - 2020/07/12 13:00:00
#6
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/12 12:59:14 (permalink)
0
hateful 500 bug
#7
ric
Super Member
  • Total Posts : 28009
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/12 13:40:09 (permalink)
+1 (1)
A better reference would be
https://en.wikipedia.org/wiki/Intel_HEX
One "feature" I think you have missed is that the addres field is stored in "big endian" format in this file, but the PIC data is stored in "little endian" format. https://en.wikipedia.org/wiki/Endianness
 

I'm not following why that means the addresses are doubled, but for this line

:100008007E1480314E010C1E10287E015510D5102B

So the address is 8000h, and it looks like it doesn't need to be halved?

That line, spaced out for clarity, is
:10 0008 00 7E14 8031 4E01 0C1E 1028 7E01 5510 D510 2B


So it contains 16 bytes of data, the address is 0x0008, which when halved is 0x0004, so 0x147E is stored at address 0x0004
 
 
post edited by ric - 2020/07/12 13:41:59

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#8
ric
Super Member
  • Total Posts : 28009
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/12 13:53:23 (permalink)
+1 (1)
acharnley
Line 1, is that to indicate the start of data? It is only a digit difference from line 7.

Lines 1 and 7 set the upper 16 bits of the address.
As addresses in the hex file are doubled, it takes more than 16 bits to represent address 0x8007 for the config data.

I also post at: PicForum
Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
NEW USERS: Posting images, links and code - workaround for restrictions.
To get a useful answer, always state which PIC you are using!
#9
NorthGuy
Super Member
  • Total Posts : 6228
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/12 13:54:32 (permalink)
0
acharnley
I'm not following why that means the addresses are doubled, but for this line

:100008007E1480314E010C1E10287E015510D5102B

So the address is 8000h, and it looks like it doesn't need to be halved?



 
The address in this command is 8 - it will be placed at address 4 in the device memory. Data bytes are LSB, but addresses are MSB.
#10
1and0
Access is Denied
  • Total Posts : 10999
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/12 14:24:44 (permalink) ☄ Helpfulby acharnley 2020/07/13 00:43:54
+1 (1)
acharnley
Another confusing paragraph...

"In the hex file there are two bytes per program word stored in the Intel ® INHX32 hex format. Data is stored LSB first,
MSB second. Because there are two bytes per word, the addresses in the hex file are 2x the address in program
memory. For example, if the Configuration Word 1 is stored at 8007h, in the hex file this will be referenced as
1000Eh-1000Fh."

I'm not following why that means the addresses are doubled, but for this line

:100008007E1480314E010C1E10287E015510D5102B

So the address is 8000h, and it looks like it doesn't need to be halved?

Hex file addresses are byte-addressable; i.e. it is halved for word-addressed PIC16 devices and not for byte-addressed PIC18 devices.
 
Here's your hex data:
 
:02 0000 04 0000 FA                                     
record type 04 -> upper 16-bit address = 0x0000
 
:04 0000 00 8031 1A28 09                                 
byte address 0x00000000 -> word address 0x0000 contains opcode 0x3180, etc.
 
:10 0008 00 7E14 8031 4E01 0C1E 1028 7E01 5510 D510 2B   
byte address 0x00000008 -> word address 0x0004 contains opcode 0x147E, etc.
 
:10 0018 00 5511 4E01 9010 9A14 9A18 901C 1828 8031 86   
byte address 0x00000018 -> word address 0x000C contains opcode 0x1155, etc.
 
:10 0028 00 9320 4E01 9A10 9010 7E10 0900 8031 1C28 F0   ...
:0C 0308 00 0034 0134 8C30 5201 8C00 0800 DD             ...
 
:02 0000 04 0001 F9                                     
record type 04 -> upper 16-bit address = 0x0001
 
:0A 000E 00 EC3F FF3F 9F3F FF3F FF3F 25                 
byte address 0x0001000E -> word address 0x8007
 
:00 0000 01 FF                                           
end of file
 
post edited by 1and0 - 2020/07/12 14:27:49
#11
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/13 00:44:39 (permalink)
0
Brilliant answers all. I've everything I need to crack on an implement today.

Wish the Nordic forums were this responsive!

Thanks, Andrew
#12
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/13 06:19:02 (permalink)
0
Nearing some type of solution.

I was using xxd to byte encode the intel hex into a c file. This wasn't efficient at all so I've wrote my own parser. One  further optimisation I can foresee, if I do the address/2 prior to spitting it out then I don't need the upper address select lines?
#13
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/13 06:54:08 (permalink)
0
First of all let's confirm if I've messed up the approach. I'll release everything to help others in the future and would much appreciate if anyone can give it a quick glance.

By recoding the file, removing the extra bits (: \n & checksum) I save about 50% flash, or 1kb on my bare PIC program. You can see I've reversed the data, I think this is correct for LSB.
 

:020000040000FA
:0400000080311A2809
:100008007E1480314E010C1E10287E015510D5102B
:1002F80003305101960090309500080005344034D1
:0C030800003401348C3052018C000800DD
:020000040001F9
:0A000E00EC3FFF3F9F3FFF3FFF3F25
:00000001FF


Outcome

Line #0 control - upper address set to false
Line #1 result - length:4, address:0, data:28 1a 31 80
Line #2 result - length:16, address:4, data:10 d5 10 55 1 7e 28 10 1e c 1 4e 31 80 14 7e
Line #3 result - length:16, address:380, data:34 40 34 5 0 8 0 95 30 90 0 96 1 51 30 3
Line #4 result - length:12, address:388, data:0 8 0 8c 1 52 30 8c 34 1 34 0
Line #5 control - upper address set to true
Line #6 result - length:10, address:32775, data:3f ff 3f ff 3f 9f 3f ff 3f ec



static const uint8_t glueFirmware[] = { 4,0,40,26,49,128,16,4,16,213,16,85,1,126,40,16,30,12,1,78,49,128,20,126,16,380,52,64,52,5,0,8,0,149,48,144,0,150,1,81,48,3,12,388,0,8,0,140,1,82,48,140,52,1,52,0,10,32775,63,255,63,255,63,159,63,255,63,236 };
 
 
 

post edited by acharnley - 2020/07/13 07:01:44
#14
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/13 07:34:54 (permalink)
0
And on the Cortex side, here's the code. I have a further query though. According to the datasheet it's a 24bit data payload, but what does it comprise off. I have data in bytes, send two with padding?

Attached Image(s)

#15
NorthGuy
Super Member
  • Total Posts : 6228
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 07:44:57 (permalink)
0
It's as on the picture - 0 bit, 14 bits of the instruction, then 9 zero bits.
 
For the byte-orientred SPI, if you have it in two uint8_t bytes (lower 8 bits in L and upper 6 bits in H, then what you need to send these bytes for the payload:
 
1. 0 
2. (H << 1)|(L >> 7)
3. L << 1
 
<edit> Corrected the order
 
 
post edited by NorthGuy - 2020/07/13 08:08:04
#16
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/13 08:40:48 (permalink)
0
I looked at it again and that now makes sense. I'm a little confused on the MSB and LSB, which appears to be MSB for both data and commands, but you said earlier -
 
"Data bytes are LSB, but addresses are MSB."

I reversed the data bytes from the Intel Hex thinking this was correct (AB CD EF transmits as EF CD AB) but not sure now.
#17
NorthGuy
Super Member
  • Total Posts : 6228
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 10:06:17 (permalink)
+1 (1)
acharnley
"Data bytes are LSB, but addresses are MSB."



I said this about the HEX file format:
 
:100008007E1480314E010C1E10287E015510D5102B
 
The address 0008 is represented as 0008 - MSB first
The instruction 147E is represented as 7E14 - LSB first
#18
acharnley
Super Member
  • Total Posts : 574
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/13 11:13:43 (permalink)
0
There is no 147E instruction, do you mean the 7E14 instruction is presented as 147E? wink: wink

Placing 7E14 into your partition below would have the 7E part coming first, which is MSB?

1. 0 
2. (H << 1)|(L >> 7)
3. L << 1
 
#19
1and0
Access is Denied
  • Total Posts : 10999
  • Reward points : 0
  • Joined: 2007/05/06 12:03:20
  • Location: Harry's Gray Matter
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 12:11:11 (permalink)
+1 (1)
acharnley
There is no 147E instruction, do you mean the 7E14 instruction is presented as 147E? wink:

Placing 7E14 into your partition below would have the 7E part coming first, which is MSB?

 
:10 0008 00 7E14 8031 4E01 0C1E 1028 7E01 5510 D510 2B
            ----
            7E   is the LSB of the instruction opcode 0x147E (BSF 0x7E,0)
              14 is the MSB of the instruction opcode 0x147E (BSF 0x7E,0)
#20
Page: 123 > Showing page 1 of 3
Jump to:
© 2020 APG vNext Commercial Version 4.5