EEVblog #1144 - Padauk Programmer Reverse Engineering

[spth]

I can only corroberate JS findings about very bad noise immunity of the PFS154.

I wasted a lof time getting a LED to work as a light sensor on the PFS154. My only conclusion is that the PFS154 has severe internal coupling issues. I summarized my findings here:

https://cpldcpu.wordpress.com/2019/09/28/a-led-candle-based-on-the-3-cent-mcu/

It seems to be advised to stick to purely digital designs, at least for the lower end Padauk MCUs.

Bad noise immunity on the PFS series is not a surprise, it is even stated by Padauk in their catalog. The otherwise closest devices, but with claimed much better noise immunity would be the PFC series. Though teh PFC154 is marked as a "new" device, so it might take a few weeks until it arrives at distributors.

[tim_]

Bad noise immunity on the PFS series is not a surprise, it is even stated by Padauk in their catalog. The otherwise closest devices, but with claimed much better noise immunity would be the PFC series. Though teh PFC154 is marked as a "new" device, so it might take a few weeks until it arrives at distributors.

Yeah, it's kinda telling if the manufacturer mentions it even on their line card. Although, bad PSRR/EMI immunity does not neccesarily imply that there is also strong internal coupling. In this case it seems to be like that.

I wonder, has anybody tried the ADC in the PFS173 yet? How many bits are actually noise free?

[socram]

I've tried setting the last word but it seems there's some kind of either protection or sorcery going on - I cannot change it to anything:

Code: [Select]

> write-pfs154.py honk.ihx com3
Writing 0000-0007... done
Writing 0010-00AB... done
Writing 07FF-07FF... done
Verifying 0000-0007... OK
Verifying 0010-00AB... OK
Verifying 07FF-07FF... FAILED
@ 07FF - expected 0000, read 3FFF

I have VPP set to 5.8V and the rest of the flash seems to be programmable just fine. Should I do anything special to program this last word?

[js_12345678_55AA]

I've tried setting the last word but it seems there's some kind of either protection or sorcery going on - I cannot change it to anything:

Code: [Select]

> write-pfs154.py honk.ihx com3
Writing 0000-0007... done
Writing 0010-00AB... done
Writing 07FF-07FF... done
Verifying 0000-0007... OK
Verifying 0010-00AB... OK
Verifying 07FF-07FF... FAILED
@ 07FF - expected 0000, read 3FFF

I have VPP set to 5.8V and the rest of the flash seems to be programmable just fine. Should I do anything special to program this last word?

There is no magic for last word. It looks like your programmer / programming script tries to write to odd address. PFS devices only can start writing at even addresses (this means you have to write 7FE and 7FF, you can write "FFFF" to 7FE so it will not change the exisiting value, just the verifier in your script needs to know about this fact afterwards).

JS

[js_12345678_55AA]

Bad noise immunity on the PFS series is not a surprise, it is even stated by Padauk in their catalog. The otherwise closest devices, but with claimed much better noise immunity would be the PFC series. Though teh PFC154 is marked as a "new" device, so it might take a few weeks until it arrives at distributors.

Yeah, it's kinda telling if the manufacturer mentions it even on their line card. Although, bad PSRR/EMI immunity does not neccesarily imply that there is also strong internal coupling. In this case it seems to be like that.

I wonder, has anybody tried the ADC in the PFS173 yet? How many bits are actually noise free?

I think PFS173 is the better way to go for your specific project.

I got PFS173 in small 6 pin housing for 4.6 cent / pcs. So no real need for me to use PFS154 or PMS150C:  https://item.taobao.com/item.htm?id=598420620199

JS

[socram]

There is no magic for last word. It looks like your programmer / programming script tries to write to odd address. PFS devices only can start writing at even addresses (this means you have to write 7FE and 7FF, you can write "FFFF" to 7FE so it will not change the exisiting value, just the verifier in your script needs to know about this fact afterwards).

JS

Thank you! I will try to have my programmer align to chunks of 4 words.

EDIT: that did the job! Thank you again!

[socram]

As oposed to what https://github.com/free-pdk/fppa-pdk-documentation/blob/master/Reserved_Area_Last_8_Words_Of_Codemem.txt says, the LVR seems not to be configured via the last word but the MISC_LVR register:

For 4.0V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x00
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 3.5V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x20
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 3.0V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x40
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.75V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x60
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.5V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x80
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 1.8V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0xA0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.2V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0xC0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.0V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0xE0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

[tim_]

I think PFS173 is the better way to go for your specific project.

I got PFS173 in small 6 pin housing for 4.6 cent / pcs. So no real need for me to use PFS154 or PMS150C:  https://item.taobao.com/item.htm?id=598420620199

JS

Thats a very good offer. How did you manage to order there?

I tried to investigate the PFS173 ADC only to find that ASPDK15 does not encode the SWAPC instruciton correctly, which is used in my softuart. Took quite a while to find this. Ticket to SDCC is submitted. Obviously, SDCC never generates a SWAPC, so it is not covered in the regression tests...

[js_12345678_55AA]

As oposed to what https://github.com/free-pdk/fppa-pdk-documentation/blob/master/Reserved_Area_Last_8_Words_Of_Codemem.txt says, the LVR seems not to be configured via the last word but the MISC_LVR register:

For 4.0V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x00
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 3.5V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x20
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 3.0V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x40
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.75V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x60
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.5V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0x80
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 1.8V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0xA0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.2V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0xC0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

For 2.0V:

Code: [Select]

0x0007:   0x2fe0    MOV A, 0xE0
0x0008:   0x019b    MOV IO(0x1B), A  ;MISC_LVR

Depends on the IC. The raw (very early) notes reference PMC154B with some similarities from PFS154. PMC154B does not have MISC_LVR register.

A better way is to use the original IDE, play with the "code options" for your specific CPU and document the results.

[js_12345678_55AA]

I think PFS173 is the better way to go for your specific project.

I got PFS173 in small 6 pin housing for 4.6 cent / pcs. So no real need for me to use PFS154 or PMS150C:  https://item.taobao.com/item.htm?id=598420620199

JS

Thats a very good offer. How did you manage to order there?

I know some local guys ordering it for me and forward it.

But now that we know it exists: It is possible to query LCSC.com to get special parts which they do not have in inventory...

[socram]

Regarding the MISC_LVR register again - was that name found somewhere in official PADAUK docs or in the IDE code or somewhere else? I am wondering because otherwise, maybe it would be sensible to rename it to MISCLVR (without the underscore), or lvrc (LVR control, as other control registers are the name of the peripheral + "c" such as tm2c or gpcc).

The problem with MISC_LVR is that I wanted to make a PR to cpldcpu's io_pfs154.h to include the bits that the IDE generates for several voltages for the PFS154, but there's already a MISC_LVR_DISABLE, and IMHO it would be confusing that this one refers to the misc register, and MISC_LVR_1_8V (for setting LVR to 1.8V, for example) refers to the MISC_LVR register.

[tim_]

Regarding the MISC_LVR register again - was that name found somewhere in official PADAUK docs or in the IDE code or somewhere else? I am wondering because otherwise, maybe it would be sensible to rename it to MISCLVR (without the underscore), or lvrc (LVR control, as other control registers are the name of the peripheral + "c" such as tm2c or gpcc).

The problem with MISC_LVR is that I wanted to make a PR to cpldcpu's io_pfs154.h to include the bits that the IDE generates for several voltages for the PFS154, but there's already a MISC_LVR_DISABLE, and IMHO it would be confusing that this one refers to the misc register, and MISC_LVR_1_8V (for setting LVR to 1.8V, for example) refers to the MISC_LVR register.

It's called like that in the official include for from the IDE (PFC154.INC), see below. The underscore does not fit to general conventions indeed.

JS has included the underscore in the defines.
https://github.com/free-pdk/easy-pdk-programmer-software/blob/master/Examples/src/easypdk/pfs154.h#L195

Code: [Select]

	MISC_LVR		IO_WO:OP	0x1B (-)
		$ 7 ~ 4 :	1V8, 1V9, 2V, 2V1, 2V2, 2V3, 2V4, 2V5, 2V75, 3V, 3V15, 3V3, 3V5, 3V75, 4V, 4V5
		$ 1 ~ 0	:	BG_On, BG/4, BG/32, BG_Auto

[itelite]

Maybe i missed this somewhere, but im not seeing it in the documentation.

I built the programmer, flashed firmware. All seems well.  I would like to program the 6 pin PMS150c, but i do not know how to wire to the output headers.  I have the PMS150 on a breakout board stuck into a bread board, with the intent to run jumper wires from the headers to the breadboard.  Any guidance would be appreciated.

[electronic_eel]

Maybe i missed this somewhere, but im not seeing it in the documentation.

I built the programmer, flashed firmware. All seems well.  I would like to program the 6 pin PMS150c, but i do not know how to wire to the output headers.

It is documented vaguely in the datasheets and manual for the official programmer from Padauk. You'd have to read several of the controller datasheets, the protocol description in this thread and on github and then slowly the pieces begin to fall together.

But I also made an adapter pcb which should make it easy: https://github.com/free-pdk/easy-pdk-programmer-hardware/tree/master/adapter-pcbs. You could replicate that on your breadboard. See the schematics. The inner columns are the programmer, the outer ones the Padauk.

[chaplin]

hi,
i build my own easy-pdk-programmer  , but can't write ,Other operations are OK。

this my board pic

any idea what might goes wrong?

[js_12345678_55AA]

hi,
i build my own easy-pdk-programmer  , but can't write ,Other operations are OK。
(Attachment Link)
this my board pic

any idea what might goes wrong?

Hi,

it looks very good already.

The problem you see can be caused by long wires / dirty contacts of adapter / ... so VDD or VPP is not supplied properly to IC.
Usually reseating the IC in socket / using shorter wires solves this problem.

How do you connect the PFS173 to the programmer?


Also please check values and soldering of:
 C2 / C10 (must be 100nF, they stabilize VDD and VPP)
and
 C13 / C21 (must be 4.7uF, they stabilize the opamp inputs)

JS

[itelite]

Maybe i missed this somewhere, but im not seeing it in the documentation.

I built the programmer, flashed firmware. All seems well.  I would like to program the 6 pin PMS150c, but i do not know how to wire to the output headers.

It is documented vaguely in the datasheets and manual for the official programmer from Padauk. You'd have to read several of the controller datasheets, the protocol description in this thread and on github and then slowly the pieces begin to fall together.

But I also made an adapter pcb which should make it easy: https://github.com/free-pdk/easy-pdk-programmer-hardware/tree/master/adapter-pcbs. You could replicate that on your breadboard. See the schematics. The inner columns are the programmer, the outer ones the Padauk.

Oh ok good.  I can work with that.  I just realized based on the photos in the above post that the pins are meant to be marked on the PCB.  The silkscreening on my PCB is so bad that it all looks like smudges ha.  Thats what threw me for sure.

[chaplin]

hi,
i build my own easy-pdk-programmer  , but can't write ,Other operations are OK。
(Attachment Link)
this my board pic

any idea what might goes wrong?

Hi,

it looks very good already.

The problem you see can be caused by long wires / dirty contacts of adapter / ... so VDD or VPP is not supplied properly to IC.
Usually reseating the IC in socket / using shorter wires solves this problem.

How do you connect the PFS173 to the programmer?


Also please check values and soldering of:
 C2 / C10 (must be 100nF, they stabilize VDD and VPP)
and
 C13 / C21 (must be 4.7uF, they stabilize the opamp inputs)

JS

thanks JS,
I made a test board,  only PFS173 and Female Socket were soldered. I also checked   C2 / C10，C13 / C21 , and they were correct.

[js_12345678_55AA]

hi,
i build my own easy-pdk-programmer  , but can't write ,Other operations are OK。
(Attachment Link)
this my board pic

any idea what might goes wrong?

Hi,

it looks very good already.

The problem you see can be caused by long wires / dirty contacts of adapter / ... so VDD or VPP is not supplied properly to IC.
Usually reseating the IC in socket / using shorter wires solves this problem.

How do you connect the PFS173 to the programmer?


Also please check values and soldering of:
 C2 / C10 (must be 100nF, they stabilize VDD and VPP)
and
 C13 / C21 (must be 4.7uF, they stabilize the opamp inputs)

JS

thanks JS,
I made a test board,  only PFS173 and Female Socket were soldered. I also checked   C2 / C10，C13 / C21 , and they were correct.
(Attachment Link)

Hi,

On your test board you added more capacitors. This can cause the problem. With additional caps VPP and VDD might need more time / need to be a tiny bit higher to stabilize.
Could you try your extra test board without the capacitors?

Also which version of the programmer software + firmware do you use?
Latest 1.1 version (https://github.com/free-pdk/easy-pdk-programmer-software/releases) contains some improvements regarding writing of PFS173.

JS

[itelite]

ok ive made a little progress.  Programer is detected, chip is detected and id.  when i try to program the hello world 150c i get a successful write, but a failed verify.    if i try to write again it says chip is not blank (of course)

Running easypdk start i do not get a hello world, but i dont know if i am supposed to.

Not sure how to debug this. Running verbose doesn't seem to give anything further.   Tried 2 chips with same result just to make sure.

Also, what are these IHX files all about?  How does one convert a PDK project made in the official IDE to this format?

[spth]

ok ive made a little progress.  Programer is detected, chip is detected and id.  when i try to program the hello world 150c i get a successful write, but a failed verify.    if i try to write again it says chip is not blank (of course)

Running easypdk start i do not get a hello world, but i dont know if i am supposed to.

Not sure how to debug this. Running verbose doesn't seem to give anything further.   Tried 2 chips with same result just to make sure.

Also, what are these IHX files all about?  How does one convert a PDK project made in the official IDE to this format?

As mentioned before, the symptoms could be due to too much capacitance across VDD or sue to the user of an older version of the programmer software.
The programmer should work fine with the Padauk-recommended maximum of 0.01 µF though.

.ihx is Intel Hex, a rather common format (SDCC emits .ihx by default; the Padauk Mini-C IDE uses some weird obfuscated non-standard thing instead).

[js_12345678_55AA]

ok ive made a little progress.  Programer is detected, chip is detected and id.  when i try to program the hello world 150c i get a successful write, but a failed verify.    if i try to write again it says chip is not blank (of course)

Running easypdk start i do not get a hello world, but i dont know if i am supposed to.

Not sure how to debug this. Running verbose doesn't seem to give anything further.   Tried 2 chips with same result just to make sure.

Also, what are these IHX files all about?  How does one convert a PDK project made in the official IDE to this format?

Hi,

can you try to read the written IC and check what was actually written?

You also can disable the blank check and try to write the IC again with the same file (see command line option of easypdkprog: --noblankchk). In case some bits not been written in the first run this can fix this situation.

JS

[js_12345678_55AA]

Regarding the MISC_LVR register again - was that name found somewhere in official PADAUK docs or in the IDE code or somewhere else? I am wondering because otherwise, maybe it would be sensible to rename it to MISCLVR (without the underscore), or lvrc (LVR control, as other control registers are the name of the peripheral + "c" such as tm2c or gpcc).

The problem with MISC_LVR is that I wanted to make a PR to cpldcpu's io_pfs154.h to include the bits that the IDE generates for several voltages for the PFS154, but there's already a MISC_LVR_DISABLE, and IMHO it would be confusing that this one refers to the misc register, and MISC_LVR_1_8V (for setting LVR to 1.8V, for example) refers to the MISC_LVR register.

Your argument with "MISC_LVR_DISABLE" confliction with "misc_lvr" register name was a good one.

I changed "_misc_lvr" to "_misclvr" and all its defines to "MISCLVR_...".

I also added defines in capital letters for all registers so Visual Studio Code can syntax highlight them (as suggested by @tim_). So for example the "_misc_lvr" register can be accessed by "MISCLVR" now, like: MISCLVR = MISCLVR_3V | MISCLVR_BANDGAP_AUTO;

(In development branch of programmer software, examples folder: https://github.com/free-pdk/easy-pdk-programmer-software/tree/development/Examples/src)

JS

[itelite]

I can read successfully and it has been written.  not sure how to compare it to input, since input is a IHX file, readout seems to do a HEX file or a BIN file.

no blank check yields a successful write and failed verify. Even running several times.

What is the hello world supposed to do? That is to say, how can i test that it is functioning? i assume a hello world over serial, but this does not happen.

Wirelength is about 10CM.  Anyway to slow down programming, in case wire length is an issue? it could be 100X slower and that would be just fine with me.

[spth]

I can read successfully and it has been written.  not sure how to compare it to input, since input is a IHX file, readout seems to do a HEX file or a BIN file.

.ihx and .hex are both file endings for Intel Hex. objcopy can be used to convert between Intel Hex and raw binary.