EEVblog #1144 - Padauk Programmer Reverse Engineering

[tim_]

Have you tried "easypdkprogtest"  and measured all voltages?

[spth]

Recently, about a dozen new Padauk devices becam available at LCSC. Part numbers start with XDT, and I cannot find any datasheets anywhere. They are not mentioned on the Padauk website. The Padauk MINI-C software does not mention them either (there is one XDT device mentioned in there - the XDT0164, but that one isn't among the ones available at LCSC).

Does anyone have any idea about those devices?

[tim_]

Recently, about a dozen new Padauk devices becam available at LCSC. Part numbers start with XDT, and I cannot find any datasheets anywhere. They are not mentioned on the Padauk website. The Padauk MINI-C software does not mention them either (there is one XDT device mentioned in there - the XDT0164, but that one isn't among the ones available at LCSC).

Does anyone have any idea about those devices?

It could be a mistake. All of these seem to be touch controllers without MCU:

http://www.zhienchina.com/product/Touch.html

[makersLabs]

Have you tried "easypdkprogtest"  and measured all voltages?

Hi Tim,
No I just try to use "normal" program
I found easypdkprgtest.c is it that one you speak about ?

on DOS session sending make easypdgprogtest give me this for result :
D:\Users\FidL\Documents\eagle\easyPDKprog\easy-pdk-programmer-software-master>make easypdkprogtest
cc -std=c99 -pedantic -Wall -O2 -Ilib/argp-standalone-1.3   -c -o serialcom.o serialcom.c
process_begin: CreateProcess(NULL, cc -std=c99 -pedantic -Wall -O2 -Ilib/argp-standalone-1.3 -c -o serialcom.o serialcom.c, ...) failed.
make (e=2): file sp¨|cifi¨| cannot find.
make: *** [serialcom.o] Error 2

[spth]

https://item.taobao.com/item.htm?spm=a230r.1.14.1.f1fc51c4BL5XXZ&id=649017329840&ns=1&abbucket=8#detail

XDM4102 and XDM4104. Very interesting. 1.9 KW of program memory. According to the data from Mini-C, these are pdk14 devices. I guess they use the program memory space to map the 2KB EEPROM. That could allow these devices to update their own firmware in the field. It would be great to have datasheets.

P.S.: According to http://www.qy6.com/syjh/showbus8356932.html, the XDM4105 is basically a PFS173 with EEPROM, the XDM4104 a PFS154 with extra EEPROM , the XDM4103 a PMS152 with extra EEPROM. But according to that page, the program memory has hte full size (so it looks more like two dies in one package). I guess we need to get and decap some to know.

[js_12345678_55AA]

https://item.taobao.com/item.htm?spm=a230r.1.14.1.f1fc51c4BL5XXZ&id=649017329840&ns=1&abbucket=8#detail

XDM4102 and XDM4104. Very interesting. 1.9 KW of program memory. According to the data from Mini-C, these are pdk14 devices. I guess they use the program memory space to map the 2KB EEPROM. That could allow these devices to update their own firmware in the field. It would be great to have datasheets.

P.S.: According to http://www.qy6.com/syjh/showbus8356932.html, the XDM4105 is basically a PFS173 with EEPROM, the XDM4104 a PFS154 with extra EEPROM , the XDM4103 a PMS152 with extra EEPROM. But according to that page, the program memory has hte full size (so it looks more like two dies in one package). I guess we need to get and decap some to know.

I have some XDM4103. They are multi chip packages containing a standard PADAUK PMS152 and an attached 24C02 eeprom.
The 24C02 eeprom is attached to IO ports of PADAUK IC. The eeprom can not be used as program memory.
Nothing fancy.

XDM4105 is same thing, a PFS173+24C02 in one package.

Here a list with XDM to PADAUK mapping: http://www.zhienchina.com/product/MCU.html

JS

[js_12345678_55AA]

Hello,

some days ago I had an idea how to add support for writing PDK files (from padauk IDE).

The padauk IDE inserts code that makes a call to almost the end of the IC code memory (e.g. call 0x7FE on PFS154).
If the returned value is 0xFF (ret 0xFF), the calibration code for IHRC is executed.
After WRITER completes the IHRC calibration, it overwrites the return value 0xFF with the calibration value.
The next time IC is started, the same call returns the calibration value, which is then written to IHRCR.

The idea that simplifies PDK support for easypdkprog is that instead of running the complex padauk calibration code, the default easypdk calibration code is embedded and instead of the instruction returning the calibration value, a GOTO to the easypdk calibration code is inserted. This only requires space for 13 additional instructions, which most projects can afford. 

The development branch contains an initial implementation that already works very well for all ICs I have tested. The "write" command supports IHX and PDK files now. Even serial numbers (32 bit only) can be set.

For the other direction SDCC .IHX file => usable with padauk IDE I will try a different approach. Instead of converting the .IHX to .PDK, I plan to convert the .IHX to padauk IDE .ASM code (with embedded comments containing original SDCC .C source lines). This converted .ASM code can then be used in padauk IDE to generate PDK files and is also usable with the padauk ICE (padauk emulator).


JS

[spth]

@spth



mr.spth
I'm very interested in your open source the programmable hard devices .the operation instructions provided are not clear enough and

I'd like to request some additional documentation regarding the programmer's operation instructions. I'd also like to request the

latest Windows binary development release of the programmer software. annex: Test Chip compatible software
thank you
Su

I can't give it to you because I don't have an import and export certificate.You can buy it on Taobao.
https://item.taobao.com/item.htm?spm=a230r.1.14.1.359b404c0Msywi&id=650818241626&ns=1&abbucket=15#detail


时间先生


我对你们的开源可编程硬件设备非常感兴趣。提供的操作说明不够清楚，我想要求提供一些关于程序员操作说明的附加文档。我还想申请最新的

Windows二进制开发版本的程序员软件。附件：测试芯片兼容软件

非常感谢。


su
由于我没有进出口凭证,无法给你.你可以在淘宝上购买.
https://item.taobao.com/item.htm?spm=a230r.1.14.1.359b404c0Msywi&id=650818241626&ns=1&

I didn't create the programmer, and didn't contrinute much to the easypdkprog software either. That work was mostly done by @js_12345678_55AA. But I think you can get help in the forum here or by opening an issue on GitHub.

AFAIK; Windows binaries of releases can be found at https://github.com/free-pdk/easy-pdk-programmer-software/releases

I did create the SDCC pdk13, pdk14 and pdk15 backends(s), though: http://sdcc.sourceforge.net which you can use to compile C code for Padauk µC.

Philipp

[tim_]

mew chip FT32F072C8AT7 LQFP48
https://www.fremontmicro.com/product/32%20bit%20mcu/arm%20core_1/20210316/1769.aspx
https://item.taobao.com/item.htm?spm=a1z09.2.0.0.df072e8dE6k6EJ&id=656098151997&_u=923hlh4e710

So now FMD switched to cloning STM microcontrollers. It would be better if they came up with their own designs instead.

[tim_]

Article about Padauk in the Digitimes

https://digitimes.com/news/a20211008PD205.html

"Padauk Technology saw its third-quarter revenue hit a record high of NT$264 million (US$9.43 million), with revenue for the first three quarters of 2021 already exceeding the level in all of 2020."

I wish they would send some reels to LCSC again, but I guess they are busy trying to get enough product for their key customers...

[js_12345678_55AA]

Hi

thanks @damingge for the taobao link. I will order some of the FT32F072 to check compatibility and also will try to get some PFC886. For sure it will take some time to export them from China but I have some friends which handle it for me.

Regarding latest "binary versions" of the programmer software / firmware: You always can build it yourself from source. Everything is included. However the next release version will come out soon.
I just wanted to test a bit more all the new features like .PDK writing, support for PFC151/PFC161/PFC232, support for MacSilicon (ARM-Mac) / support for armhf /aarch64 (raspberry pi) ...

JS

Update: I checked FT32F072 data sheet and it looks like it is not at all like a real STM32F072. The SRAM is much smaller, data sheet does not mention dual 12 bit DAC, bootloader does not mention DFU, ... So most likely this is not a valid STM32F072 replacement. I ordered some anyway to have a look myself. Maybe the clone is better than the data sheet.

[tim_]

It looks like FMD is planning to have RISC-V products as well:

https://www.fremontmicro.com/product/32%20bit%20mcu/risc-v%20core/index.aspx

This could be very interesting. There are still not many small RISC-V devices available.

[daming]

FT32F0 The file is too la.rge. What's your QQ number or email number.

[js_12345678_55AA]

FT32F0 The file is too la.rge. What's your QQ number or email number.

You can send to : js55aa@88.com

[js_12345678_55AA]

This chip is good:

this is:
http://www.wch-ic.com

http://www.wch.cn/products/category/5.html#data
http://www.wch.cn/products/CH32V103.html?

This has already been discussed on github. STM32F103 and all its (complicated) clones do not have dual DAC. They also do not have DFU bootloader in ROM which makes programing more complicated.

JS

[daming]

padauk  new mcu pfc460  26io sop28 tsop28

[daming]

Quad core MCU

[tim_]

padauk  new mcu pfc460  26io sop28 tsop28

Looks really interesting. If only they were available...

LCSC has some new Padauk MCUs in stock: The PFC161 in various package types. The price is not interesting at all, though (>$0.30).

[KaeTo]

Hello,

can anyone tell me where you can buy Padauks (PFS154 and PFS173) right now? I used to buy them at LCSC, but they are out of stock since months. Does anyone knew an alternative platform or when LCSC should have them in stock again?

[LovelyA72]

It's kinda quiet here...

I am currently trying to make audioplayer work on a PFS154.
However, the example does not work at all. After probing on the SPI line I found that not only the timing is a mess, the padauk is driving the MISO pin which it needs to be listening to instead of driving.

I am wondering this might be a compiler issue since I can't see any pin manipulation on the MISO pin.

[js_12345678_55AA]

It's kinda quiet here...

I am currently trying to make audioplayer work on a PFS154.
However, the example does not work at all. After probing on the SPI line I found that not only the timing is a mess, the padauk is driving the MISO pin which it needs to be listening to instead of driving.

I am wondering this might be a compiler issue since I can't see any pin manipulation on the MISO pin.

Do you use a recent version of SDCC?

I learned the other day that assembler syntax for IO commands was changed around July 2021 (e.g. "mov.io  IOREG, A" instead of the previous "mov IOREG,A").
=> Recent SDCC versions (snapshot / compiled from source) will most likely produce defect output when assembler language is included in your source code.

You should check the compiler output for warnings about IO register forced to be in memory... (unfortunately the will not be shown with default settings)

To fix this you only need to find all assembler code which contains MOV, T0SN, T1SN, XOR which have an IO register as source or destination. The new syntax for them is "mov.io / t0sn.io / t1sn.io / xor.io"

JS

P.S: Unfortunately updating all existing projects right now is not a good idea, since the stable release version of SDCC does not support the new ".io" syntax :-(


In case you mean the "audioplayer" from showcase projects, you need to change in "pdkspi.c" the assembler function "pdkspi_sendreceive":

Code: [Select]

uint8_t pdkspi_sendreceive(uint8_t s)
{
  __asm
     mov a, #8                                 ; loop 8 times
1$:
     set0.io _ASMS(SPI_PORT), #(SPI_OUT_PIN)   ; SPI-OUT = 0
     t0sn _pdkspi_sendreceive_PARM_1, #7       ; s.7==0 ?
     set1.io _ASMS(SPI_PORT), #(SPI_OUT_PIN)   ; SPI-OUT = 1
     set1.io _ASMS(SPI_PORT), #(SPI_CLK_PIN)   ; SPI-CLK = 1
     sl _pdkspi_sendreceive_PARM_1             ; s<<=1
     t0sn.io _ASMS(SPI_PORT), #(SPI_IN_PIN)    ; SPI-IN==0 ?
     set1 _pdkspi_sendreceive_PARM_1, #0       ; s.0=1
     set0.io _ASMS(SPI_PORT), #(SPI_CLK_PIN)   ; SPI-CLK = 0
     dzsn a                                    ; loop--
     goto 1$                                   ; loop again if>0
  __endasm;
  return s;
}

[js_12345678_55AA]

I changed all showcase projects: https://github.com/free-pdk/easy-pdk-showcase-projects

They now use the new .io assembler syntax and require a recent SDCC version (>=4.1.10) for compilation.

I also added a workaround in the polysound project for the compiler bug / regression with incorrect working scoping of enums ( https://sourceforge.net/p/sdcc/bugs/3289/ )

JS

[spth]

P.S: Unfortunately updating all existing projects right now is not a good idea, since the stable release version of SDCC does not support the new ".io" syntax :-(

You could use e.g.

Code: [Select]

#if __SDCC_REVISION >= 12558
mov.io-style asm code
#else
mov-style asm code
#endif


[spth]

Yesterday, SDCC 4.2.0 was released. There were no fancy new features particularly relevant to the pdk ports, though.

Development continues after the release , and the STM8 just got support for ISO C23 bit-precise integer types. Those could be useful for Padauk devices once ported, as they allow e.g. the use of 24-bit and 40-bit integer types.
P.S.: SDCC also allows bit-fields of bit-precise integer types, so they are also a way to have bit-fields wider than int.

[LovelyA72]

Just a quick update, PMS150C(both SOP-8 and SOT-23-6) is back in stock in lcsc with sufficient stock.