EEVblog #1144 - Padauk Programmer Reverse Engineering

[socram]

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

That seems correct. It looks like the writer itself is using 0x67 at some point for reading in place of 0x61 and 0x60.

[DocBen]

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.

I tried to replicate your experiment with the 0x60 command (minus powercycling I just switch it on), but I only have blank chips.
They dont respond at all.

Could you try with a blank chip?

[js_12345678_55AA]

I tried to replicate your experiment with the 0x60 command (minus powercycling I just switch it on), but I only have blank chips.
They dont respond at all.

Could you try with a blank chip?

Which IC do you try to use?
I use PFS154-S16 (erasable flash, 1000 write cycles)

I use the following sequence (I tested with 200kHz up to almost 2MHz for CLK pulses, all working):

- enable VPP 6.0V (I use external power supply for VPP and switch it on using a transistor)
- wait 100µs
- enable VDD 3.3V (driven from STM32 GPIO output pin directly)
- wait 500µs
- switch DAT to output
- send preamble + command bit by bit (28 bit + 8 bit): 0xA5A5A5A60
    bit send loop:
   * set current bit on DAT (MSB first)
   * CLK high
     * optional wait 1µs
   * CLK low
     * optional wait 1µs
- switch DAT to input
- receive ACK (12 bit):
    bit receive loop:
    * CLK high
    * read DAT bit (MSB)
      * optional wait 1µs
    * CLK low
      * optional wait 1µs
- check that ACK is 0xAA1

- 1 extra clock
   * CLK high
     * optional wait 1µs
   * CLK low
     * optional wait 1µs
- switch DAT to output

- send address (13 bit)
- switch DAT to input
- recv data (14 bit)
- 1 extra clock
   * CLK high
     * optional wait 1µs
   * CLK low
     * optional wait 1µs
- switch DAT to output

...

- send address (13 bit)
- switch DAT to input
- recv data (14 bit)
- 1 extra clock
   * CLK high
     * optional wait 1µs
   * CLK low
     * optional wait 1µs
- switch DAT to output

- wait 100µs
- disable VDD
- wait 20µs
- disable VPP

----------------

I think the sequence "VPP on, wait 100µs, VDD on, wait 500µs, send command" is essential.
Also if you make a mistake like sending a wrong preamble or bad command the IC will exit special mode and just start normal execution.

I will try to read an empty IC later.

[DocBen]

I use an arduino (clone).
The code I use is a bit of a mess right now because I hardcoded the command.
My futile attempt to remove errors
However it should be almost identical to the code you have.

So powercycling timing seems to be important.

Code: [Select]

void PADAUK_write_bit (unsigned char b) {
  digitalWrite(PA6_data, b);
  delayMicroseconds(1);
  digitalWrite(PA3_clk, 1);
  delayMicroseconds(1);
  digitalWrite(PA3_clk, 0);
  delayMicroseconds(1); 
}

unsigned char PADAUK_read_bit () {
  digitalWrite(PA3_clk, 1);
  delayMicroseconds(1);
  unsigned char b = digitalRead(PA6_data);
  digitalWrite(PA3_clk, 0);
  delayMicroseconds(1); 
  return b;
}

void PADAUK_command(unsigned char cmd) {
//A
PADAUK_write_bit(1);
PADAUK_write_bit(0);
PADAUK_write_bit(1);
PADAUK_write_bit(0);
//5
PADAUK_write_bit(0);
PADAUK_write_bit(1);
PADAUK_write_bit(0);
PADAUK_write_bit(1);
//A
PADAUK_write_bit(1);
PADAUK_write_bit(0);
PADAUK_write_bit(1);
PADAUK_write_bit(0);
//5
PADAUK_write_bit(0);
PADAUK_write_bit(1);
PADAUK_write_bit(0);
PADAUK_write_bit(1);
//A
PADAUK_write_bit(1);
PADAUK_write_bit(0);
PADAUK_write_bit(1);
PADAUK_write_bit(0);
//5
PADAUK_write_bit(0);
PADAUK_write_bit(1);
PADAUK_write_bit(0);
PADAUK_write_bit(1);
//A
PADAUK_write_bit(1);
PADAUK_write_bit(0);
PADAUK_write_bit(1);
PADAUK_write_bit(0);
//6
PADAUK_write_bit(0);
PADAUK_write_bit(1);
PADAUK_write_bit(1);
PADAUK_write_bit(0);
//0
PADAUK_write_bit(0);
PADAUK_write_bit(0);
PADAUK_write_bit(0);
PADAUK_write_bit(0);

pinMode(PA6_data, INPUT_PULLUP);
delayMicroseconds(1);

PADAUK_read_bit();
PADAUK_read_bit();
PADAUK_read_bit();
PADAUK_read_bit();

PADAUK_read_bit();
PADAUK_read_bit();
PADAUK_read_bit();
PADAUK_read_bit();

PADAUK_read_bit();
PADAUK_read_bit();
PADAUK_read_bit();
PADAUK_read_bit();

pinMode(PA6_data, OUTPUT);
digitalWrite(PA6_data, 0);
}


[DocBen]

The output waveform looks identical to your capture otherwise.

Vdd is 5V, Vpp is 7.8 right now but I have tried several values from 5.6 to 12 V.

[js_12345678_55AA]

Level 3 done  :

I just got ERASE working.

I had to insert one small extra CLK directly after command, so ERASE sequence was like this (maybe can be stripped down):
- enable VPP 8.3V
- wait 100µs
- enable VDD 3.3V
- wait 500 µs
- send preamble+command (28 bit + 8 bit): 0xA5A5A5A30
- receive ack (12 bit)
- CLK_UP
- CLK_DOWN
- wait 10000µs
- CLK UP
- wait 5000µs
- CLK_DOWN
- CLK_UP
- CLK_DOWN
- CLK_UP
- wait 5000µs
- CLK_DOWN
- CLK_UP
- CLK_DOWN
- wait 150 µs
- disable VDD
- wait 250 µs
- disable VPP

---------

complete IC (PFS154) was erased *EXCEPT* 3 words stayed constant:
@0x7ED : 0x0281    => RET 0x81
@0x7EF : 0x027A    => RET 0x7A
@0x7F0 : 0x1FFF    ? ? ? maybe a "magic value"

So looks like to identify a flash IC the 0x1FFF is detected (followed by 2 times erase counter, which was erased :-) )
The specific part is encoded @0x7ED, @0x7EF (guess: coded as "RET k" so calibration routine or user program can use it to identify IC it is running on) => IC type is 0x7A81 or 0x817A 

Have fun,

JS

EDIT: BONUS points: If erase counter is erased (0x3FFF) then it starts with 0 again when using original WRITER to program the IC. It made my test IC "virgin" again :-)

[socram]

AFAIK that extra clock is needed by all commands. I'm not sure how you are being able to use the read with  12 bit reply in place of the 13 as the scope shows.

[oPossum]

I am going to try using a DAC + opamp to generate the necessary variable voltages needed for programming. Driving a capacitive load with an opamp is generaly a bad idea - they will tend to oscillate. TI has a chip that they say is "awesome for driving capacitive loads!!!", so I am going to see if it really is. Hope to have all the parts in a few weeks.

http://www.ti.com/lit/ds/symlink/alm2402-q1.pdf
http://www.ti.com/lit/ds/symlink/dac084s085.pdf

[js_12345678_55AA]

AFAIK that extra clock is needed by all commands. I'm not sure how you are being able to use the read with  12 bit reply in place of the 13 as the scope shows.

After looking at the captures some more time it looks like the following happens:

Example PFS154 READ:

>preamble 28 bit
>command 4 bit
- 4 clocks
<ack 12 bit
- 1 clock
>addr 13 bit
<data 14 bit
- 1 clock
>addr 13 bit
< data 14 bit
- 1 clock
...
>addr 13 bit
< data 14 bit
- 1 clock

(It looks like whenever a switch from DAT-INPUT mode to DAT-OUTPUT mode is performed this extra "1 clock" is required)

My previous READ was working since I used 14 bit as address, which supplied the extra clock after switching DAT form input to output.

I will edit previous posts to have 13 bit address.

JS

[js_12345678_55AA]

Still not fully done...

I changed my READ to use 13 bit and sending extra clock.

Now I have a very reliable READ and ERASE.

However the WRITE is not working yet. Not a single bit is written. I massaged my DAT/CLK output to be almost identical to the one from WRITER.
The only difference I found is that it looks like after WRITER sent command "WRITE" VPP gets increased to 8V followed by delay of 5ms (maybe waiting for stabilization) and then (different to ERASE) also VPP is increased to 5.6V followed again by a delay of 5ms (wait for stabilization...) and then data is sent.

In order to have this feature I need to add one more transistor and power rail to my bread board and also must put a level shifter between input pins / output pins of MCU and IC ... ?? really ??

Stay tuned...

JS

[amyk]

Think of it this way: The official programmer wouldn't have done so if it wasn't required

[ali_asadzadeh]

That's great work any progress regarding the OTP ones? also any other part in the family?

[socram]

I could try running the SPI decoder on the OTP ones, but I'd need a scope dump first.

[spth]

Today, I made a first step to inefficently compiling a small subset of C to Padauk asm code. The current version is very restricted and generates very inefficient code; it is untested.

There is no assembler / linker support, so the resulting .asm file has to be assembled in other ways.

[…]

Code in svn at https://svn.code.sf.net/p/sdcc/code/branches/pdk/sdcc, use -mpdk14 to target Padauk (despite the name, the set of instructions emitted is part of the common subset of the Padauk instruction sets).

On the second day, wrt. completeness of implementation of the C standard, this has now far surpassed Mini-C.

Noticeable remaining restrictions:

* Variables can only reside in RAM, not in code space
* Global and static variables are not initialized.
* No floating-point or bit-fields.
* Functions can return at most 2 bytes (i.e. no long or long long).
* Multiplicative operators are not supported.
* Functions are not reentrant.
* No support for variable arguments.
* No standard library.
* struct / union cannot be assigned, passed as arguments or returned.
* No compoundliterals.
* No access to I/O from C.

There is no glue to connect this to assembler / linker yet, so the only useable output is asm code.
The generated asm code is still very inefficient. I will look into improving that a bit soon.

Philipp

Most of the above restrictions still apply.
There is now I/O support via __sfr, __sfr16.
There is rudimentary support for reentrant functions and variable arguments, but so far it only works for simple functions).

But there are still substantial improvements. There are fewer errors during compilation, the generated code is more efficient. A large part of the standard library (i.e. nearly everything that does not rely on return values > 16 bit) now compiles without errors.

My next main goals for this month are improving the support for reentrant functions / variable arguments, implementing initialization of global and static variables and getting something basic working for the glue between compiler, assembler and linker.

Philipp

P.S.:
At this point it would be really helpful for my work on sdcc if someone with access to the hardware could find out how push af works exactly.
Does a go to [sp] and f to [sp + 1]? Does a go to [sp + 1] and f to [sp]?

[FrankBuss]

A first usable version of the sampling software for my ADC4 board is done with the 1 GB RAM. As always needed a bit longer than expected, not as easy as it should be to access DDR3 RAM from a FPGA. I included a test mode which saves a counter in the RAM to check it, and also a CRC8 checksum because I'm transferring it over an external serial port connection. Sometimes there are transfer errors, but the CRC8 checksum detects it and I transfer the block then again. So the data should be very accurate.

I recorded the programming cycle of a PMS150C with SOT-23-6 package. There is no extra information with 25 MHz, so I used 12.5 MHz samplerate.

I stored the data in Sigrok format to view with PulseView, which is the best open source program for viewing analog data that I could find. It works for Windows, Linux and Mac. I couldn't find a way for GTKWave to show voltage divs. PulseView forgets the settings always when you load a new file, but at least it can be configured with 1 V per div and horizontal lines for each div, and navigating even in big datasets is fast and smooth. This is an example how you configure it when you click on the channel arrow:



You can also see the cursor, which is enabled by clicking on the blue cursor symbol in the toolbar, and which is useful for measuring time deltas.

All files are here:

http://www.frank-buss.de/tmp/dumps.zip

A *.sr file is just a zip file, and the analog-1-1-1 files are binary files of the voltages, with 4 byte float values for each sample, which could be converted back to float in Python with struct.unpack. But for easier reading I stored it in CSV format as well. The files in detail:

blinker.zip: the Padauk project and PDK file, compiled with IDE version 0.84
dump1.sr/csv: programming an already programmed PMS150C OTP chip with the blinker OTP. The following signals are connected to the channels:

CH1: PA4
CH2: PA6
CH3: VDD
CH4: PA5

The full sequence looks like this:



PA5 (CH4) doesn't look very interesting. So for the next files dump2.sr/csv, I sampled the following signals, now using CH4 for PA3:

CH1: PA4
CH2: PA6
CH3: VDD
CH4: PA3

It looks like this:



You can use the signals which are identical in the two dumps to correlate the PA5 signal in relation to PA3, if needed.

Then I used an empty chip and programmed it and saved it as dump3. The channel configuration is the same as used first:

CH1: PA4
CH2: PA6
CH3: VDD
CH4: PA5

It needs longer, so I sampled 2 seconds, with the same resolution of 12.5 MHz samplerate as the other dumps. Looks like this:



Finally I used another empty chip and programmed it, and saved the dump as dump4, now recording PA3 again instead of PA5 with CH4:

CH1: PA4
CH2: PA6
CH3: VDD
CH4: PA3

Looks like this:



I don't have much time to analyze it myself, but I guess now it shouldn't be too difficult to reverse engineer the full protocol.

PS: I disabled the open/short test with the ".writer" directive in the blinker.PRE file, because there were some problems with it with the SOT23-6 to DIP14 adapter, so some details of the dump might be different compared to the other dumps.

[tim_]

Thank you, that is extremely useful.

From a first glance, the programming interface of the PMC150 seems to be straight forward. The main difference to the PFS154 is that it does not seem to use a bidirectional data line, but a normal SPI interface.

My guess is that the pinout is as follows:

• PA3:   Clock (driven by writer)
• PA4:   Data in (driven by writer, data is valid on rising edge of clk. Data is set at arbitrary times due to random timing of writer software)
• PA5:   VPP
• PA6:   Data out (driven by MCU, data is valid on rising edge of clk. Data is set on falling edge since the MCU does not have an internal clk)

The program mode entry sequence is very similar to the PFS:

• Set all pins to GND
• Drive VPP to 8V (possibly >6V is threshold?, it looks like VDD is floating at the same time)
• wait 100µs
• Drive VDD to ~4V (2-6V is used depending on programming or verification)
• wait 500µs

VPP is 7.5V during read and ~10.5V during writing. This seems rather low. Are the ADCs calibrated correctly or may there be some offset/gain error?

VDD is 6V during programming, 4V during reading and 2V for verification. I would guess that it should be ok to keep VDD at 5V if you don't want to verify all corner cases.

To understand the protocoll it will be necessary to extract the logs using an SPI protocol analyzer. I will try to use PulseView for that. I am using it for the first time. It looks nice, but seems to be lacking some functionality. For example, how is it possible to display voltage values of specific data points`?

Edit: One comment: I find the entry sequence rather odd. Usually you would try to avoid under all circumstances applying a high voltage to a CMOS input when VDD is not connected due to latch up risk and potential damage to the ESD circuit. The programmer needs to control this sequence carefully to prevent frying the device.

-

[DocBen]

A first usable version of the sampling software for my ADC4 board is done with the 1 GB RAM.

Not to nit-pick, but it seems there is a lot of cross talk and bouncing going on. Also clock and data seem to be out of phase in some areas.
Don't if that is really the case or if the data for the otp is really that different from the pfs154.

Have you tried to sample test signals?
Ie clock of a micro on one channel and look what the rest does?

[FrankBuss]

VPP is 7.5V during read and ~10.5V during writing. This seems rather low. Are the ADCs calibrated correctly or may there be some offset/gain error?

VDD is 6V during programming, 4V during reading and 2V for verification. I would guess that it should be ok to keep VDD at 5V if you don't want to verify all corner cases.

To understand the protocoll it will be necessary to extract the logs using an SPI protocol analyzer. I will try to use PulseView for that. I am using it for the first time. It looks nice, but seems to be lacking some functionality. For example, how is it possible to display voltage values of specific data points`?

There could be an error of about 0.1 V - 0.2 V, the potentiometers are a bit sensitive, and it clips at about 10.24 V: Everything higher than this is 10.24 V. Maybe I should calibrate it for 12 V, but then the resolution gets worse.

But I verified PA5 (right, looks like VPP) with my Agilent scope and the rest should be pretty accurate. From dump3 with PulseView:



And you are right, PulseView is very limited. I couldn't find a way to read the exact voltages at a location. When you move the mouse over a location, it shows it in millivolt if it is below 1 V, and only if zoomed in like crazy, and if it is above 1 V, it is rounded to closest integer values. Looks like the programmers never used a real scope  But the workaround I described works pretty well: click on the channel label, then set "number of pos vertical divs" to 10, and vertical resolution to 1 V / div. Then you will have at least each 1 V div a horizontal line.

This is how it looks like when I record it with my scope. Not the same recording sequence, but again programming an empty chip:



As you can see, the 7.5 V is about the same, and then you can see the clipping.

[tim_]

Ah, interesting, that makes a lot of sense. Have you checked what the actual VPP is, instead of 10.5V? I suppose it is 12V or higher?

I got pretty far decoding the protocol, I am mainly stuck at writing right now. I will post my notes soon.

[FrankBuss]

Not to nit-pick, but it seems there is a lot of cross talk and bouncing going on. Also clock and data seem to be out of phase in some areas.
Don't if that is really the case or if the data for the otp is really that different from the pfs154.

Have you tried to sample test signals?
Ie clock of a micro on one channel and look what the rest does?

You are right, cross talk is terrible. But I think the recording should be very accurate regarding the timing and the phase of the signals.

I verified it with my signal generator and because of the nature of the sampling on the FPGA it is very unlikely that there is a phase error. But of course there could be still bugs in the Python script etc. If you think there are any wrong or strange signals, I can record any 2 signals with my real oscilloscope to verify it. This is a screenshot of my oscilloscope Python script, with 4 Vpp and 500 kHz from the signal generator, channel 2 phase shifted 180°:

[tim_]

You are right, cross talk is terrible. But I think the recording should be very accurate regarding the timing and the phase of the signals.

From what I see, there is mainly crosstalk from Clk to VDD and MISO/MOSI. I suppose this crosstalk could also be internal to the MCU (from CMOS switching), since it is fully clocked externally in programming mode. Apart from the truncation of Vpp voltage, the logs look fine to me.

[FrankBuss]

Have you checked what the actual VPP is, instead of 10.5V? I suppose it is 12V or higher?

This is the full cycle of VPP with my scope:



I verified it and the scope has no problems to measure more than 12 V, no clipping here. So it looks like the max level is about 10.8 V.

[FrankBuss]

PS: I noticed that it looked like the programmer loads a new firmware when I switch from the PMS150C to the PMC884. So it is plausible that some parts of the programming sequence are very different depending on the chip.

[tim_]

Please find attached my notes on analysing the programming sequence from Frank. Sorry for the bad image quality, I had to limit the filesize. I can upload it somewhere else later.

The information is not yet very structured, but I believe it should be enough to create a programmer for the PMS150C from scratch.

Something I have not yet looking into, is the clock calibration/code checksum. So, for a start, it would be easier to generate binaries without the initialization code that the Padauk IDE adds.

Many parts of the programming sequence are only to verify operation at different corner cases of the operating voltage. It is probably sufficient to stay at a single level of VDD, e.g. 5V.

A challenge that remains will be to come up with hardware that allows controlling VPP at 7.5V and 10.8V. Maybe some of the existing PIC programmers can be used as a reference.

Btw, one issue that could also be existent with the PFS154 is a strange behavior of MISO during data direction changes (see slides 12/13). Many bidirectional protocols (e.g. SWD) introduce an additional cycle for direction reversal. Padauk has omitted this, which leads to unexpected "features". Generally,  there are some parts of the protocol that look like workarounds. I'd guess they fixed things as they come, so probably there are also some inconsistencies between devices.

[FrankBuss]

Please find attached my notes on analysing the programming sequence from Frank.

Great work! The different programming voltages shouldn't be a problem. The circuit diagram from @oPossum looks good, the ALM2402 can drive up to 400 mA, so maybe no external transistor amplifier is even needed. But it has only a gain bandwidth of 600 kHz, maybe would be good to use some additional 4051 for the high frequency data lines. Could be all controlled with a cheap Arduino nano, and a simple Python script to control it and send the programming file over serial port.

I wonder why they do all these tests. I guess they don't do much tests when they produce the ICs? So far I've used about 20 PMS150C for testing, programming little things etc. One IC was not programmable. Might be a good idea if a DIY programmer would do all the verifies at different voltage levels etc. as well.