Author Topic: EEVblog #1144 - Padauk Programmer Reverse Engineering  (Read 66917 times)

icraftcrafts and 2 Guests are viewing this topic.

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #300 on: December 31, 2018, 07:18:53 am »
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 ;)
« Last Edit: December 31, 2018, 10:18:40 am by DocBen »
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #301 on: December 31, 2018, 09:51:59 am »
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?
« Last Edit: December 31, 2018, 10:00:12 am by DocBen »
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #302 on: December 31, 2018, 10:07:59 am »
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  ;D

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.
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #303 on: December 31, 2018, 10:21:54 am »
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  ;D

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?
« Last Edit: December 31, 2018, 10:26:40 am by DocBen »
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #304 on: December 31, 2018, 11:03:33 am »
I've just checked by opening the TXT and looking at the timestamps it actually exported everything, from -4864 to 500936754.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #305 on: December 31, 2018, 12:38:19 pm »
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
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #306 on: December 31, 2018, 12:53:43 pm »
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.
« Last Edit: December 31, 2018, 12:55:25 pm by DocBen »
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #307 on: December 31, 2018, 01:09:01 pm »
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.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #308 on: December 31, 2018, 05:06:10 pm »
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.
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #309 on: December 31, 2018, 06:03:21 pm »
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.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #310 on: January 01, 2019, 03:25:17 pm »
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
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #311 on: January 01, 2019, 06:32:44 pm »
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.


« Last Edit: January 01, 2019, 06:49:21 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: oPossum, GonzoTheGreat, DocBen, rhodges

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #312 on: January 01, 2019, 07:09:48 pm »
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.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #313 on: January 01, 2019, 07:36:17 pm »
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
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #314 on: January 01, 2019, 08:20:08 pm »
>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.
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #315 on: January 01, 2019, 08:24:53 pm »
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 ;)
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #316 on: January 01, 2019, 08:35:59 pm »
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.
« Last Edit: January 01, 2019, 08:40:36 pm by socram »
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #317 on: January 01, 2019, 08:46:36 pm »
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.
« Last Edit: January 02, 2019, 05:26:16 am by DocBen »
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #318 on: January 01, 2019, 09:02:47 pm »
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)
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #319 on: January 01, 2019, 09:49:35 pm »
<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?
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #320 on: January 01, 2019, 10:14:21 pm »
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

 8) 8) 8) 8) 8)

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)
« Last Edit: January 01, 2019, 10:28:35 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #321 on: January 01, 2019, 10:18:10 pm »
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
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline DocBen

  • Regular Contributor
  • *
  • Posts: 111
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #322 on: January 01, 2019, 10:27:02 pm »
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.
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #323 on: January 01, 2019, 10:29:46 pm »
Could you please try also with 0x61? I wonder why I'm getting that if it's 0x60.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #324 on: January 01, 2019, 10:39:37 pm »
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
Easy PDK programmer and more: https://free-pdk.github.io
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf