Skip to main content
Topic: PIC programming adapter problem (Read 22270 times) previous topic - next topic

Re: PIC programming adapter problem

Reply #30
I guess we are getting a little sidetracked here...

Regarding the actual topic: I downloaded the whole svn for BP, the program under scriptsHVPselftest does not even compile as some header files are missing. That led me to search the actual directory, which is scriptspowertoolsHVPselftest. I've tested my adapter a couple of times, I guess we just need to synch those who folders or get rid of one of them. Can you also try the one I pointed udif?

Re: PIC programming adapter problem

Reply #31
I have nothing to add here except to say ready these three pages was glorious geek pr0n, and also I think the last of 5 pages of unread form posts I had to get through today ;)
Got a question? Please ask in the forum for the fastest answers.

Re: PIC programming adapter problem

Reply #32
A quick update.
I've streamlined the code a bit, according to the suggestions here.
The code still behaves the same though, and I hope to take a look using a Logic Analyzer later today.

Re: PIC programming adapter problem

Reply #33
Looks much better :-) Should i wait till the fuse writing is working?

http://ww1.microchip.com/downloads/en/D ... 39622L.pdf

Programming specification states that you should set all the TBLPRTx registers.

So the fuse writing code would be like:
Code: [Select]
setup fuse write:
iface->PIC416Write(0x00, 0x8EA6); //setup PIC - BSF  EECON1, EEPGD
iface->PIC416Write(0x00, 0x8CA6); //setup PIC - BSF  EECON1, CFGS
// set table ptrs
iface->PIC416Write(0x00, 0x0e30); //movlw 0x30
iface->PIC416Write(0x00, 0x6ef8); //movwf TBLPTRU
iface->PIC416Write(0x00, 0x0e00); //movlw 0x00
iface->PIC416Write(0x00, 0x6ef7); //movwf TBLPTRH

cycle through fuses:
the same thing you have.
If this won't help, only analyzer will.

Page 10 suggest that you have only 8 (16bit config words), thats 16writes.

Re: PIC programming adapter problem

Reply #34
[quote author="robots"]Looks much better :-) Should i wait till the fuse writing is working?
[/quote] Probably Yes, it will only be 1-2 more days, and currently the code adds no functionality beyond my previous patch, that already added code read/write ability for the 18F2553.

[quote author="robots"]http://ww1.microchip.com/downloads/en/DeviceDoc/39622L.pdf

Programming specification states that you should set all the TBLPRTx registers.
[/quote]
The link to the document is naturally the same one I'm looking at.
I don't think the document says I need to set all 3 TBLPRTx registers between writes.
I think the note on section 3.6 regarding setting the full address only relates to not using the 0xD command (write 2 bytes and post-increment).
I set all 3 TBLPRTx registers at the beginning, then for the next configuration writes, set only the new low address. I think this is consistent with their example as well. Even/Odd writes are separate, and they change only the lowest address register between writes.
In any case, if I will test this as well, just to be sure (this should be quick).
[quote author="robots"]So the fuse writing code would be like:
Code: [Select]
setup fuse write:
iface->PIC416Write(0x00, 0x8EA6); //setup PIC - BSF  EECON1, EEPGD
iface->PIC416Write(0x00, 0x8CA6); //setup PIC - BSF  EECON1, CFGS
// set table ptrs
iface->PIC416Write(0x00, 0x0e30); //movlw 0x30
iface->PIC416Write(0x00, 0x6ef8); //movwf TBLPTRU
iface->PIC416Write(0x00, 0x0e00); //movlw 0x00
iface->PIC416Write(0x00, 0x6ef7); //movwf TBLPTRH

cycle through fuses:
the same thing you have.
If this won't help, only analyzer will.

Page 10 suggest that you have only 8 (16bit config words), thats 16writes.[/quote]

I'm more worried about the write delay as set by the Bus Pirate. It is defined to be 1ms, which is what the spec says, with no safety margins.I'll take a look with the OLS to see what the actual delay is.

Re: PIC programming adapter problem

Reply #35
I think you can commit the changes.

After all my efforts have made no change on the result (set full tblptr on each write, increase write delay to 2ms, etc.) I decided to take a close look at the actual data.
Here is the relevant data from the diolan bootrom:
Code: [Select]
:020000040030CA
:0100000021DE
:010001004EB0
:0100020038C5
:010003001EDE
:010005008377
:010006008178
:010008000FE8
:01000900C036
:01000A000FE6
:01000B008074
:01000C000FE4
:01000D0040B2
:00000001FF
Here is the same data, read back from the 18F2553:
Code: [Select]
:020000040030CA
:0E000000214E011E0083C4000FC00F800F4070
:00000001FF
At first, I noticed that the fist two bytes were and the last 6 bytes Identical, but not the middle bytes. I couldn't explain the other difference.

Then last night I noticed for the first time that the original Hex file skipped some addresses, namely 0x300004 and 0x300007.
Earlier, before I noticed this, I thought some of the data was written to the wrong locations (specifically, 0x83 at 0x300005), when in fact it was OK . Those undefined addresses are indeed read as 0x00, as defined by the spec.

This leaves me with 0x300006 (CONFIG4L) that is read as 0xc4 when written as 0x81, and 0x300002 (CONFIG2L) that is read as 0x01 when written as 0x38). I now believe this is something specific to these registers and my specific PIC type, the 18F2553.

Maybe someone who has more PIC experience than me can explain why?

Re: PIC programming adapter problem

Reply #36
[quote author="udif"]This leaves me with 0x300006 (CONFIG4L) that is read as 0xc4 when written as 0x81, and 0x300002 (CONFIG2L) that is read as 0x01 when written as 0x38). I now believe this is something specific to these registers and my specific PIC type, the 18F2553.

Maybe someone who has more PIC experience than me can explain why?[/quote]
There are some unused bits in all config registers, thought it may be related to that but the thing is there are some weird stuff going on. For example for CONFIG4L, written value is OK, but you are reading bit4 as 1 whereas unimplemented bits are read as 0. See 18F2550 datasheet (18F2553 datasheet points me there) Table 25-1

 

Re: PIC programming adapter problem

Reply #37
I have committed the code into SVN, also added few checks, fixed compiler warning, removed some unused code, renamed DataByte and Data , to databyte and data.