EEVblog #1144 - Padauk Programmer Reverse Engineering

[jacola]

So, i got a first board with PFC154 working and its mostly in-circuit programmable with the lite-r1 (i interrupt the VDD pin for programming).

Now i am trying to do an efficient WS1812B driver, in assembler, and an i2c slave (interrupt driven) within SDCC framework.

So far so good.

I will help where i can answering questions.

J.

[tim_]

Where is the activity regarding Nyquest suddenly coming from? I noticed you can now buy plenty of their devices very cheaply on LCSC. It looks like they are basically PIC clones? They are supported by SDCC?

Also, many Padauk devices are in stock again at normal prices! Most interesting is the PMS154C-S16, which is well supported by the OS toolchain.

[spth]

There have been a few new devices recently: the current Padauk IDE mentions a PFC887, there are datasheets for PFC440, PMS15B, PMB180, PGS134, PGS152. I've added some github fppa documentation repo today.

But I wonder if the instruction encoding used on PFC886 and PFC887 is really the same as other pdk16 devices: the .INC files call it SYM83B2, while for the older pdk16 devices, it is called SYM83A.

[KaeTo]

Hello together
I wanted to ask if the  PFC161 is supported by SDCC and the free pdk programmer at the time.

[spth]

Hello together
I wanted to ask if the  PFC161 is supported by SDCC and the free pdk programmer at the time.

It is. easypdkprog added support in June 2021, SDCC has had support since spring 2019.
I'd still recommend to use a recent version of easypdkprog and a recent release (e.g. SDCC 4.2.0) of SDCC.

[KaeTo]

Thank you

[rs04]

Hello everybody,
  The EEVblog community has made the padauk programmer which I have and used it. I also have the 5S-I-S02B padauk provided emulator. For testing my programs I use this emulator using the IDE provided by padauk itself which supports mini c language.
   My question is, can I convert this mini-c programmed code to the ihex file supported by the freepdk programmer? If not I have to first check the code in emulator, then write the same code for sdcc compiler which does not feel good to me.
  The IC that I am working with is PMS171B which is OTP type and I can not reprogrammed it to fix any minor mistake for which I have to use emulator. I also tried converting the mini-c code into asm code and copy the code in sdcc compatible way using  "__asm" and end it. But during compilation it shows error. While converting mini-c to asm, some commands with "" will also appear which I removed.

[LovelyA72]

something worth mentioning in the newer padauk IDE. They are using a key and response system for the customer service to unlock clients that can not connect to the internet. Might be a fun investigation if someone is interested. The way to access the unlock dialog is to run a fresh IDE without internet connection and click Help > News

[LovelyA72]

Where is the activity regarding Nyquest suddenly coming from? I noticed you can now buy plenty of their devices very cheaply on LCSC. It looks like they are basically PIC clones? They are supported by SDCC?

Correct, they are PIC clones. Their NY8 C compiler uses a modified SDCC without following the GPL open source license by opening the source code of the modified tool chain.

[tim_]

something worth mentioning in the newer padauk IDE. They are using a key and response system for the customer service to unlock clients that can not connect to the internet. Might be a fun investigation if someone is interested. The way to access the unlock dialog is to run a fresh IDE without internet connection and click Help > News

So the new IDE is locked down? It really seems that Padauk is not appreciating the open market...

I am having a good time with the CH32V003. It's a minimal RISC-V (RV32EC) microcontroller that is only $0.10 and comes with an excellent free toolchain. Not to speak of an overabundance of periphery including DMA...

[tim_]

Where is the activity regarding Nyquest suddenly coming from? I noticed you can now buy plenty of their devices very cheaply on LCSC. It looks like they are basically PIC clones? They are supported by SDCC?

Correct, they are PIC clones. Their NY8 C compiler uses a modified SDCC without following the GPL open source license by opening the source code of the modified tool chain.

Ok, that explains. I saw references to the SDCC toolchain in their examples with a target called "ny8", that is not supported by the official SDCC. Annoying, and not something that should be supported.

[LovelyA72]

something worth mentioning in the newer padauk IDE. They are using a key and response system for the customer service to unlock clients that can not connect to the internet. Might be a fun investigation if someone is interested. The way to access the unlock dialog is to run a fresh IDE without internet connection and click Help > News

So the new IDE is locked down? It really seems that Padauk is not appreciating the open market...

I am having a good time with the CH32V003. It's a minimal RISC-V (RV32EC) microcontroller that is only $0.10 and comes with an excellent free toolchain. Not to speak of an overabundance of periphery including DMA...

Not really, it's just an alternative way of network activation. If there's a working internet connection the activation process is automatic and transparent to the user.

[LovelyA72]

also, seems like they just released some MCU with EEPROM or lithium charger.
They are also planning to release some hall effect switches next year.

[tim_]

also, seems like they just released some MCU with EEPROM or lithium charger.
They are also planning to release some hall effect switches next year.

Catalogue in english:
http://www.padauk.com.tw//upload/SelectionGuide/Company_Catalogue_2023H1_v2_20221124..pdf

Interesting, they seem to pursue lots of opportunities where they combine their small MCU core with other devices. It also seems that they plan to discontinue many parts that are still listed on their website like the PFS173.

[rs04]

I want to program PFC161 using freePDK hardware. For this I need to use the development branch. Using the firmware of master branch does not support in development branch. But there is no
EASYPDKPROG.dfu file in this branch. Where can I get it?

[spth]

I want to program PFC161 using freePDK hardware. For this I need to use the development branch. Using the firmware of master branch does not support in development branch. But there is no
EASYPDKPROG.dfu file in this branch. Where can I get it?

Build it via "make" in Firmware/source?

[jacola]

Hi, 
i have a PFC154-S16 on a board which does not identify correctly:

TYPE:FLASH RSP:0xE34B VPP=4.50 VDD=2.00

Unsupported IC

For me this smells as if padauk made a new mask version and counted up 34A to 34B - could that be ?
Any advice how to debug this further ?

I have ICs i can send to whoever can take a look ..

Johannes

[jacola]

Hi JS,

i can send you PFS122 via DHL quickly (within europe), we bought a good quantity of -S16 and -U08

I have quite some parts stocked now in Portugal - i believe in using those padauks for several projects, so we bought stock to have them.

Plus - i want to use them commercially so happy to send you a bounty to get this moving.

Johannes

[jacola]

Reply to self

The problem is understood but not solved. The chip has no issue and identifies correctly

Our motherboard has 'just' a 10k pullup to the Padauk supply on the programming pins, but that already causes the programming interface to get wrong bits apparently and fail. I assume its some critical timing in the programmer firmware, a 10k pullup should actually not have any influence on a digital signal like that programming data pin. 

We use easypdk 'lite' with 100 ohm series resistors in the programming lines, removing those does not change anything.

Johannes

[js_12345678_55AA]

Reply to self

The problem is understood but not solved. The chip has no issue and identifies correctly

Our motherboard has 'just' a 10k pullup to the Padauk supply on the programming pins, but that already causes the programming interface to get wrong bits apparently and fail. I assume its some critical timing in the programmer firmware, a 10k pullup should actually not have any influence on a digital signal like that programming data pin.

We use easypdk 'lite' with 100 ohm series resistors in the programming lines, removing those does not change anything.

Johannes

Hi,

Hard to give any advise on this. In circuit programing was and always will be a challange with PADAUK ICs. Even the PADAUK official programer gives you a hrad challange here.

You mentioned pull up resistors on the programing data pins. This could in fact be a problem. Since you pull up those pins to 5.5V (VDD during programing of PFC154) it will be harder for PADAUK IC to properly to pull them down to signal a 0. The STM32 is a 3.3V IC with 5V tolerant pins. But this does not mean that the logic level of STM32's inputs is translated as well... So in case the PADAUK IC can not pull down the "0" bit below 1.23V then it is undefined what actually will be read.

From your post it looks like the "probe" command already has bit problems.
Since the probe command uses extra low voltage it might be a good idea to change the firmware code for your scenario and use higher VDD / VPP:

firmware: "fpdk.c"

Code: [Select]

uint32_t FPDK_ProbeIC(FPDKICTYPE* type, uint32_t* vpp_cmd, uint32_t* vdd_cmd)
{
  //try to get IC with low voltages
  *vpp_cmd = 4500; *vdd_cmd = 2000;
...You can try to increase those values slightly to compensate for pull ups / downs in your circuit. E.g. try to set vpp_cmd to 5500 and vdd_cmd to 2500 or 3000 and check if probing is working with your circuit. Note: This is just for the probe command.

The actual read/write/erase command and programing voltages are defined within the
host software: "fpdkicdata.c"

Code: [Select]

{ .name                                      = "PFC154",
   .otpid                                     = 0x2AA5,
   .id12bit                                   = 0x34A,
   .type                                      = FPDK_IC_FLASH,
   .addressbits                               = 13,
...
   .vdd_cmd_read                              = 2.5,
   .vpp_cmd_read                              = 5.5,
   .vdd_read_hv                               = 2.5,
   .vpp_read_hv                               = 5.5,
...
   .vdd_cmd_write                             = 2.5,
   .vpp_cmd_write                             = 5.5,
   .vdd_write_hv                              = 5.5,
   .vpp_write_hv                              = 0.0,
...
For programing phase 1 (command phase) which is used to identify the IC vdd_cmd_write and vpp_cmd_write are used.
In case you get an error that the IC does not match when you try to write, you can experiment with those values.
You might want to increade / decrease them for some milivolts. Just make sure vdd_cmd_write + 2.5V < vpp_cmd_write (this is the "magic" to enable PADAUK programing mode).

JS

[jacola]

I did some more investigation about the programming problem with the pullup on the padauk PFC154 ('in circuit programming').

My suspicion proves correct, it is the pullup on the data line (PA6). The other pins used for programming are not affected.

It is super easy to reproduce, if you just add a 10kOhm pullup between PA6 and VDD on a sip test socket with a PFC154 and plug that to easyprog lite. it cannot identify the chip properly.
The error seems to be just in the last bit of the ID, and with the scope i verified that the levels of the bits seem correct.

So my assumption is that this can be fixed in software on easyprog, it is probably an issue of sampling timing of the answer, and it is not an issue of the padauk pin (not being able to drive against 10k or the like).

attached
- picture of setup (with easyprog and pfc154 and the pullup)
- picture of signals on scope without pullup
- picture of signals on scope with pullup.

I dont know the exact serial programming protocol of the padauk, but i can investigate into the firmware of the programmer and probably figure this out, however, i assume some of you are much faster on this.

Johannes

[js_12345678_55AA]

Hi JS,

i can send you PFS122 via DHL quickly (within europe), we bought a good quantity of -S16 and -U08

I have quite some parts stocked now in Portugal - i believe in using those padauks for several projects, so we bought stock to have them.

Plus - i want to use them commercially so happy to send you a bounty to get this moving.

Johannes

Have you tried your PFS122 with easypdkprog?

The ones I purchased identify as PFS172, reading, writing, running... all works fine.
They also can be written as PFS172 with official PADAUK WRITER.

And last but not least... in official PADAUK IDE if you look at the header files, PFS172.INC and PFS122.INC are identical. PFS122 just adds some extra definitions for ADCM (ADC modes).

Checking OTP_ID we learn:

PFS121, PFS122, PFS172, PFS172B are all the SAME IC.

PFS123, PFS173, PFS173B are all the SAME IC


So looks like PFS122 support was there all the time 

JS

[js_12345678_55AA]

I did some more investigation about the programming problem with the pullup on the padauk PFC154 ('in circuit programming').

My suspicion proves correct, it is the pullup on the data line (PA6). The other pins used for programming are not affected.

It is super easy to reproduce, if you just add a 10kOhm pullup between PA6 and VDD on a sip test socket with a PFC154 and plug that to easyprog lite. it cannot identify the chip properly.
The error seems to be just in the last bit of the ID, and with the scope i verified that the levels of the bits seem correct.

So my assumption is that this can be fixed in software on easyprog, it is probably an issue of sampling timing of the answer, and it is not an issue of the padauk pin (not being able to drive against 10k or the like).

attached
- picture of setup (with easyprog and pfc154 and the pullup)
- picture of signals on scope without pullup
- picture of signals on scope with pullup.

I dont know the exact serial programming protocol of the padauk, but i can investigate into the firmware of the programmer and probably figure this out, however, i assume some of you are much faster on this.

Johannes

When I do the same experiment (10K between VDD and PA6) I get the exact same problem.

As a test I modified the clock timing in firmware (fpdk.c: _FPDK_DelayUS() 1 => 20) and changed the timeouts in host software (fpdkcom.c: FPDKCOM_CMDRSP_READIC_TIMEOUT 10000 / FPDKCOM_CMDRSP_WRITE_TIMEOUT 20000).
This did not change the wrong OTPID problem (last bit different). Then I changed the IC OTP ID inside of fpdkicdata.c and to my suprise a read worked (it only works with the slower timing). Erase also worked.
Write starts but somehow the result looks very bad (not just bit failures, it seems to write to wrong places).

However, with some more experiments this might have a solution after all.


JS

EDIT: There is a PULL-DOWN config for the GPIO-INPUT config for the DAT line (PA.6) when STM32 is reading bits. When I change this to PULL-UP I get the same result as when the external PULL-UP 10k resistor is connected.
This makes me believe that PFC 14 bit series might clock out 1 ID bit less and the last bit interpreted as ID is in fact a floating DAT line (PADAUK does not push/pull this bit).
After looking at the OTP-ID we have right now for PFC154: 0x34A and shifting it 1 bit to the right we get 0x1A5 (which is in line with other OTP IDs, matching in parts the OTP ID we find in PADAUK header files. PFC154 OTP_ID in PADAUK header: 0x2AA5).
So it should be possible to solve the ID bit without changing the timing...

[jacola]

  i will try the PFS122 on monday, just got a first PCB with it (for testing i used the PFC232 on the boards) into the office.
*** GOOD NEWS indeed !

On the PFC14, thanks for investigating ! I tried modifying the ID also (added 'PFC154B to the list) and it worked for identification, but programming did not, and i am not the specialist (yet).

Breaking my fingers now on the optimized I2C state machine, interrupt based ..

[jacola]

OK, so i have a full feature I2C implementation, interrupt based, working.
It simulates the usual PCF8574 but it also 'makes' a second device with 16 generic registers plus some readonly info for identification.
All works 100% in interrupt context, so the 'main' program is free for other functions.
There is a 'notification callback' when the PCF8574 is written so the main program can take action.

I will test the code a bit and clean it up. I will eventually publish it as open source, if someone is interested i can share it now.

One problem i stumbled upon which i would like to 'warn' about
The bit set/reset instructions on the IO ports (PA and PB) do not affect a single bit. the implementation in the padauk is made in a way that they read back all 8 bits, modify the specific bit, and then put them back into the output register. So if a specific bit (in my case i2c data) is set to 0, but 'input', the set bit instruction on any other IO bit in that port will result .. in the 0 being changed to 1 (by readback of the input with '1 value and write out). It is logical but caught me .. 

last comment (actually this is a question): i would like to use the "SWAPC" instruction, but did not get that to compile (well .. assemble). Is that maybe missing or is there a specific syntax i am missing ?
I tried SWAPC and also SWAPC.io, neither worked.

Cheers

Johannes