• AVR Freaks

Helpful ReplyHot!PIC16F Intel Hex File Questions

Page: < 1234 > Showing page 3 of 4
Author
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/15 06:18:55 (permalink)
0
Something like that.
 
The "Load Data" command is 0x02, not 0x01.
 
Also the 0xE0 command writes in pages - that is 32 consecutive instructions aligned to 32-byte boundary. Therefore, aside of making more writes than necessary, your code will fail if a hex file line crosses page boundaries. Your HEX file is too small for this, but if it was a little bit bigger, this would happen for the line which starts with:
 
:10003800 ...
 
This is different for config bytes. If I remember correctly, you need to write them one instruction at a time.
post edited by NorthGuy - 2020/07/15 07:08:43
#41
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 08:57:03 (permalink)
0
Good spot on the 0x02 mistake.

I can't find anything in the programming spec about the command writing as a page. I did assume each line was a row, latches were only for a row not a page, and the command wrote a row.

So I need a few extra smarts to detect if an address lies after the previous row boundary and if so write the previous latches?
 
post edited by acharnley - 2020/07/15 09:04:49
#42
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 10:22:19 (permalink)
0
Right I need to clear some things up before I have yet another rewrite on my hands.
 
The data, English presented, looks like this:

Line #1 result - length:4, address:0x0, data:31 80 28 1a
Line #2 result - length:16, address:0x4, data:
Line #3 result - length:16, address:0xc, data:


1. 0x4 doesn't fall on a row boundary.
2. Latches store the current address when written to.
3. there is one latch for each word and 32 latches for each row.
4. The reason for Line 1 and 2 is address 0x3 and 0x4 aren't used.
5. The reason for subsequent length=16 lines in the data file instead of one larger line (when addresses aren't skipped) is for legacy purposes, i.e there's no reason why it couldn't have been

Line #2 result - length:32, address:0x4, data:14 7e 31 80 1 4e 1e c 28 10 1 7e 10 55 10 d5 11 55 1 4e 10 90 14 9a 18 9a 1c 90 28 18 31 80
 
I'm thinking it might be best to condense because the program in flash is sequential from address 0x0.

So end up with one line for the program data which for the above would look like -

Line #1 result - length:300, address:0x0, data:31 80 28 1a ff ff 14 7e 31 80 1 4e 1e c 28 10 1 7e 10 55 10 d5 11 55 1 4e 10 90 14 9a 18 9a 1c 90 28 18 31 80 ...

Similar for the upper address data.








 
 
post edited by acharnley - 2020/07/15 10:33:49
#43
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 12:53:43 (permalink)
0
I hope there are no more surprises.

So now the parser creates a uint16_t array containing multiple (area, length, ...words) where area is 0x0, 0x8000 with any missing address words padded. I've saved 200 bytes encoding the program below and the writing is row aligned.


 
Line #0 control - upper address set to 0x0
Line #1 result - length:4, address:0x0, words:3180 281a
Line #2 result - length:16, address:0x4, words:147e 3180 14e 1e0c 2810 17e 1055 10d5
Line #3 result - length:16, address:0xc, words:1155 14e 1090 149a 189a 1c90 2818 3180
Line #4 result - length:16, address:0x14, words:2093 14e 109a 1090 107e 9 3180 281c
Line #5 result - length:16, address:0x1c, words:107e 140 3180 28bd 140 198 199 19a
Line #6 result - length:16, address:0x24, words:3006 92 30da 93 194 30f7 17e ce
Line #7 result - length:16, address:0x2c, words:3027 c3 30fd b8 1e5 1c4 1b9 1cf
Line #8 result - length:16, address:0x34, words:1ba 1c5 3008 d0 30ff bb 30ff c6
Line #9 result - length:16, address:0x3c, words:30ff d1 30c0 bc 30ff c7 30c0 d2
Line #10 result - length:16, address:0x44, words:3008 e8 301a 97 300e 17d c5 301a
Line #11 result - length:16, address:0x4c, words:17e a3 300c 17d be 301a 17e a1
Line #12 result - length:16, address:0x54, words:3004 a4 3001 17d 9c 300b bd 3002
Line #13 result - length:16, address:0x5c, words:17e a5 3002 a6 3002 a7 300f 17d
Line #14 result - length:16, address:0x64, words:c6 8 3181 2166 3180 3180 20fe 3180
Line #15 result - length:16, address:0x6c, words:3180 2020 3180 3181 2154 3180 3181 2186
Line #16 result - length:16, address:0x74, words:3180 3181 215d 3180 3181 2146 3180 3181
Line #17 result - length:16, address:0x7c, words:2124 3180 3181 2137 3180 3180 20e9 3180
Line #18 result - length:16, address:0x84, words:3181 2111 3180 3181 216e 3180 3180 20d4
Line #19 result - length:16, address:0x8c, words:3180 3181 2176 3180 3181 217c 8 140
Line #20 result - length:16, address:0x94, words:180e 2899 1f0 1f1 289d 3004 f0 3000
Line #21 result - length:16, address:0x9c, words:f1 870 17e a4 140 1c0e 28a5 188e
Line #22 result - length:16, address:0xa4, words:28a8 1f2 1f3 28ac 3004 f2 3000 f3
Line #23 result - length:16, address:0xac, words:872 17e 93 140 188e 28b5 1f4 1f5
Line #24 result - length:16, address:0xb4, words:28b9 3004 f4 3000 f5 874 17e a5
Line #25 result - length:16, address:0xbc, words:8 3180 2066 3180 17e 1055 10d5 1155
Line #26 result - length:16, address:0xc4, words:1454 14d4 1554 1453 14d3 1553 14e 1616
Line #27 result - length:16, address:0xcc, words:178b 170b 140 1598 1618 1698 63 28d2
Line #28 result - length:16, address:0xd4, words:3008 17c a5 301c a6 300e a7 3017
Line #29 result - length:16, address:0xdc, words:a8 300e a9 3002 aa 3004 ab 3020
Line #30 result - length:16, address:0xe4, words:ac 1ad 3080 a4 8 3008 17c 91
Line #31 result - length:16, address:0xec, words:301a 92 3002 93 3016 94 3002 95
Line #32 result - length:16, address:0xf4, words:3002 96 3004 97 3020 98 199 3080
Line #33 result - length:16, address:0xfc, words:90 8 300e 17d c5 300f c6 3015
Line #34 result - length:16, address:0x104, words:17e 9e 3040 143 8f 3005 90 18d
Line #35 result - length:16, address:0x10c, words:140 1713 143 1290 8 17c 1af 3015
Line #36 result - length:16, address:0x114, words:b0 3003 b1 301a b2 3003 b3 3002
Line #37 result - length:16, address:0x11c, words:b4 3028 b5 1b6 1b7 3080 ae 8
Line #38 result - length:16, address:0x124, words:17c 19b 301c 9c 300b 9d 300b 9e
Line #39 result - length:16, address:0x12c, words:300b 9f 3001 a0 3008 a1 1a2 1a3
Line #40 result - length:16, address:0x134, words:3080 9a 8 3003 145 90 3011 8f
Line #41 result - length:16, address:0x13c, words:191 30ff 8d 18c 14e 1090 3080 145
Line #42 result - length:16, address:0x144, words:8e 8 3001 14b 92 3002 93 18e
Line #43 result - length:16, address:0x14c, words:18d 18c 191 190 3022 8f 1792 8
Line #44 result - length:16, address:0x154, words:3060 151 8d 18f 191 193 190 192
Line #45 result - length:16, address:0x15c, words:8 3090 153 94 195 3003 96 3005
Line #46 result - length:16, address:0x164, words:97 8 14f 196 197 198 199 19a
Line #47 result - length:16, address:0x16c, words:19b 8 3090 153 90 191 3003 92
Line #48 result - length:16, address:0x174, words:193 8 3088 152 8e 3008 8f 8
Line #49 result - length:16, address:0x17c, words:3003 151 96 3090 95 8 3405 3440
Line #50 result - length:12, address:0x184, words:3400 3401 308c 152 8c 8
Line #51 control - upper address set to 0x10000
Line #52 result - length:10, address:0x8007, words:3fec 3fff 3f9f 3fff 3fff
Area result -
  - 0x0, words:394
  - 0x8000, words:12

#44
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/16 00:58:39 (permalink)
0
Still waiting on Nordic but here's the flashing code now. Data comes in as -

[Address1, len1, data1a, data1b, Address2, len2, data2a, data2b]
 
I couldn't find anything specific to flashing the config data differently and am using the same approach.
 

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

post edited by acharnley - 2020/07/16 01:03:57
#45
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/16 12:51:15 (permalink)
0
Thank you for all the help so far. I'm nearly there!

In fact, I only have one question and if Nordic support becomes active this month I'll be able to get it tested.

I've updated the code to write each Config word one at a time.


  uint16_t pos = 0;
  while (pos != (sizeof(glueFirmware)/sizeof(glueFirmware[0]))) {
    uint16_t baseAddress = glueFirmware[pos];
    loadAddress(baseAddress);
    pos++;
    uint16_t size = glueFirmware[pos];
    pos++;
    uint8_t latches = baseAddress? 1:32;
    while (size) {
      for (uint16_t at=0; at<latches && size; at++) {
        command(0x2); // load nvm, address will auto increment
        sendPayload(glueFirmware[pos]);
        pos++;
        size--;
      }
      // flash latch data
      command(0xE0);
      nrf_delay_ms(8); // TPINT - 10ms covers all cases
    }
  }

 
baseAddress can only be 0x0 or 0x8007. For the question, assume it is 0x0 and there's a full row to be programmed. Inside the for loop the command 0x2 indicates a payload is forthcoming to load into the latch and it'll +1 the address afterwards. This fills the latches but after the loop exits the address is now +32, which means all the latches are aligned to the next row, not the one I'm wanting to target?

I'm assuming a latch doesn't record the address as part of the data load but all set latches are aligned to the address value upon write.
#46
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/16 16:13:25 (permalink)
+1 (1)
acharnley
This fills the latches but after the loop exits the address is now +32, which means all the latches are aligned to the next row, not the one I'm wanting to target?

I'm assuming a latch doesn't record the address as part of the data load but all set latches are aligned to the address value upon write.



That is correct. When you write the last latch of the row, you need to use 0x00 instead of 0x02 to make sure you don't jump to the next page. Then you increment the address after the write.
 
When you write latches, only 5 lower bits of the address matter, everything else is ignored.
 
When you program, the 5 lower bits are ignored. Only the high bits of the address are used to address the page being written. Theoretically, you can load the latches for the whole page, then set a new address and write it to any place you want.
#47
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/17 05:17:13 (permalink)
0
It's not working yet but I have to check the prototype board for issues. I've created a basic program which turns on an LED.
 

:020000040000FA
:04000000803108281B
:100008007E1480317E10090080310A287E1040015C
:1000180080310E28063040019200981612280534C7
:06002800403400340134F5
:020000040001F9
:0A000E00EC3FFF3D9F3FFF3FFF3F27
:00000001FF

 
This gets pumped through the JS script, spat out as a uint16_t array and read in by the nrf52, of which the SPI is now working. The guts of the operation are -
 

  // handshake
  txBuffer[0] = 'M';
  txBuffer[1] = 'C';
  txBuffer[2] = 'H';
  txBuffer[3] = 'P';
  NRF_SPIM0->TXD.MAXCNT = 4;
  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]))) {
    uint16_t baseAddress = glueFirmware[pos];
    uint8_t latches = baseAddress? 1:32;
    pos++;
    uint16_t size = glueFirmware[pos];
    pos++;
    while (size) {
      loadAddress(baseAddress);
      for (uint16_t at=0; at<latches && size; at++) {
        NRF_LOG_INFO("latch %d", at);
        NRF_LOG_FLUSH();
        command(at == latches-1? 0x0 : 0x2); // load nvm, address will auto increment
        sendPayload(glueFirmware[pos]);
        pos++;
        size--;
        baseAddress++;
      }
      // flash latch data
      command(0xE0);
      //NRF_LOG_INFO("wrote");
      NRF_LOG_FLUSH();
      nrf_delay_ms(8); // TPINT - 10ms covers all cases
    }
  }

 
The console output looks correct! (doesn't include MCHP handshake)
 

<info> app: command 80
<info> app: payload 8000
<info> app: command 18
<info> app: command 80
<info> app: payload 0
<info> app: latch 0
<info> app: command 2
<info> app: payload 3180
<info> app: latch 1
<info> app: command 2
<info> app: payload 2808
<info> app: latch 2
<info> app: command 2
<info> app: payload FFFF
<info> app: latch 3
<info> app: command 2
<info> app: payload FFFF
<info> app: latch 4
<info> app: command 2
<info> app: payload 147E
<info> app: latch 5
<info> app: command 2
<info> app: payload 3180
<info> app: latch 6
<info> app: command 2
<info> app: payload 107E
<info> app: latch 7
<info> app: command 2
<info> app: payload 9
<info> app: latch 8
<info> app: command 2
<info> app: payload 3180
<info> app: latch 9
<info> app: command 2
<info> app: latch 10
<info> app: command 2
<info> app: payload 107E
<info> app: latch 11
<info> app: command 2
<info> app: payload 140
<info> app: latch 12
<info> app: command 2
<info> app: payload 3180
<info> app: latch 13
<info> app: command 2
<info> app: payload 280E
<info> app: latch 14
<info> app: command 2
<info> app: payload 3006
<info> app: latch 15
<info> app: command 2
<info> app: payload 140
<info> app: latch 16
<info> app: command 2
<info> app: payload 92
<info> app: latch 17
<info> app: latch 18
<info> app: command 2
<info> app: payload 2812
<info> app: latch 19
<info> app: command 2
<info> app: payload 3405
<info> app: latch 20
<info> app: command 2
<info> app: payload 3440
<info> app: latch 21
<info> app: command 2
<info> app: payload 3400
<info> app: latch 22
<info> app: command 2
<info> app: payload 3401
<info> app: command E0
<info> app: command 80
<info> app: payload 8007
<info> app: latch 0
<info> app: command 0
<info> app: payload 3FEC
<info> app: command E0
<info> app: command 80
<info> app: payload 8008
<info> app: latch 0
<info> app: command 0
<info> app: payload 3DFF
<info> app: command E0
<info> app: command 80
<info> app: payload 8009
<info> app: latch 0
<info> app: command 0
<info> app: payload 3F9F
<info> app: command E0
<info> app: command 80
<info> app: payload 800A
<info> app: latch 0
<info> app: command 0
<info> app: payload 3FFF
<info> app: command E0
<info> app: command 80
<info> app: payload 800B
<info> app: latch 0
<info> app: command 0
<info> app: payload 3FFF
<info> app: command E0

 
If you can spot any problems please let me know, be great to have an extra set of eyes on it.

Thanks! Andrew
#48
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/17 07:57:41 (permalink)
0
You do manipulate the MCLR pin correctly, right?
 
I would suggest writing a small program first which reads the device id. Once it's working, you know that the programming mode entry and other things are correct. This also will give you an ability to read back what you wrote. So you can easily verify the results. Otherwise, there's a lot of stuff which must be correct at the same time and you don't really know what to look at.
#49
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/17 09:24:20 (permalink)
0
Yes the NRF manipulates the MCLR pin, verified this is ok.

So far still nothing so as you say I'll have to do the read.
#50
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/19 05:02:30 (permalink)
+2 (2)
acharnley
Yes the NRF manipulates the MCLR pin, verified this is ok.

So far still nothing so as you say I'll have to do the read.



It is also possible that your SPI mode is incorrect.
 
The smallest you can do is entering the programming mode and the reading back. This is only two operations so not much can go wrong. At the entry the address will be 0 or 0x8000 (I don't know which). Make sure your PIC has non-zero values at these addresses. Then, as soon as you read something which is not zero, it means the PIC responds.
 
#51
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/30 02:22:21 (permalink)
0
IT WORKS!!!!! BOOOOM!
 
Currently having a party in my head! grin: grin
#52
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/30 02:31:34 (permalink)
+1 (3)
Keeping an appropriate social distance from yourself I hope! ;)
 

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!
#53
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/08/13 09:46:57 (permalink)
0
So, I've had to switch to a PIC16F18845 which might or might not mean some changes. I've scoured the programming datasheet and for this chip's low programming memory the timings are compatible. The commands and approach seem to be identical. I've wrote a basic LED on program, verified the LED pin is actually connected and had a go - which was not successful.

I've verified the RESET is being pulled low. One matter is I switched level translator to the one attached. A potential snag is a ramp caused by the 2k resistor as shown by the scope attachment. Would this pose a problem for SPI?

Attached Image(s)

#54
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/08/21 01:39:42 (permalink)
0
Still battling it. I've changed the connection approach to a better version of the first method whereby the PIC receives the same voltage in reset mode. I've verified that the PIC is actually getting the correct voltage and MCLR is pulled low. Schematic attached. Now the CLK/DAT have direct connections so rise/fall isn't an issue.

The most obvious thing to look at is the DAT/CLK connections. I'm reflowing UQFN chips and have verified the pins under microscope. I'm 99.5% certain they are connected.
 
The SPI was working correctly previously and I haven't changed the configuration. The only change necessary is to switch the pin into an input for reading the NVM address.

Common code...


 
 
 
#define TERAB 10 //ms
#define TDLY 5 //us
#define TPINT 8 //ms
#define TENTHS 250 //us
#define TENTS 1 // 100 ns (use 1us)

volatile extern struct statusProto status;
volatile static uint8_t waiton;
volatile uint8_t rxBuffer[3];
volatile static uint8_t txBuffer[4];

static inline void tdly (void) {

  nrf_delay_us(TDLY); // TDLY
}

inline void GLUE_Start (void) {

  NRF_SPIM0->ENABLE = SPIM_ENABLE_ENABLE_Enabled << SPIM_ENABLE_ENABLE_Pos;
  NRF_GPIO->OUTSET = 1 << CFG_PIN_GLUE_RESET; // into reset
  nrf_delay_ms(1);
  NRF_GPIO->OUTCLR = 1 << CFG_PIN_GLUE_RESET; // out of reset
}

void SPIM0_SPIS0_SPI0_IRQHandler (void) {

  waiton = 0;
  NRF_SPIM0->EVENTS_END = 0;
}

static inline void sendBuffer (void) {

  waiton = 1;
  NRF_SPIM0->TASKS_START = 1;
  while (waiton) {
    __WFE();
  }
  tdly();
}

static inline void send (uint8_t length) {

  NRF_SPIM0->TXD.MAXCNT = length;
  sendBuffer();
}

static void command (uint8_t value) {

  NRF_LOG_INFO("command %X", value);
  NRF_LOG_FLUSH();
  txBuffer[0] = value;
  send(1);
}

static void loadAddress (uint16_t address) {

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

static void configureAsOutput (void) {

  NRF_GPIO->PIN_CNF[CFG_PIN_GLUE_DAT] = pinDisconnectInputBuffer | (GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos);
  NRF_SPIM0->PSEL.MOSI = CFG_PIN_GLUE_DAT;
  NRF_SPIM0->PSEL.MISO = SPI_PSEL_MOSI_CONNECT_Disconnected << SPI_PSEL_MOSI_CONNECT_Pos;
}

static uint16_t fetch (void) {

  command(0xFE); // read nvm
  NRF_GPIO->PIN_CNF[CFG_PIN_GLUE_DAT] = (GPIO_PIN_CNF_DIR_Input << GPIO_PIN_CNF_DIR_Pos);
  NRF_SPIM0->PSEL.MOSI = SPI_PSEL_MOSI_CONNECT_Disconnected << SPI_PSEL_MOSI_CONNECT_Pos;
  NRF_SPIM0->PSEL.MISO = CFG_PIN_GLUE_DAT;
  send(3);
  configureAsOutput();
  return rxBuffer[0] << 15 | rxBuffer[1] << 7 | rxBuffer[2] >> 1;
}
 
 
 


To recap, entering programming mode...


 
 
 
 
NRF_GPIO->OUTSET = 1 << CFG_PIN_GLUE_RESET; // into reset

  nrf_delay_us(TENTS);
  NRF_SPIM0->ENABLE = SPIM_ENABLE_ENABLE_Enabled << SPIM_ENABLE_ENABLE_Pos;
  nrf_delay_us(TENTHS);

  // handshake
  txBuffer[0] = 'M';
  txBuffer[1] = 'C';
  txBuffer[2] = 'H';
  txBuffer[3] = 'P';
  send(4);


And reading the deviceid


 
 
 
    loadAddress(0x8006); // deviceid
    uint16_t data = fetch();
 


Breakpointing inside fetch the rxBuffer is 3x 0xff. Any ideas as I've exhausted everything I can think off?
post edited by acharnley - 2020/08/21 02:08:18

Attached Image(s)

#55
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/08/21 05:17:13 (permalink)
+1 (1)
acharnley
Breakpointing inside fetch the rxBuffer is 3x 0xff. Any ideas as I've exhausted everything I can think off?



If the code already worked earlier, then it is correct.
 
Looks like the PGD line is stuck high. There may be many reasons - shorted to something, driven, connected to a wrong place etc.
 
#56
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/08/21 06:58:22 (permalink)
0
I'm 100% sure the connections are fine having had a scope on the tracks. Part of the read issue was reconfiguring the NRF52 pin with the SPI enabled, so I've resolved that and I now get 3x 0x0. As I understand it the PIC works in SPI Mode 0 whereby both CLK and DAT are logic 0 by default. I need to keep it at this default while the SPI is reconfigured.

The program that gets pushed should be lighting an LED on the board but it doesn't, indicating a failure. I've checked the LED pin is connected as well by reverse flow through the protection diode, which shows the PIC's Vdd is connected.

Scoured the programming datasheet and as you say, it's identical. The LED should be on. This is war.
post edited by acharnley - 2020/08/21 07:15:38
#57
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/08/21 07:10:41 (permalink)
+1 (1)
acharnley
I'm 100% sure the connections are fine having had a scope on the tracks. The read issue is perhaps to do with the NRF52 (I may need to disable SPI before reconfiguring which I'm looking into) but the write should be working as it did previously.



Probe the PGD line at various places (starting from the PIC and going all the way to the pin of your programming device) and see at what places you see something and at what place it turns into a constant '1'.
#58
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/08/21 07:36:11 (permalink)
0
Sorry I edited the post above mid-flight. It's now 0, which is something.

Here's the code expanded for reading the device id. Anything obvious?


  NRF_GPIO->OUTSET = 1 << CFG_PIN_GLUE_RESET; // into reset

  nrf_delay_us(TENTS);
  NRF_SPIM0->ENABLE = SPIM_ENABLE_ENABLE_Disabled << SPIM_ENABLE_ENABLE_Pos;
  NRF_GPIO->PIN_CNF[CFG_PIN_GLUE_DAT] = pinDisconnectInputBuffer | (GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos);
  NRF_SPIM0->PSEL.MOSI = CFG_PIN_GLUE_DAT;
  NRF_SPIM0->PSEL.MISO = SPI_PSEL_MOSI_CONNECT_Disconnected << SPI_PSEL_MOSI_CONNECT_Pos;
  NRF_SPIM0->ENABLE = SPIM_ENABLE_ENABLE_Enabled << SPIM_ENABLE_ENABLE_Pos;
  nrf_delay_us(TENTHS);

  // handshake
  txBuffer[0] = 'M';
  txBuffer[1] = 'C';
  txBuffer[2] = 'H';
  txBuffer[3] = 'P';
  send(4);
  nrf_delay_us(TDLY);
 
  // set address
  txBuffer[0] = 0x80;
  send(1);
  nrf_delay_us(TDLY);
  txBuffer[0] = 0x8006 >> 15;
  txBuffer[1] = 0x8006 >> 7;
  txBuffer[2] = 0x8006 << 1;
  send(3);
  nrf_delay_us(TDLY);
 
  // read nvm
  txBuffer[0] = 0xFE;
  send(1);
  nrf_delay_us(TDLY);
  NRF_SPIM0->ENABLE = SPIM_ENABLE_ENABLE_Disabled << SPIM_ENABLE_ENABLE_Pos;
  NRF_GPIO->PIN_CNF[CFG_PIN_GLUE_DAT] = (GPIO_PIN_CNF_DIR_Input << GPIO_PIN_CNF_DIR_Pos);
  NRF_SPIM0->PSEL.MOSI = SPI_PSEL_MOSI_CONNECT_Disconnected << SPI_PSEL_MOSI_CONNECT_Pos;
  NRF_SPIM0->PSEL.MISO = CFG_PIN_GLUE_DAT;
  NRF_SPIM0->ENABLE = SPIM_ENABLE_ENABLE_Enabled << SPIM_ENABLE_ENABLE_Pos;
  send(3);
  nrf_delay_us(TDLY);
  NRF_SPIM0->ENABLE = SPIM_ENABLE_ENABLE_Disabled << SPIM_ENABLE_ENABLE_Pos;
  NRF_GPIO->PIN_CNF[CFG_PIN_GLUE_DAT] = pinDisconnectInputBuffer | (GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos);
  NRF_SPIM0->PSEL.MOSI = CFG_PIN_GLUE_DAT;
  NRF_SPIM0->PSEL.MISO = SPI_PSEL_MOSI_CONNECT_Disconnected << SPI_PSEL_MOSI_CONNECT_Pos;
  NRF_SPIM0->ENABLE = SPIM_ENABLE_ENABLE_Enabled << SPIM_ENABLE_ENABLE_Pos;
  return rxBuffer[0] << 15 | rxBuffer[1] << 7 | rxBuffer[2] >> 1;

#59
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/08/21 10:01:15 (permalink)
+1 (1)
acharnley
Sorry I edited the post above mid-flight. It's now 0, which is something.

Here's the code expanded for reading the device id. Anything obvious?

 
Nothing obvious I can spot. If I were you, I wouldn't edit the code which already worked, but rather look at the connection and electrical things with a scope.
 
#60
Page: < 1234 > Showing page 3 of 4
Jump to:
© 2020 APG vNext Commercial Version 4.5