EEVblog #1144 - Padauk Programmer Reverse Engineering

[bingo600]

Yeah, but that is not done because this is acceptable style, but because SDCC is not able to remove unused functions from the binary... I know I am also guilty of this, but generally no code should be in the include files.

Ahh so it's optimal (codesize) to compile in one large source file ??
That sounds a bit like a linker issue , not being able to skip unused functions.

/Bingo

[js_12345678_55AA]

I haved documented the code options and how to use them here: https://free-pdk.github.io/tutorial#code-options

Hi,

the PADAUK IDE code options divide into 2 parts: Real options set in fuse (usually only startup speed, IO drive current and security).
All other code options are "virtual" (you will find this keyword a lot in the PADAUK IDE .INC files) which means they will be written by PADAUK created startup code into other registers.
This means your question "It is unclear whether you are allowed to change these code options while the µC is running, or whether you are supposed to only set them once and leave them as they are." is in fact easy to answer: Yes you can set this values from code whenever you want (PADAUK IDE inserted startup code is doing exactly this).
Also I would not call them "undocumented registers". The PADAUK IDE .INC files do document those registers very well. The virtual option tells you exactly which register and which bits will be setup by the code option you choose in PADAUK IDE.

JS

[Talrey]

Yup. Tried every boolean combination of Button First | Plugging In | Button While Doing lsusb. No change in the output.

Does your device enumerate when you plug it in while the button is pressed? It should show up as "STM32 BOOTLOADER". If it does not, then there is certainly a hardware issue, like a solder bridge or incomplete connection. Trying to program the device with SWD will not make that issue go away. Choose wisely where you spend your effort

Did you check the 3.3V supply? Did you check the USB connection on the PCB?

Ah, yeah, nothing is enumerating with lsusb. I'll start poking with my meter, then. Thanks.

[Talrey]

 

I feel like quite the fool now. It turns out that tacky flux like you'd use in a reflow oven is quite the insidious chemical.
All I had to do was replace the button, flux seems to have wormed its way inside and disabled it. A fresh button from the batch passed continuity, the original didn't.

One sudo whack at it later and it's flashed. Next will be getting it to talk to a real chip, it complains there's "nothing found" with more verbosity saying "command ack failed / wrong icid".
I guess it's round two with the multimeter 

I wonder if a dunk in isopropyl would clear the button out. Not like I don't have a dozen more on hand, but I might still try it as an investigation of the flux.
I certainly won't be doing the next board the same way!

[tim_]

I feel like quite the fool now. It turns out that tacky flux like you'd use in a reflow oven is quite the insidious chemical.
All I had to do was replace the button, flux seems to have wormed its way inside and disabled it. A fresh button from the batch passed continuity, the original didn't.

One sudo whack at it later and it's flashed. Next will be getting it to talk to a real chip, it complains there's "nothing found" with more verbosity saying "command ack failed / wrong icid".
I guess it's round two with the multimeter 

I wonder if a dunk in isopropyl would clear the button out. Not like I don't have a dozen more on hand, but I might still try it as an investigation of the flux.
I certainly won't be doing the next board the same way!

Yeah, after a couple iterations, the typical points of failure become obvious

You should compile "easypdkprogtest" and check for the voltages to verify that the programming voltage control works properly.

[pacmancoder]

Hello! Firstly, I want to thank you all for such great work on the Padauk MCUs ecosystem, keep it up  !

Recently I was interested in using a FreePDK ecosystem because I was not satisfied with the official
software/programmer. Because the original easy-pdk-programmer still needs some components to be purchased and
soldered manually (e.g. USB port, STM32 MCU because it is 0 in stock at jlcpcb), I decided to make easy-to-handsolder
programmer version based on "lite" version schematics by tim_. (But honestly, I just love to solder devices by
myself, so this was the main reasoning behind this )

All passives have at least 0805 sizes, and the mini-USB port was used instead of micro-USB,
so it should be relatively easy to solder this programmer by the hand. The only quirky parts
which may be hard to solder are STM32 MCU and MT3608 boost converter.

Although the existing "lite" version of easy-pdk-programmer by tim_
(which was used as a reference for this project) is relatively simple by itself, some additional
simplifications/changes were made:

• Removed 20Ohm USB series resistors. According to the STM32F072 datasheet:
    "No external termination series resistors are required on USB_DP (D+) and USB_DM (D-);
    the matching impedance is already included in the embedded driver"
• Replaced the boot button with a simple jumper
• Replaced 47uF boost converter output capacitor with two 22uF caps to simplify the process of
    gathering components (Mainly because in my city I was not able to find 47uF 16v,
    while it was easy to find 22uF 25V)
• Replaced MicroUSB for MiniUSB (again, for ease of soldering)
• Added pull-down resistor for PB8 to make programmer detect as "lite" hardware - Is I saw in the latest
    firmware for easypdk, this should force firmware to use "lite" hardware variant id (Am I right?)
• Project was made using KiCAD instead of EasyEDA

 
I am still concerned about my routing skills, because I am relatively new to hardware development, so feel free
to correct me if I did something wrong (You can text me here or directly add the issue on the GitHub). The design is not even tested
yet, so it is still work-in-progress but I hope I will be able to polish it on this week and order the PCBs)

Github repo: https://github.com/pacmancoder/easy-pdk-mini

UPD 08.09.2020: Updated project on GitHub:
Added 0.5A 6V PTC fuse, slightly improved routing, changed board dimensions to less bizarre, fixed silkscreen, and drawings layers problems.

UPD 08.09.2020 (2): Update project again:
Small polishing changes before PCB production. Uploaded gerbers, updated images (new revision on the GitHub)

[Talrey]

I feel like quite the fool now. It turns out that tacky flux like you'd use in a reflow oven is quite the insidious chemical.
All I had to do was replace the button, flux seems to have wormed its way inside and disabled it. A fresh button from the batch passed continuity, the original didn't.

One sudo whack at it later and it's flashed. Next will be getting it to talk to a real chip, it complains there's "nothing found" with more verbosity saying "command ack failed / wrong icid".
I guess it's round two with the multimeter 

I wonder if a dunk in isopropyl would clear the button out. Not like I don't have a dozen more on hand, but I might still try it as an investigation of the flux.
I certainly won't be doing the next board the same way!

Yeah, after a couple iterations, the typical points of failure become obvious

You should compile "easypdkprogtest" and check for the voltages to verify that the programming voltage control works properly.

Hmm... what are the voltages supposed to be? I got 19.83, 5.01, and vref=3.31.

Based on the source for the test, pressing the button should light an LED, but it didn't.
Also, there's a keypress time-out function, but it didn't respond to that either. I had to kill the program with ^C.
Gave it about four runs, same results each time... but now the programmer's just vanished from USB. I guess something failed on the board and took the STM offline.

[tim_]

Hmm... what are the voltages supposed to be? I got 19.83, 5.01, and vref=3.31.

Based on the source for the test, pressing the button should light an LED, but it didn't.
Also, there's a keypress time-out function, but it didn't respond to that either. I had to kill the program with ^C.
Gave it about four runs, same results each time... but now the programmer's just vanished from USB. I guess something failed on the board and took the STM offline.

Uhm, the voltages should be 5.0 V, 5.0V and 3.3 V. 19.85 certainly is too high, this is even above the nominal boost converter output. Did you miss any resistors anywhere, or are some values are mixed up?

[Talrey]

Uhm, the voltages should be 5.0 V, 5.0V and 3.3 V. 19.85 certainly is too high, this is even above the nominal boost converter output. Did you miss any resistors anywhere, or are some values are mixed up?

I'll grant that the build process was a bit messy, but I've probed the lines around the 15V and compared them to the schematics. Definitely not missing anything either.
R17 was reading really low (31kOhm to the stated 100kOhm), but I think that's because I'm measuring it in-circuit: 31kOhm matches the equivalent resistance across it due to some other resistors forming a second path through ground.

Actually, I checked the voltage in a few places while it was plugged in... and the 15V is indeed 15V.
No idea why the program was reading 19.8, and I can't verify because it's not responding.

I wonder if the STM itself was causing the higher voltage somehow, and kicked the bucket so it's not interfering any more? 

[tim_]

I have been working with the PFS173 again, only to bump into some additional oddities. Not sure where else to document this:

Power on reset

It seems that the PFS173 power on reset does not work if the slew rate is too low. My power supply takes around 50 ms to ramp to final voltage. This will lead to the PFS173 not starting at all. See waveform here:

When I detach and attach the connection manually, everything is fine:

11 Bit PWM

It took me quite a while to figure out why the PWM frequency was never the one I tried to set: The 11 Bit PWM is actually a 10 bit counter. The eleventh bit is generated by a ANDing the LSB with the clock. Therefore only 1024 maximum counts should be assumed when calculating the PWM frequency.

Some more findings:

Using port B as input

It seems that the input enable register PBDIER has a default reset state of 0x00, while that datasheet states that it is 0xff. I wonder whether this is actually an errata or maybe the registers are usually set by Mini-C.

GPIO rise an fall times

The rise and fall times of the GPIO used in output mode are suprisingly slow. In the image below you can see the output of the PFS173 (yellow trace), loaded with a WS2812 and a scope probe, and the signal after it was regenerated by a WS2812.

The rise tim of the PF173 is 32 ns, while the fall time is 50ns. The WS2812 (and also other MCUs) have a tr/tf of <5ns into the same load. The tr/tf of the PFS173 is much lower than even the current drive abilities suggest. So this seems to be an intentional design feature. My guess is that helps to protect their on chip supply (a step signal will cause the internal supply to bounce around), without having to introduce additional measures like an internal LDO.



interrupt latency

I measured interrupt latency to be 6 cycles till the first instruction of the interrupt handler. Can anyone confirm this? Jitter is 2 cycles, assuming an infinite rjmp loop in the main program.

[cmfcmf]

It seems that the input enable register PBDIER has a default reset state of 0x00, while that datasheet states that it is 0xff. I wonder whether this is actually an errata or maybe the registers are usually set by Mini-C.

The latter is true, see also https://free-pdk.github.io/tutorial#registers

[tim_]

It seems that the input enable register PBDIER has a default reset state of 0x00, while that datasheet states that it is 0xff. I wonder whether this is actually an errata or maybe the registers are usually set by Mini-C.

The latter is true, see also https://free-pdk.github.io/tutorial#registers

Hm... I cannot imagine that all registers contain random values at reset, because there certainly are some combinations that would cause undesireable behavior.
Maybe only a few registers are off. But that's something that can be easily checked.

[cmfcmf]

It seems that the input enable register PBDIER has a default reset state of 0x00, while that datasheet states that it is 0xff. I wonder whether this is actually an errata or maybe the registers are usually set by Mini-C.

The latter is true, see also https://free-pdk.github.io/tutorial#registers

Hm... I cannot imagine that all registers contain random values at reset, because there certainly are some combinations that would cause undesireable behavior.
Maybe only a few registers are off. But that's something that can be easily checked.

True - the wording can certainly be improved. When I wrote "undefined", I meant "is initialized to a fixed value that may differ from the datasheet, therefore its better to always set all registers explicitly". Of course, it would be even better to have a definitve list of all µCs and their respective true initial register values.

[tim_]

Hm... I cannot imagine that all registers contain random values at reset, because there certainly are some combinations that would cause undesireable behavior.
Maybe only a few registers are off. But that's something that can be easily checked.

True - the wording can certainly be improved. When I wrote "undefined", I meant "is initialized to a fixed value that may differ from the datasheet, therefore its better to always set all registers explicitly". Of course, it would be even better to have a definitve list of all µCs and their respective true initial register values.

I wrote a small program to dump the initial content of the PFS173 I/O area.
It's invoked in  _sdcc_external_startup(void) and first copies all registers to the ram, so apart from the flag register and the stack pointer everything should be unchanged.

It seems that CLKCMD is initialized with 0x9e at reset. All other readable bits appear to be zero.

It appears that accessing unused registers or write only registers often yields the result from the previous access. Possible an issue with a floating internal bus.

I wonder what is going on with 2E and 2F? 2F seems to be unstable and changes values between 0x21 and 0x61.

Code: [Select]

Dumping initial state of I/O area
00: F0 F0 A6 9E 00 08 00 00
08: 00 00 00 00 00 00 00 00
10: 20 00 00 00 00 00 00 00
18: 00 00 00 00 00 00 00 00
20: 40 00 FF E0 E0 E0 E0 E0
28: E0 E0 E0 00 00 E0 60 61
30: 00 00 00 00 00 00 00 00
38: 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00
48: 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00
58: 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00
68: 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00
78: 00 00 00 00 00 00 00 00

Edit: It seems that the I/O register data bus will simply hold the previous value when reading from a WO or nonexistant register. When writing a value to one register, the same value will appear when reading from an invalid location.

Using that fact it is possible to identify all write only or nonexistant registers. In the hexdump below, every such register is marked with 0x55.

Code: [Select]

Dumping initial state of I/O area
00: F0 55 A6 9E 00 08 00 55
08: 55 55 55 55 55 55 55 55
10: 20 00 00 00 00 00 00 55
18: 00 00 00 55 55 55 55 55
20: 40 00 FF E0 55 55 55 55
28: 55 55 55 00 55 E0 60 21
30: 00 00 55 55 00 00 55 55
38: 55 55 55 55 55 55 55 55
40: 00 55 55 55 55 55 00 55
48: 55 55 55 55 00 55 55 55
50: 55 55 55 55 55 55 55 55
58: 55 55 55 55 55 55 55 55
60: 55 55 55 54 55 55 55 55
68: 55 55 55 55 55 55 55 55
70: 55 55 55 55 55 55 55 55
78: 55 55 55 55 55 55 55 55

Hm... there seems to be something undocumented at the adresses 0x2d, 0x2e,  0x2f

Hmmm....  0x2d is cleary a control register. Reset state is 0xE0. Bits 7-5,3,1,2 are R/W, Bits 4 and 2 RO. 0x2e and 0x2f appear to be read only.
Any ideas what this could be? It's also not mentioned in the official includes. These could possibly be test registers.

[js_12345678_55AA]

Hm... there seems to be something undocumented at the adresses 0x2d, 0x2e,  0x2f
Hmmm....  0x2d is cleary a control register. Reset state is 0xE0. Bits 7-5,3,1,2 are R/W, Bits 4 and 2 RO. 0x2e and 0x2f appear to be read only.
Any ideas what could this be? It's also not mentioned in the official includes. These could possibly be test registers.

I think I have an idea what it could be...

Some time ago when I was deep into research I found out about the really undocumented RFC (Resistance to Frequency Converter). This might be used as a poor men's touch interface or ADC?
You can still find some comments only in some of the PDK .INC files.

After digging a bit deeper I found some info in an old Puolop datasheet for PTBO165C : http://www.htsemi.com/xiazai.aspx?aa=/include/upload/download/_20180709113738742.pdf&bb=PTBO165CXXS

Sections 3 and 4:
3. RF Inverters Functions Description
4. RFC (Resistance to Frequency Converter) Functional Description

This small data sheet explains register settings and how to use them. From the PDK .INC files it is also obvious that this feature is present in some more IC (not only in 165C). Maybe it is just not working and that's why missing from data sheet or it is sold as extra feature in different IC marketing derivates.

Have fun,

JS

[tim_]

Hm... there seems to be something undocumented at the adresses 0x2d, 0x2e,  0x2f
Hmmm....  0x2d is cleary a control register. Reset state is 0xE0. Bits 7-5,3,1,2 are R/W, Bits 4 and 2 RO. 0x2e and 0x2f appear to be read only.
Any ideas what could this be? It's also not mentioned in the official includes. These could possibly be test registers.

I think I have an idea what it could be...

Some time ago when I was deep into research I found out about the really undocumented RFC (Resistance to Frequency Converter). This might be used as a poor men's touch interface or ADC?
You can still find some comments only in some of the PDK .INC files.

After digging a bit deeper I found some info in an old Puolop datasheet for PTBO165C : http://www.htsemi.com/xiazai.aspx?aa=/include/upload/download/_20180709113738742.pdf&bb=PTBO165CXXS

Sections 3 and 4:
3. RF Inverters Functions Description
4. RFC (Resistance to Frequency Converter) Functional Description

This small data sheet explains register settings and how to use them. From the PDK .INC files it is also obvious that this feature is present in some more IC (not only in 165C). Maybe it is just not working and that's why missing from data sheet or it is sold as extra feature in different IC marketing derivates.

Wow, nice find! That does indeed exactly match the pattern of R/W and RO/WO bits. Will look into this

Edit: The PFC154 actually still has the register descriptions in the .INC file and they exactly match to the locations found for the PFS173. Interestingly there is no mentioning of this functionality in the datasheet.

Code: [Select]

RFCC IO_RW 0x36 (0x2D, -)
$ 7 ~ 5, 0 : PA4, PB4, PA0, PB3, X, PB2, X, PB1,
PA3, PB0, PB7, X, PB6, X, DISABLE : 0xE
$ 4 : X, START : WR_BIT
$ 3 : R_TYPE, C_TYPE // PA4 only for C_TYPE
// ICE Only support R_TYPE
$ 2 : X, Overflow
$ 1 : X, Output // PB5

RFCCRH IO_RO 0x37 (0x2E, -)
RFCCRL IO_RO 0x38 (0x2F, -)

Also note that the linecard still shows the RFC functionality in the footnotes (http://www.padauk.com.tw//upload/SelectionGuide/selection_guide_2019H1__20190227_EN-2.png), but there is no device listed.

Seems indeed like this functionality was retroactively removed. Possibly it did not perform well...

EDIT: It actually works! The register mapping of the RFC in the PFS173 is the same as in the PFC154. Essentially this peripheral forms an RC oscillator with an RC pair that is connected to a selectable pin. There is a 16 bit counter to count pulses from the RC oscillator which has to be manually started and stopped. I was able to use this circuit to read out light levels incident on a LED, where the LED is abused as a photodiode.

it should also be possible to use this peripheral for touch sensing or as a plant moisture sensor.

The functionality is a bit limited, because the counter has to be manually started and stopped by software. Also, only one channel at a time can be operated.

What is still lacking, is a description of the schmitt trigger voltages.

[js_12345678_55AA]

interrupt latency
I measured interrupt latency to be 6 cycles till the first instruction of the interrupt handler. Can anyone confirm this? Jitter is 2 cycles, assuming an infinite rjmp loop in the main program.

Did you use SDCC to define the interrupt ?
* SDCC places a GOTO at ISR vector (+2 cycles)
* SDCC adds automatically 3 instructions to a function marked as "interrupt": "push af / mov a, p / push af" (+3 cycles)

Since we need to assume that PC needs to be saved as well (IC is doing this on it's own) this add another (+1 cycle)

==> 2+3+1 = 6 cycles.

Somewhere back in this thread I gave an example how to trick SDCC not to write a GOTO but define ISR directly at ISR vector. Also by specifying the function "naked" you can do the register saving on your own.

This might bring you an ISR latency of only 1 cycle.



JS

[js_12345678_55AA]

Hi,

Your main loop is executing an endless loop with GOTO. This is absolute worst case since for sure interrupt will not execute while one instruction is running.

Since GOTO is using 2 instructions, latency of interrupt will be +2 cycles for this worst case.
I'm sure if you make a dummy loop out of 10 NOPs and 1 GOTO then the average latency will go down by 1 cycle.

Now calculations is:
+2 cycles from GOTO in main loop - absolute worst case (maybe use an endless loop with stopexe. This should reduce it to +1 cycle worst case)
+1 cycle store PC before entering ISR
+2 cycles for the GOTO from SDCC
+3 cycles for storing AF + p
+1 cycle to execute your set1 instruction
====
= 8-9 cycles which is very close to your measurement.

JS

[js_12345678_55AA]

It seems that the PFS173 spends two more cycle on something else...

That's interesting and good to know for a cycle accurate emulation :-)

Maybe you can change the main loop to set / reset another output pin so the 2 ghost cycles can be proofed:

$1:
    set1 PB,2
    set0 PB,2
    set1 PB,2
    set0 PB,2
    set1 PB,2
    set0 PB,2
    set1 PB,2
    set0 PB,2
    set1 PB,2
    set0 PB,2
    goto $1

Thanks for your research.

[tim_]

FYI, the RFC can also be found in the PFS154. Found in S08 and S16, so I guess it is in all package versions of the PFS154.

It's at addresses 0x36,0x37,0x38, just as indicated in the PFC154 include file.

I/O space dump below. There do not seem to be any other undocumented R/W or RO registers.

0x55 is an unused or WO register, the other value reflect the reset state.

Code: [Select]

Dumping initial state of I/O area
00: F0 55 66 9E 00 87 00 55
08: 55 55 55 55 55 55 55 55
10: 01 00 00 55 00 00 00 55
18: 00 55 54 55 00 00 55 55
20: 00 55 55 55 55 55 00 55
28: 55 55 55 55 00 55 55 55
30: 55 55 00 00 55 55 F4 00
38: 00 55 55 55 55 55 55 55


[pacmancoder]

A little update about easy-pdk-mini project (easy-pdk-programmer-lite based programmer variant for handsoldering):
- First revision boards were delivered to me and I assembled a single board using only my soldering iron, so the main idea of my board variant holds well!
- I messed up schematics for opamp wiring when porting EasyEDA schematics to the KiCAD, so to make the first revision boards work, some trace-cutting and wire soldering was required .
- But in the end, It works! I am happily flashed PMS150C and PFS173 chips (Bye-bye, horrible Padauk's Mini-C!)

As for the second board revision, I changed the following:
- Fixed opamp wiring. Now everything should work perfect.
- USB-B Through-hole port is used instead of Mini-USB, because Mini-USB soldering without hot air soldering station is, indeed as painful as Micro-USB hand-soldering.

The updated board files can be downloaded from my github repo, if anyone interested.

[ali_asadzadeh]

JS, would you please add the STM32 Bin file along the DFU one too,
In a new design I have connected bootpin to ground, I can only program the STM32 with j-link and it would accept bin file or hex file.

Thanks

[js_12345678_55AA]

JS, would you please add the STM32 Bin file along the DFU one too,
In a new design I have connected bootpin to ground, I can only program the STM32 with j-link and it would accept bin file or hex file.

Thanks

Hi,

the .DFU file is same as the .BIN file. It just has a few of extra bytes appended to the end. It does not matter if you use the .DFU file and flash it as .BIN file. The extra bytes at the end will by ignored.


JS

[ali_asadzadeh]

Thanks JS,
How we can set LVR for PFS173,
Is there any example code?
I want to set it to 4.0V

[js_12345678_55AA]

Thanks JS,
How we can set LVR for PFS173,
Is there any example code?
I want to set it to 4.0V

In case you use the include file from "easypdk/pfs173.h" then setting LVR to 4.0V can be done like this (place it in _sdcc_external_startup() function):

MISCLVR = MISCLVR_4V;

Also make sure that you do NOT set MISC_LVR_DISABLE ins MISC register.


JS