EEVblog #1144 - Padauk Programmer Reverse Engineering

[DocBen]

In this sequence of the verify it looks like the programmer supplies the adress and then the micro responds with the data.

The micro probably samples on rising edges, the programmer on falling.

Format changes as well, 8bitish for the commands, 14 bitish for the data/adresses -> probably different for different core sizes. (PICs have padding to make it all nice and 16bitish

[DocBen]

Whats a bit weird is that it seems to write during verify also.

I assume that its writing because the clocks after command 0x70 and data are slower than usual (8 clock cycles total).
Also while its reading in address/data fashion, it writes 4 words at a time (5*14=70 bits, one address first I assume)

Maybe its re-writing and re-reading bits that didnt match?

Towards the end there seem to be two runs of the calibration program followed by writes to the calibration bytes.

The last command is also a write, that isnt read back/verified. Maybe a usage counter? Why?

Vpp -> Vdd : 200 us
Vdd -> Data : 1000 us
larger pauses to stabilize voltages?

[socram]

There was a slightly problem while I was exporting the TXT file for processing, apparently the LAP-C program didn't like exporting a 20GB file and crashed before finishing 

So I'm not sure if the file contains all the commands and all the messages. The program doesn't display what percentage of the file it has processed, so I'm not sure how much data was still remaining to be exported.

[DocBen]

There was a slightly problem while I was exporting the TXT file for processing, apparently the LAP-C program didn't like exporting a 20GB file and crashed before finishing 

So I'm not sure if the file contains all the commands and all the messages. The program doesn't display what percentage of the file it has processed, so I'm not sure how much data was still remaining to be exported.

You dont need to export everything, just the command sequences would be fine. At the beginning and end theres blank checking.
There are two phases where data is read and there are shorter phases in between where I think data is beeing re-writen.
Maybe you can just export shorter parts.

You have to set bars and export from bar to bar. But you can only use A and B bar Why?

[socram]

I've just checked by opening the TXT and looking at the timestamps it actually exported everything, from -4864 to 500936754.

[js_12345678_55AA]

Great findings from all of you.

I think it's time to test some of the observations. I will start with the VERIFY (READ).

I will assume that VDD/VPP = 3.3V will be ok for this. Then I just can connect the input/output of the host MCU to padauk IC directly.

After looking at the different bit counts for input / output transmissions which can not be mapped to 8 bit I think using the hardware SPI of host MCU will not work out well.

This means I will try to bit bang the protocol with a tight loop (might be hard when capturing input from IC assuming 1MHz clock).

JS

[DocBen]

I will assume that VDD/VPP = 3.3V will be ok for this. Then I just can connect the input/output of the host MCU to padauk IC directly.

I'm not sure this will work.
The sequence must probably be observed:
Apply Vpp (5.6V) before Vdd (2.6V) (thats the same as with PICs)    -> select programming mode, command phase
Send command
Change Vdd to 4.3V to read data   -> data phase

I think theres a voltage dependent state machine at work that tells the micro what to do.

[socram]

Maybe it does, or maybe it just relies on the order rather than actual voltages. I think it's worth looking before proceeding with designing the programmer.

[js_12345678_55AA]

First test result:

VPP 3.3V seems NOT to work. IC starts exactly same as when VPP is not applied (52.40ms till blink out starts on PA.3)

Need to add transistor now to toggle 5V.

[socram]

First test result:

VPP 3.3V seems NOT to work. IC starts exactly same as when VPP is not applied (52.40ms till blink out starts on PA.3)

Need to add transistor now to toggle 5V.

I'd try 3.3V on VDD rather than VPP.

[js_12345678_55AA]

I did some experiments.

Everything up to 5.5V on VPP (PA.5) is ignored (this is maximum rating in IC data sheet for VDD and pins) and IC starts up normally.

As soon >5.6V (tested up to 12V) is present on VPP (PA.5) the startup of the IC is different (I guess programing/command mode).

Need to hook up logic analyzer to bread board now.

JS

[js_12345678_55AA]

FIRST BIG SUCCESS...

After some try and error I completed Level1  : CLOCK is ALWAYS sent from WRITER.

- a command is sent with preamble 0xA5A5A5A followed by 8 bit COMMAND
- after last bit from command was sent DATA switches directions
- IC sends back 0xAA and 4 bit status (maybe something like this: b0001 = ok, b0000 = error), clock must be supplied by WRITER

This only works with VPP > 5.5 V.

JS

EDIT: 3.3V was used for VDD.

[socram]

Great job! The IC seems to be sampling the data pin on falling edge, then, is that right?  While it seems the incoming data must be sampled on the rising edge.

[js_12345678_55AA]

Great job! The IC seems to be sampling the data pin on falling edge, then, is that right?  While it seems the incoming data must be sampled on the rising edge.

Not there yet ... in command mode it looks like I can sample either on rising or on falling edge.

Could you describe the READ command (0x60) in detail?

>A5A5A5A60
<AA1

>? ? ?
<? ? ?
...

JS

[DocBen]

>A5A5A5A60
<AA1

>? ? ?
<? ? ?

AFAICT the programmer supplies the address of the location it wants to read (looking at the dutycycle of the clock) see the picture in my post December 31, 2018, 08:51:59 pm.
Starting with 0 and counting up. 14 bit address from the programmer, then 14 bits of data are returned by the micro.
I guess the clock is supplied by the programmer.

[DocBen]

Maybe the vdd voltage has to be changed as well. From 2.6V to 4.3V.
Might be important for the micro to distinguish between command and data modes.
However might not be as sensitive to the actual voltage as I thought, so maybe 2.5V and 5V is fine.
Or no change at all

[socram]

Not there yet ... in command mode it looks like I can sample either on rising or on falling edge.

Could you describe the READ command (0x60) in detail?

Sure.

Code: [Select]

Enter read mode:
>A5A5A5A61 (36 bits)
<1010 1010 0001 0 (13 bits)

Voltage is on VDD now raised to 4.3V

Read word:
>address (13 bits)
<word (14 bits)
>unknown, seemingly always 1 (1 bit)Note command seems to be 61 instead of 60, or at least that what I got from the 200 MHz dump, and from previous using the "sticky" (ie one if it's high on either falling or rising) approach.

[DocBen]

Maybe the last bit is just an ACK?
If you supply an adress outside of the chips memory range > 2048 for the PFS154 maybe it returns 0?

Maybe thats the stop condition for a read? Edit: Nope.

[socram]

Write command format, in case you want to try it:

Code: [Select]

>A5A5A5A71 (36 bits)
<1010 1010 0001 0 (13 bits)

VPP is raised to 8.3V

<word1 (14 bits)
<word2 (14 bits)
<word3 (14 bits)
<word4 (14 bits)
<address (13 bits)
<000000000 (padding? not sure about the direction of this one - 9 bits)

[DocBen]

<000000000 (padding? not sure about the direction of this one - 9 bits)

Thats probably just something to get the micro to program the locations after the data has been supplied.

There's also a one right before that that appears on the data line but is not accompanied by a clockcycle. Dont know whats that for or if its even important.

Also shouldn't it be >word above?

[js_12345678_55AA]

Level 2 done... complete readout.

Attached the logic analyzer capture from the readout. I decreased some stupid delays and did not make the song and dance at the beginning. Just send command 0x60 and then read data.

Summary:
VPP: 5.6V
VDD: 3.3V
>0xA5A5A5A
>0x60
<0xAA1
>0x0000  (14 bit addr)
<0x0070  (14 bit data)
>0x0001  (14 bit addr)
<0x2F00  (14 bit data)
...
>0x07FF  (14 bit addr)
<0x31FD (14 bit data)
VDD: 0V
VPP: 0V

 

JS


EDIT: I'm tempted to set security bit.... and try again ;-)

EDIT2: It was not working when using 13 bit address... not sure why. Maybe clock style is wrong or pullup/down or ... is needed?

EDIT3: Reading from address 0x800 ... returns same as 0x000 ... (so address just wraps around)

[js_12345678_55AA]

Write command format, in case you want to try it:

Code: [Select]

>A5A5A5A71 (36 bits)
<1010 1010 0001 0 (13 bits)

VPP is raised to 8.3V

<word1 (14 bits)
<word2 (14 bits)
<word3 (14 bits)
<word4 (14 bits)
<address (13 bits)
<000000000 (padding? not sure about the direction of this one - 9 bits)

This is next I will try... (tomorrow maybe).

> VPP is raised to 8.3V

What I found out... READ is also working with VPP 8.3V and VPP 12.0V  so maybe just 12V VPP is needed :-) ?

JS

[DocBen]

Write command format, in case you want to try it:

Code: [Select]

>A5A5A5A71 (36 bits)
<1010 1010 0001 0 (13 bits)

VPP is raised to 8.3V

<word1 (14 bits)
<word2 (14 bits)
<word3 (14 bits)
<word4 (14 bits)
<address (13 bits)
<000000000 (padding? not sure about the direction of this one - 9 bits)

This is next I will try... (tomorrow maybe).

> VPP is raised to 8.3V

What I found out... READ is also working with VPP 8.3V and VPP 12.0V  so maybe just 12V VPP is needed :-) ?

JS

That would also simplify voltage regulation significantly.
Just double (triple) Vdd and apply to Vpp. (Does it really need to be 8.3V )
That can be done with a charge pump.

[socram]

Could you please try also with 0x61? I wonder why I'm getting that if it's 0x60.

[js_12345678_55AA]

Could you please try also with 0x61? I wonder why I'm getting that if it's 0x60.

OK, tested 0x60, 0x61, 0x62, ... 0x6F ... all same result: VALID READ 

=> seems command is just 0x6  and then 4 dummy clocks are used before switching mode (the 4 clocks are really needed, I thought maybe preamble 28 bit + 4 bit command = nice 32 bit... but nope)

JS