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

0 Members and 2 Guests are viewing this topic.

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1450 on: November 24, 2022, 01:59:12 am »
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.
Kashikoma!
 

Offline LovelyA72

  • Regular Contributor
  • *
  • Posts: 60
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1451 on: November 24, 2022, 04:30:40 am »
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.
Kashikoma!
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1452 on: November 24, 2022, 06:46:09 am »
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.

 

Offline rs04

  • Newbie
  • Posts: 4
  • Country: np
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1453 on: November 25, 2022, 10:36:33 am »
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?
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1454 on: December 02, 2022, 02:17:30 pm »
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?
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1455 on: December 04, 2022, 10:38:42 pm »
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
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1456 on: December 06, 2022, 04:42:46 pm »
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

« Last Edit: December 06, 2022, 05:25:03 pm by jacola »
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1457 on: December 06, 2022, 05:31:16 pm »
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
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1458 on: December 06, 2022, 09:50:15 pm »
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

Easy PDK programmer and more: https://free-pdk.github.io
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1459 on: December 08, 2022, 12:21:47 pm »
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

 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1460 on: December 09, 2022, 08:07:02 pm »
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  :-DD

JS
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1461 on: December 09, 2022, 09:43:10 pm »
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...
« Last Edit: December 09, 2022, 10:04:59 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1462 on: December 10, 2022, 06:12:28 pm »
 ;D 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 ..



 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1463 on: December 13, 2022, 06:33:55 pm »
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

 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1464 on: December 13, 2022, 06:59:56 pm »
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

I would definitely be interested to see your i2c implementation at some point.

I have my own that works pretty good up to about 370 kHz, although it requires a host with clock stretching compatibility.  I haven't published it anywhere yet, partly due to laziness, and partly because it uses the SWAPC instruction that as you have noticed is broken with the current version of SDCC.

You can try the previous version of SDCC to get SWAPC to compile, but they I believe you will have to also revert all the .IO syntax.  There is an outstanding bug report about the issue here: https://sourceforge.net/p/sdcc/bugs/3376/.  Hopefully it is resolved for the next release.
 

Offline bonnom

  • Newbie
  • Posts: 2
  • Country: nl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1465 on: December 13, 2022, 07:07:45 pm »

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  :-DD

JS

I also noticed that, they discontinued the, PFS121, PFS172, PFS172B, PFS173, PFS173B and replaced them with PFS122 and PFS123.
Maybe they had some problems with the ADC accuracy and decided not to sell them as 12-bit ADCs.
 

Offline bonnom

  • Newbie
  • Posts: 2
  • Country: nl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1466 on: December 13, 2022, 07:11:05 pm »
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

Could you check if you can flash the PFS122 with the easy-pdk-prog with the PFS172 flag.
If that works we can add PFS122 to easy-pdk-prog and have official support!

edit: forget to say flag
« Last Edit: December 13, 2022, 10:27:01 pm by bonnom »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1467 on: December 14, 2022, 04:40:54 pm »

Could you check if you can flash the PFS122 with the easy-pdk-prog with the PFS172 flag.
If that works we can add PFS122 to easy-pdk-prog and have official support!

edit: forget to say flag

I already checked that and it worked... Then I was unsure if the seller might have mixed up something, so I went to the original "PADAUK_Tool" include files and saw that they all share the same OTP_ID. The OTP_ID is used from original PDAUK_IDE during compilation and embedded inside of the .PDK file. The OTP_ID is the only thing original "PADAUK Writer" uses to check if the correct IC is present.

Means: "Same OTP ID in header files = same IC silicon is used". There are no PFS121, PFS122, PFS172B... there is only the PFS172 ;-)

And in case they would have corrected something in some component (making a new mask) for sure they would have changed the OTP ID in this case.

JS

BTW: I already added PFS121, PFS122, ... as "variant names" to easypdkprog (development branch). SO you can flash them as "PFS121" / "PFS122" / ...
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1468 on: December 14, 2022, 05:34:24 pm »
You can try the previous version of SDCC to get SWAPC to compile, but they I believe you will have to also revert all the .IO syntax.  There is an outstanding bug report about the issue here: https://sourceforge.net/p/sdcc/bugs/3376/.  Hopefully it is resolved for the next release.

I had a quick look at it and added a patch for the swapc bug (https://sourceforge.net/p/sdcc/bugs/3376/). It was introduced with the .io syntax change.

JS
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: serisman

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1469 on: December 14, 2022, 11:21:40 pm »
So i can confirm the PFS122 perfectly programs 'as' PFS172.

Note - PFS122 has a 12bit 'R-type' ADC and is sold as such. It is less accurate than the 'real' ADC which is for example in the PFS232, and it can only use VDD as reference voltage, but it works well for what i do with the PFS122 (a PoE+ inrush controller which limits inrush to PoE levels on a PoE+ device so it can be used on PoE switches without problems, with limited power of course).
Note: the PFS122 include files are missing the ADC low four bit result register, resp. use the 8-bit name for the high ..

THANKS for the swapc patch. it will speed up my code a bit .. gonna try it.

I have to say, i start to love the Padauks. They are working as documented, a really good solution to professional challenges we face, and low price ..  Thanks a lot to the community to have brought the tools and support that far. I will contribute as i can.

Johannes
 
The following users thanked this post: retiredfeline

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1470 on: December 15, 2022, 11:05:52 am »
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.

Could you explain your observation a bit more in detail? I'm working on a cycle accurate emulator which also includes peripherals (parts of it been used in the noiseplug showcase project: https://github.com/free-pdk/easy-pdk-showcase-projects/tree/master/noiseplug/emulation)

You say the assembly code of

set1 PA,#0

will in fact read complete PA (to where), set the bit and then write it back (all in 1 cycle)?

How / what did you observe that lets you assume this?


Or do you mean that the SDCC C compiler might produce 3 opcodes (read, modify, write) for C code like "PA = PA | 1"?


JS

Edit:
When I look at the functional block diagram for IO pins in the datasheet (e.g. page 56 / Fig. 17:  http://www.padauk.com.tw/upload/doc/PFS122%20datasheet_EN_V001_20220518.pdf) I assume, that a bit set instruction ( set1 )

I assume that the IC will only:

- set the "1" for the bit to set on the data bus
- activates the "WR data latch" line so the output data latch (flip flop) for the desired bit (pin) updates the value

« Last Edit: December 15, 2022, 11:26:55 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline jacola

  • Contributor
  • Posts: 15
  • Country: pt
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1471 on: December 21, 2022, 12:22:50 am »
sorry for the delay.
compiler: it will definitely not do the read/modify/write as 3 opcodes, that you would see in the assembly listing and the set0.io instruction is actually assembly already.

i agree you would wish that only one bit would be changed, but this not what i observe.
There is a simple test to do:

add a pull-up (or program a pull-up) on one bit on PA or PB (lets take the example here, PB0).
i want to use PB0 as 'open collector' output (actually for i2c ..)
So i do a set0.io  PB,#0   - to set the bit to 0
after that, using PBC i can make the pin either '1' (due to the pullup) if i configure it as input, or '0' if i configure it as output in PBC.

then, while the bit is 'input', set ANY other bit in PB, one or zero does not matter.
the data bit '0' stored in the holding register for PB0 will be changed to a one, although no-one does a set1.io PB,#0

So it seems setting ANY bit in PB will 'read back' ALL values as seen from the port, change the one bit in question, and write them all to the port's holding register.
In normal situations (where inputs are inputs always) this would not harm as the value in the holding register is not important. however, in my usecase i depend on the 0 to be there, and as it is magically 'changed' now i need to set it to 0 everytime before i enable the output .. doable but annoying and i think its worth a warning.

By the way - i tried the 'undocumented' 16Mhz feature on the PFC154, works well, but it does not work on the PFC232. The PFC232 will not run with that clock option.

Johannes

Johannes
 

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1472 on: December 21, 2022, 11:17:17 pm »
Hello all,

It's been a while, but I just updated the pdk-includes repo with support for a bunch of additional ICs:
- PFC151
- PFC154
- PFC161
- PMS150G/PMS15B

I also added aliases for:
- PFS121, PFS122 (same as PFS172)
- PFS123 (same as PFS173)

This includes a few new peripherals as well:
- Touch (PFC161)
- LVD - Low Voltage Detector (PFC151, PFC161)
- RFC - (Undocumented) Resistance to Frequency Converter (PFC154, PFS154, PFS173)

I also enabled the Undocumented 11-bit ADC for PFS173.

This should bring pdk-includes up to par with all the ICs that the easy-pdk-programmer has include files for (in the development branch)... except for PFC232.

All the changes are currently in the 'new-ics' branch: https://github.com/free-pdk/pdk-includes/tree/new-ics
Pull Request (to capture any discussion) here: https://github.com/free-pdk/pdk-includes/pull/13

I don't have any of these ICs myself, so I can't do any actual testing, but the changes were fairly straightforward so I assume things will mostly work.  I'll merge these changes up to master after waiting a bit for feedback, and after doing some additional testing to make sure I didn't break anything else.
« Last Edit: December 21, 2022, 11:51:54 pm by serisman »
 
The following users thanked this post: EEVblog

Offline serisman

  • Regular Contributor
  • *
  • Posts: 100
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1473 on: December 21, 2022, 11:40:53 pm »
In case anyone is interested...

I finally published a new version of my PDK Continuity Tester (https://github.com/serisman/pdk-continuity-tester) that solves an issue that was raised a while ago, and uses a better form factor.

I also finally published a simple PDK based Logic Probe (https://github.com/serisman/pdk-logic-probe) that can be a useful tool for breadboarding or troubleshooting.

Enjoy!
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1474 on: December 24, 2022, 06:17:29 am »
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.

Could you explain your observation a bit more in detail? I'm working on a cycle accurate emulator which also includes peripherals (parts of it been used in the noiseplug showcase project: https://github.com/free-pdk/easy-pdk-showcase-projects/tree/master/noiseplug/emulation)

Would it make sense to merge this work into the uCsim simulators that SDCC uses?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf