EEVblog #1144 - Padauk Programmer Reverse Engineering

[spth]

Yes, I meant mov, not ld.

The push af is curently just used to cheaply increase sp by 2. But If I knew which byte a goes into, it could be used to at the same time write one of the bytes I want on the stack.

Philipp

[DocBen]

Yes, I meant mov, not ld.

The push af is curently just used to cheaply increase sp by 2. But If I knew which byte a goes into, it could be used to at the same time write one of the bytes I want on the stack.

Philipp

But then you dont need the pushaf/popaf at all and youre down to six instructions anyway

Code: [Select]

mov a, op0
idxm sp, a
inc sp
mov a, op1
idxm sp, a
inc sp


[spth]

But then you dont need the pushaf/popaf at all and youre down to six instructions anyway

Code: [Select]

mov a, op0
idxm sp, a
inc sp
mov a, op1
idxm sp, a
inc sp


sp is in IO space, so there is no inc sp, and no idxm sp, a.

Philipp

[DocBen]

ok now i get you would like to do something like this:

Code: [Select]

mov a, sp
mov p, a
mov a, op0
pushaf
inc p
mov a, op1
idxm p, a


[DocBen]

you could of course also do

Code: [Select]

mov a, op0
pushaf
mov a, op1
pushaf


[DocBen]

I looked at the PMC884 datasheet and you really cannot infer the positions on the stack.

        word          data0  ;                        //  declare  data0 in RAM
        word          data1  ;                        //  declare  data1 in RAM
        ...
mov       a, 0x55 ;
mov       ld@data0,  a  ;            //  move  0x55  to  data0 (LSB)
mov       a, 0xaa ;
mov       hd@data0, a  ;          //  move  0xaa  to  data0 (MSB)
pushw   data0  ;                      //  move  data (0xaa, 0x55) to stack memory (word)
popw     data1  ;                      //  move  (0xaa,  0x55)  in stack memory to data1 (word)
mov       a,  ld@data1  ;            //  ACC=0x55
mov       a,  hd@data1  ;            // ACC=0xaa

[DocBen]

Updated disassembler with 15 bit instruction set support.

Linux and Windows binaries included.

There seems to be a small problem with the io.txt file for the 15-bit core: some of the ios are no longer named (PFS173 startup code). PFS154 and test pdks previously included work fine.

Code: [Select]

001D  3F10  set1      .6
001E  0063  dzsn      a
001F  601E  goto      0x001E
0020  2300  dzsn      M0
0021  601E  goto      0x001E
0022  3B10  set0      .6
0023  3190  t0sn      .3
0024  6023  goto      0x0023
0025  5701  mov       a, 0x01
0026  3290  t0sn      .5
0027  57FF  mov       a, 0xFF
0028  1801  add       a, M1
0029  010B  mov       IHRCR, a
002A  1701  mov       M1, a
002B  3590  t1sn      .3


[spth]

I looked at the PMC884 datasheet and you really cannot infer the positions on the stack.

        word          data0  ;                        //  declare  data0 in RAM
        word          data1  ;                        //  declare  data1 in RAM
        ...

From the startup code and the description of idxm one can infer that the Padauks are little endian, so the byte order for pusw in the 16-Bit instruction set should be the same. But push af is a different matter. Doing push af twice won't push a 16-Bit value onto the stack. It pushes two 16-bit vales, and the two a value bytes are apart, so I can't use that to push a 16-bit value.

[DocBen]

From the startup code and the description of idxm one can infer that the Padauks are little endian, so the byte order for pusw in the 16-Bit instruction set should be the same. But push af is a different matter. Doing push af twice won't push a 16-Bit value onto the stack. It pushes two 16-bit vales, and the two a value bytes are apart, so I can't use that to push a 16-bit value.

No. idxm only moves a single byte from an index that is word aligned. So 16-bit address, 8-bit data (A isnt 16-bits), two idxm's for one 16-bit operand.
I thought op0 is the low byte and op1 the high byte of op.

So still two pushaf's will push the low and high byte but not consecutive in memory which doesnt matter that much because most people wont be doing deeply nested loops or recursion on these things. Also its guranteed to work no matter what the actual design is.

So this should work:

Code: [Select]

word op;
....
mov a, ld@op //low byte of op
pushaf
mov a, hd@op //high byte of op
pushaf
...
popaf
mov hd@op, a
popaf
mov ld@op, a


[DocBen]

quick question about the ice:

is there a device driver disk or something?
The downloadable IDE doesnt install a driver somewhere does it?

[js_12345678_55AA]

Hi,

the ICE and the WRITER use USB-HID to communicate. USB-HID is not the fastest option... but it does not need any driver on Windows/Linux/Mac/...

JS

[DocBen]

Ok, then I need to figure out how to get the firmware onto the naked dev boards I got today.

[DocBen]

Also raises the interesting question what the P5SP firmwares are.
The firmware for the Cypresschip (*HID I presume) has about the right size for the chip, but the P5SP* files are ten times as large and wouldnt fit.

Maybe the socketed chip is a microcontroller after all and not an FPGA 

[DocBen]

Ok so I have found the bytes that need to be programmed at the start of the eeprom on the ICE close to the Cypress Chip:

C2 97 07 02 70 01 80 04 // this should be the ICE VID: 0797 PID: 7002 Revision/DID: 8001

C2 B4 04 04 10 01 A0 04 // This is the bulkloop firmware example from Cypress

C2 97 07 01 70 01 00 04 // ? with the controller loading the program from the EEPROM

C0 97 07 01 70 01 00 04 // ? EEPROM only holds VID/PID

Also something firmware ish is contained in FPPA_IDE.exe between 0x22af9c and 0x22ce77 (<- uncertain about the end and whether there might actually be two different firmwares here, also weird mix of .bin and .iic formats)

[oPossum]

There seems to be a small problem with the io.txt file for the 15-bit core: some of the ios are no longer named (PFS173 startup code). PFS154 and test pdks previously included work fine.

CR/LF line termination was not handled properly on the Linux version. Fixed.

[amyk]

A good starting point to see what I mean might be this datasheet for old PIC16C7XX OTPs
(although the padauks will probably behave differently I guess its reasonable to assume for now that their approach is similar)

http://ww1.microchip.com/downloads/en/DeviceDoc/30298d.pdf

I think they're more complex than that --- the PIC only uses the high voltage to enter programming mode and then it's just data/clock. In the video you can see more voltage levels than that.

[DocBen]

I think they're more complex than that --- the PIC only uses the high voltage to enter programming mode and then it's just data/clock. In the video you can see more voltage levels than that.

On the PICs its not just the high voltage:
"The  Program/Verify  mode  is  entered  by  holding  pins RB6 and RB7 low, while raising MCLR pin from VSS to the appropriate VIHH (high voltage). VDD is then raised from  VSS to  the  appropriate  VDD level.  Once  in  this mode, the user program memory and the configuration memory  can  be  accessed  and  programmed  in  serial fashion. "

The Padauks are different, but I dont think that we need the full waveform to be captured.
Just the maybe 30 - 40 cycles after each rise of VDD. The mode select is probably a combination of analog voltage levels and commands.
Also its much easier to trigger on a rising edge so the timinig issues that David was having shouldnt be that much of a problem.

There arent that many voltage levels either (I assume that VPP is supplied at pin PA5 and freely adjustable within the range below).

0x63421c 70 69 Please remove all IC, and check VDD,\nVPP(PA5), PA0 / 3 / 4 / 7 is 0 V
0x634264 30 29 Please check VPP (PA5) = 4.6V
0x634284 31 30 Please check VPP (PA5) = 11.3V
0x6342a4 24 23 Please check VDD = 5.5V
0x6342bc 24 23 Please check VDD = 7.5V
0x6342d4 24 23 Please check VDD = 3.3V

But unfortunately I dont have a programmer.

[FrankBuss]

The Padauks are different, but I dont think that we need the full waveform to be captured.
Just the maybe 30 - 40 cycles after each rise of VDD. The mode select is probably a combination of analog voltage levels and commands.
Also its much easier to trigger on a rising edge so the timinig issues that David was having shouldnt be that much of a problem.

There are different voltages on more pins than just VDD. But my board is routed now, will get the parts today, then I can print out the board to test for footprint errors and will get the final PCB in less than 2 weeks. Might be very useful for other things as well. I can connect two of these boards to a DE10 Nano. Then I have 8 analog (-10 V to +10 V) 8 bit channels with 50 MHz sample rate each, 1 GB sample memory, a FPGA and Linux on the board to pre-process the data if necessary, and gigabit ethernet to stream it in real time to a PC (at least 10 MHz samplerate with 8 channels should be possible in this mode).

[DocBen]

There are different voltages on more pins than just VDD.

Do they have the same level as VDD?

Some pins just have short pulses for blank checking.

If I interpret the strings FPPA_IDE.exe correctly only VDD, VPP(PA5) and PA0 / 3 / 4 / 7 (plus GND obviously) are used.
The smallest chip I could find (PMS150C-U06) only has VDD, PA5, GND and 4/3 as well as 6.
So 3 (clock) and 4 (data) and thats it. (which also support Davids findings in the video for the PMC150C SO8)
And if remember correctly PA6 is used for that bit banging calibration thing.

[FrankBuss]

Right, the voltage levels might be identical on VDD and the data pins. At least it was about 6.5 V for some data lines when I tested it:

https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg1986377/#msg1986377

Maybe looking at the programmer circuit board might help with this, too, and the programmer firmware.

[DocBen]

I still think the areas with 6.5V VDD are for verification purposes, there should also be parts close to 2V,
however from the current PMS150C datasheet:
Supply  Voltage 2.0V ~ 5.5V (Maximum Rating: 5.5V) *If VDD over maximum rating, it may lead to a permanent damage of IC.

I quote again from the PIC datasheet:
Programming Algorithm Requires Variable VDD
The  PIC16C7XX  uses  an  intelligent  algorithm.  The algorithm  calls  for  program  verification  at  VDDMIN  as well  as  VDDMAX.  Verification  at  VDDMIN
  ensures  good “erase  margin”.  Verification  at  VDDMAX ensures  good “program margin.”  The actual programming must be done with VDD in the VDDP
 range (4.75 - 5.25V). VDDP=VDD range required during programming. VDDMIN = minimum operating VDD spec for the part. VDDMAX = maximum operating VDD
 spec for the part. Programmers must verify the PIC16C7XX at its specified VDDMAX and VDDMIN levels. Since  Microchip may introduce  future  versions  of  the  PIC16C7XX  with  a broader V
DD range, it is best that these levels are user selectable (defaults are ok).
Note:
Any    programmer    not    meeting    these requirements  may  only  be  classified  as “prototype” or “development” programmer, but not a “production” quality programmer.

[js_12345678_55AA]

Hi,

I wrote a little program to find out how LDSPTL/LDSPTH are truly working.

The program uses LDSPTL/LDSPTH to dump the IC content and send it out via a soft spi. Then I used a STM32 and created a small capture program for the SPI which sends it to my computer via USB-Serial-Port.

First I checked flags by loading 0x00 to flags register, then execute the opcode, then output the content of flag register over spi, afterwards I loaded 0xFF to flags register and tried again.
Result: LDSPTL/LDSPTH do not alter any flags

Then I made a loop to dump the content of a PMS154B by setting SP to mem:0 and then incrementing the 16 bit value in mem:0 and mem:1.
Result: I got a complete dump of the code memory.
Upper bits of LDSPTH are reading 0 -> dump reads exactly same as content of PDK file (0x3FFF reads as 0x3FFF)
When the address in SP (can hold 16 bits) exceeds the code memory, the address just wraps around and starts reading from 0 again (NO CRASH)


Bonus: It also became visible what WRITER did to the last 32 reserved bytes in memory 

PDK-DATA last 32 bytes:

0000fe0: ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f
0000ff0: 00 00 00 00 ff 3f ff 3f ff 3f ff 3f ff 3f 51 11

Dump from PMC154B last 32 bytes:

0000fe0: ff 3f ff 3f ff 3f ff 3f ff 3f ff 3f 5a 02 ff 3f
0000ff0: 2d 34 a5 3e ff 3f ff 3f ff 3f ff 3f 48 02 51 11

GREAT FUN! (just spent 3 cent )

JS

UPDATE:
More notes about "last 8 Words", security bit, ... here:
https://github.com/free-pdk/fppa-pdk-documentation/blob/master/Reserved_Area_Last_8_Words_Of_Codemem.txt

UPDATE:
Special code found and guessing what it can be here:
https://github.com/free-pdk/fppa-pdk-documentation/blob/master/SpecialCodeFoundInPMS154B.txt

[js_12345678_55AA]

Hi,

I finally got the time to use a logic analyzer (ZeroPlus Logic Cube LAP-C322000) to capture the writing of a program on a PFS154.

I had to "modify" the logic analyzer first: was a LAP-C16032 ($100, 32kBit, can soft mod to 128 kBit) => swap SRAM => is now a LAP-C162000 / LAP-C322000 (4MBit) ( https://hackaday.com/2010/03/30/zeroplus-logic-cube-modification/ ) 

The logic analyzer allows -30V / +30V on logic pins, so capturing the expected 0V - 12V from WRITER was no problem.
Later, after deciphering the logic of the flashing protocol it will be easy to measure and reapply the real voltages for programing.
On oscilloscope it looks like PA5 receives the programing voltage of up to 12V during writing and VDD receives a slightly higher voltage >= 6.5V (maybe for reading the IC).


So first I created a PDK from my "SimpleBlink" demo and used WRITER to "CONVERT" it to a different "PACKAGE" which lets you disable the PIN CHECK (WRITER will check for all pins to have no short) which is not required for programing.
(The PDK without the pin check is attached to this post)

Then I used WRITER to write it to a PFS154 using a "PADAUK P-003". The logic analyzer was connected to JP3 on bottom side of programmer (A0 = pin 1 of JP3) and logic analyzer GND was connected to a ground pin on programmer PCB.

You can see some screen shots of the capture below (focus on first data block, zoomed in, zoomed in more).
I grouped CLK and DATA into a BUS (SPI) so the software tried to decode some bits... unfortunately it seems a non standard 8 bit transmissions is used.

It looks like PADAUK ICs enter programing mode if PA5_ICVPP is present before VDD is applied. 


Since the ZeroPlus software requires a logic analyzer to be present I exported the captured data to a simple text file of 117 MB, compressed to 1MB 7-Zip (requires recent version of 7-Zip since LZMA2 is used to make it so small, hidden in a normal ZIP since forum does not allow .7z files).
The file contains all details about the capture (2MHz seems to be enough, I tried with 100MHz but did not see any pulses < 100 units)

As always,

Have fun!

JS

[DocBen]

You can see some screen shots of the capture below (focus on first data block, zoomed in, zoomed in more).
I grouped CLK and DATA into a BUS (SPI) so the software tried to decode some bits... unfortunately it seems a non standard 8 bit transmissions is used.

I guess the problem is that the clock is rather random (ie software generated, decision path dependent)
If I count the bits by hand I get
10100101   A5
10100101   A5
10100101   A5
10100110   A6
00011010   1A
10100001   A1

for the last picture.
Maybe thats A5: enter programming mode (could also be increase address), A6: write value (followed by value, is 1A the value for the configuration bits?), A1: program value followed by pause (self timing programming?)

[js_12345678_55AA]

Hi,

I analyzed a bit more of the capture and could observe the following:

- first PA.5 is set to high (not sure which voltage is applied since logic analyzer does not provide this info, will find out later)

- 100µs later VDD is set to high (not sure which voltage is applied since logic analyzer does not provide this info, will find out later)

- 500µs later PA.3 (CLK) and PA.6 (DAT) are used to send 48 bit of data:  1010010110100101101001011001cccccccc10101010001 (A5A5A5A*CMD-BYTE*AA1) Note: AA1 might be from OTP-ID 2AA1 ?

- depending on command
 * no response expected:
   - 100µs later VDD is set to low
   - 250µs later PA.5 is set to low

 * response expected:
   - maybe DAT/CLK changes direction (driven by IC now)? --> any idea how to find out who is sending IC or WRITER?
   - response length depending of command
   - 100µs later VDD is set to low
   - 250µs later PA.5 is set to low

****

Following in this order been sent:

0x61 / no response (maybe writer stops after getting no response or does not even wait for response)
0x61 / response: 00111110111101111111111110000111111100000000000000011100011111110001000000000001111 (3F7BFFC3F8000E3F8800F)

0x31 / response: 0000 (very slow clocking)

0x66 / no response (execution time is very long before VDD/PA.5 going low)

0x70 / additional send data: 000000000010001111111111111111111111111111111111111111110011111110000 0 0 0 0 0 0 0 0 (last bits slow clocking) (4x 14bit data: 0x0008, 0x3FFF, 0x3FFF, 0x3FFF , 0x3F8 0 0..)

0x61 / no response (maybe writer stops after getting no response or does not even wait for response)

0x71 / additional send data: ( multiple times:  (4 x 14 bit data, ADR, slow clocks to process) )

0x61 / no response (maybe writer stops after getting no response or does not even wait for response)
0x61 / no response (maybe writer stops after getting no response or does not even wait for response)
0x61 / response: ...
0x61 / no response (execution time is very very very long VDD/PA.5 going low, seems DAT pulses without CLK from IC extend waiting period)

0x70 / additional send data: ( multiple times:  (4 x 14 bit data, ADR?, slow clocks to process) )
0x70 / additional send data: ( multiple times:  (4 x 14 bit data, ADR?, slow clocks to process) )

0x61 / response: ...

0x60 / response: multiple times: (14 bit data)

0x61 / no response (maybe writer stops after getting no response or does not even wait for response)

0x60 / no response (maybe writer stops after getting no response or does not even wait for response)

0x70 / additional send data: ( multiple times:  (4 x 14 bit data, ADR, slow clocks to process) )

****

- now IC is booted normally (PA.5 stays low, VDD is set to high)

- at this point it looks like the "calibration code" is executed
  # PA.5 is set high
  # PA.4 + PA.7 output high some clocks later
  lot of PA.4/PA.3 communication is done ...

- after some time VDD is set to low (IC shutdown)

****

- calibration is run again

****

0x71 / additional send data: ( multiple times:  (4 x 14 bit data, ARD?, slow clocks to process) )

0x61 / response: ...

0x60 / no response (maybe writer stops after getting no response or does not even wait for response)

0x71 / additional send data: ( multiple times:  (4 x 14 bit data, ADR?, slow clocks to process) )

****

ALL DONE



Looks like:
 0x60/0x61 might be GET_STATUS or READ
 0x70/0x71 might be WRITE
 0x31 might be ERASE
 0x66 might be CHECKBLANK


Time to write a parser for this 

Have fun,

JS