• AVR Freaks

Helpful ReplyHot!PIC16F Intel Hex File Questions

Page: < 1234 > Showing page 2 of 4
Author
acharnley
Super Member
  • Total Posts : 616
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 13:00:00 (permalink)
0
That explains it. The plot thickens, or at the very least my headache.

So in a 16 bit byte encoding the first part '7E' is always known as the LSB?

I ask because earlier we had address 0008 and said this is MSB first, which would mean sending over 08,00?
#21
ric
Super Member
  • Total Posts : 28422
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 13:08:10 (permalink)
+1 (1)
You seem to be confusing 16 bit data (held wherever) with the byte data in the hex file.
Right back in post#8 I told you that in the hex file, the high byte comes first in the address, and second in the 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!
#22
acharnley
Super Member
  • Total Posts : 616
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 13:23:52 (permalink)
0
Conflicting information

Attached Image(s)

#23
upand_at_them
Super Member
  • Total Posts : 659
  • Reward points : 0
  • Joined: 2005/05/16 07:02:38
  • Location: Pennsylvania
  • Status: online
Re: PIC16F Intel Hex File Questions 2020/07/13 13:25:22 (permalink)
+2 (2)
The hex file has nothing to do with the programming spec.
#24
acharnley
Super Member
  • Total Posts : 616
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 13:27:01 (permalink)
0
So the high byte can be in any order, have to know it beforehand.

0008, high byte first, MSB required, so write as 00,08
12E3, low byte first, LSB required, so write 12,E3
12E3, low byte first, MSB required, so write E3,12
#25
ric
Super Member
  • Total Posts : 28422
  • Reward points : 0
  • Joined: 2003/11/07 12:41:26
  • Location: Australia, Melbourne
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 13:28:12 (permalink)
+1 (1)
acharnley
So the high byte can be in any order, have to know it beforehand.

0008, high byte first, MSB required, so write as 00,08
12E3, low byte first, LSB required, so write 12,E3


You seem to be over generalising things. Context is everything.
 

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!
#26
1and0
Access is Denied
  • Total Posts : 11163
  • 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 16:14:20 (permalink)
+2 (2)
acharnley
So the high byte can be in any order, have to know it beforehand.

0008, high byte first, MSB required, so write as 00,08
12E3, low byte first, LSB required, so write 12,E3
12E3, low byte first, MSB required, so write E3,12

You're making this more difficult than it needs to be. :(

Let's take the record in Post #20, again ;)

:10 0008 00 7E14 8031 4E01 0C1E 1028 7E01 5510 D510 2B

            7E        is stored at byte addr 0008 (lo byte at word addr 0004)
              14      is stored at byte addr 0009 (hi byte at word addr 0004)
                 80   is stored at byte addr 000A (lo byte at word addr 0005)
                   31 is stored at byte addr 000B (hi byte at word addr 0005)

I really don't know how to dumb it down more. ;)
#27
NorthGuy
Super Member
  • Total Posts : 6309
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/13 19:04:33 (permalink)
+2 (2)
acharnley
There is no 147E instruction, do you mean the 7E14 instruction is presented as 147E?



No. The instruction is 0x147E (human readable form is MSB first), which is
 
BSF 0x7e,0
 
In the HEX file it appears as 7E14.
 
When you're going to pass it to the device during programming, you need to send MSB first, but you also need to shift it left by one, so you'll send three bytes as your payload: 0x00, 0x28, 0xFC
 
Same with the address. You shift left by one and send MSB first. But the addresses in the HEX file are doubled (remember?), so you need to divide by two. If you read the address from HEX file as 0008, the device address is 0x0004. The payload for the "load address" command will be: 0x00, 0x00, 0x08
 
 
 
 
#28
acharnley
Super Member
  • Total Posts : 616
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/14 01:18:26 (permalink)
0
Right, I think I have it. I've adjusted my script to reverse the data addresses to be MSB first which makes the payload send function universal. I'd missed that the address was also sent in the same way.


static void sendPayload (uint16_t payload) {

  NRF_SPI0->TXD = 0;
  sendWait();
  NRF_SPI0->TXD = payload >> 6;
  sendWait();
  NRF_SPI0->TXD = payload << 1;
  sendWait();
  tdly();
}


I note only 15 bits are being sent, so the +8000 upper address should also be divided by /2. Has to be. Data conversion is therefore -
 
:020000040000FA
:0400000080311A2809
:100008007E1480314E010C1E10287E015510D5102B
:1002F80003305101960090309500080005344034D1
:0C030800003401348C3052018C000800DD
:020000040001F9
:0A000E00EC3FFF3F9F3FFF3FFF3F25
:00000001FF
 
=

Line #0 control - upper address set to false
Line #1 result - length:4, address:0x0, data:31 80 28 1a
Line #2 result - length:16, address:0x4, data:14 7e 31 80 1 4e 1e c 28 10 1 7e 10 55 10 d5
Line #3 result - length:16, address:0x17c, data:30 3 1 51 0 96 30 90 0 95 0 8 34 5 34 40
Line #4 result - length:12, address:0x184, data:34 0 34 1 30 8c 1 52 0 8c 0 8
Line #5 control - upper address set to true
Line #6 result - length:10, address:0x4007, data:3f ec 3f ff 3f 9f 3f ff 3f ff
post edited by acharnley - 2020/07/14 01:26:05
#29
1and0
Access is Denied
  • Total Posts : 11163
  • 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/14 06:36:00 (permalink)
0
acharnley

  NRF_SPI0->TXD = payload >> 6;

 

I think that should be:

  NRF_SPI0->TXD = payload >> 7;

#30
1and0
Access is Denied
  • Total Posts : 11163
  • 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/14 07:09:16 (permalink)
+1 (1)
acharnley
I note only 15 bits are being sent, so the +8000 upper address should also be divided by /2. Has to be. Data conversion is therefore -
 
 
Line #5 control - upper address set to true
Line #6 result - length:10, address:0x4007, data:3f ec 3f ff 3f 9f 3f ff 3f ff

I don't think so -- see Figure 3-8 in the programming spec.  Why not do this instead:
static void sendPayload (uint32_t payload) {
  NRF_SPI0->TXD = payload >> 15;
  sendWait();
  NRF_SPI0->TXD = payload >> 7;
  sendWait();
  NRF_SPI0->TXD = payload << 1;
  sendWait();
  tdly();
}

#31
acharnley
Super Member
  • Total Posts : 616
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/14 07:57:21 (permalink)
0
[deleted]
post edited by acharnley - 2020/07/14 10:01:02
#32
1and0
Access is Denied
  • Total Posts : 11163
  • 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/14 08:54:35 (permalink)
0
acharnley
I concur, and that makes 14 bits.

14 bits?  The function in Post #31 can do more than 14 bits. ;)
 
#33
acharnley
Super Member
  • Total Posts : 616
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/14 09:57:52 (permalink)
+1 (1)
The post was out of sync, I was referring to the instruction size. The rest is padding as is 'described' somewhat cryptically in the programming guide.
 
Edit - I agree the maximum address is 32,767 using this approach, and 0x4007 fits whereas double this doesn't, so I'm inclined to say all addresses are halved. Besides words are still used for upper address space aren't they?
post edited by acharnley - 2020/07/14 10:09:03

Attached Image(s)

#34
1and0
Access is Denied
  • Total Posts : 11163
  • 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/14 10:48:45 (permalink)
+1 (1)
acharnley
Edit - I agree the maximum address is 32,767 using this approach, and 0x4007 fits whereas double this doesn't, so I'm inclined to say all addresses are halved. Besides words are still used for upper address space aren't they?

It is halved, but the result is not 0x4007.  The maximum address is NOT 32,767. As I've told you in Post #11:
 
: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
#35
acharnley
Super Member
  • Total Posts : 616
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/14 11:23:08 (permalink)
0
Yes I see what you mean.

I'll wait for Northguy to chip in, it was his code which suggested the first byte could be zero.

It's possible/probable he was giving the example for instruction use and I've wrongly used it for both.
#36
1and0
Access is Denied
  • Total Posts : 11163
  • 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/14 11:48:12 (permalink)
+1 (1)
acharnley
It's possible/probable he was giving the example for instruction use and I've wrongly used it for both.

Yup. ;)
 
#37
NorthGuy
Super Member
  • Total Posts : 6309
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/14 21:44:58 (permalink)
0
If you send an instruction, the first byte will always be zero, because the instruction length is 14 bits.
 
If you send an address (or if you're programming PIC18 which uses the same scheme but has longer instructions) the first byte may not be zero.
 
 
#38
1and0
Access is Denied
  • Total Posts : 11163
  • 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/14 21:58:32 (permalink)
+1 (1)
I've only looked at the spec briefly and understood the 24-bit payload field to be this:
 
  SUUU UUUH HHHH HHHL LLLL LLLP

where S is the Start bit, U H L are the data bytes, and P is the stoP bit; both Start and Stop bits are 0.
#39
acharnley
Super Member
  • Total Posts : 616
  • Reward points : 0
  • Joined: 2016/05/01 06:51:28
  • Location: 0
  • Status: offline
Re: PIC16F Intel Hex File Questions 2020/07/15 03:07:39 (permalink)
0
That's how I have it. I've attached the updated script to create the c file and the corrected c code (easy to use on anything really). Unfortunately the SPI on my NRF chip isn't working as it should and I'm awaiting Nordic's frustrating tech support before I can verify the task is working. Looks promising though!


 
static inline void tdly (void) {

  nrf_delay_us(2); // TDLY
}

static void sendWait (void) {

  while (!NRF_SPI0->EVENTS_READY) {}
  NRF_SPI0->EVENTS_READY = 0;
}

static void command (uint8_t value) {

  NRF_SPI0->TXD = value;
  sendWait();
  tdly();
}

static void sendPayload (uint16_t payload) {

  NRF_SPI0->TXD = payload >> 15;
  sendWait();
  NRF_SPI0->TXD = payload >> 7;
  sendWait();
  NRF_SPI0->TXD = payload << 1;
  sendWait();
  tdly();
}

static void loadAddress (uint16_t address) {

  command(0x80);
  sendPayload(address);
}

inline void UpdateFirmware(void) {

  // start spi here

  // handshake
  NRF_SPI0->TXD = 'M';
  NRF_SPI0->TXD = 'C';
  sendWait();
  NRF_SPI0->TXD = 'H';
  sendWait();
  NRF_SPI0->TXD = 'P';
  sendWait();
 
  // bulk erase
  loadAddress(0x8000); // all areas
  command(0x18);
  nrf_delay_ms(10); // TERAB

  uint16_t pos = 0;
  while (pos != (sizeof(glueFirmware)/sizeof(glueFirmware[0]))) {
    uint8_t size = glueFirmware[pos];
    pos++;
    loadAddress(glueFirmware[pos] << 8 | glueFirmware[pos+1]);
    pos += 2;
    while (size) {
      command(0x1); // load nvm, address will auto increment
      sendPayload(glueFirmware[pos] << 8 | glueFirmware[pos+1]);
      size -= 2;
      pos += 2;
    }
    // flash latch data
    command(0xE0);
    nrf_delay_ms(8); // TPINT - 10ms covers all cases
  }

}
 

post edited by acharnley - 2020/07/15 03:14:09
#40
Page: < 1234 > Showing page 2 of 4
Jump to:
© 2020 APG vNext Commercial Version 4.5