EEVblog #1144 - Padauk Programmer Reverse Engineering

[spth]

If you follow the link / instructions from the example directory I mentioned earlier... https://github.com/free-pdk/easy-pdk-programmer-software/tree/master/Examples/src
you will find a download link for current SDCC snapshots (nightly builds) for several platforms: http://sdcc.sourceforge.net/snap.php
I just checked again and 13 bit support is included.

Okay, I did what you said, but I still did not get it completly (sorry for that). I downloaded and installed the sdcc exe. During the installation prozess the applied libs are viewed. So I downloaded additionally the .zip file and unzipped it. In this unziped directory I found in the lib folder the pdk13 folder and copied it into the lib folder of the installed exe.
Now I tried compieling the code examples. At first helloword example from the software branch and later the examples from the sdcc example branch. Non of them worked. In the helloworld from the software branch I later defined additionally the the used uC. At first I tried compiling withe the "make" command in diffent variations like explained in the software/examples/src branch but I did not get a response at all. Next I tried compiling with "sdcc helloworld.c" . With this it started compiling but I got warning 182 for the "pfs154.h" "absolute address for sfr '...' probably out of range". Futhermore I got errors for helloworld.asm. Ten times I got ".org in REL area or directive / mnemonic error" and at last "missing or improper operator, terminators, or delimiters". After that helloworld.rel was removed. (I added a screenshot of the cmd window)

It would be great if you can tell me what I am doing wrong all the time and thank you very much for your comments in the past.

I checked, and there indeed was a problem with the pdk13 library missing in the Windows installer. If I didn't make a mistake it should be fixed now, and tomorrow's installers should install the pdk13.lib correctly (but I am not familiar with Windows, and might have made a mistake).

Do you have "make" installed? AFAIK it is not included in Windows.

"sdcc helloworld.c" would try to compile for the default mcs51 target, MCS-51 (i.e. Intel 8051 and compatible). For Padauk, you need to specify the target, i.e. using the option -mpdk13, -mpdk14 or -mpdk15.

[daveatol]

Hi. I just had a look at the schematic.

Why is the supply switched to the boost converter, rather than using the 'Enable' pin of the converter? The extra 4u7 on the +5V rail is within USB spec's <10uF total rail capacitance.

Why is the negative charge pump required for the opamp? The AS358 input and output ranges include 0V. Was it added because the AS358 sink current drops off below 1V? I get the feeling that it shouldn't be an issue.

EDIT: also, I think the filter on the AS358A positive supply can be removed, as its PSRR is 100dB.

Cheers,

[js_12345678_55AA]

Hi. I just had a look at the schematic.
Why is the supply switched to the boost converter, rather than using the 'Enable' pin of the converter? The extra 4u7 on the +5V rail is within USB spec's <10uF total rail capacitance.

It's for protection. The enable signal of the boost converter does not enable / disable the output. It is enabling / disabling the boost. So at startup, even without the enable signal present, you get +5V out of it.
The output of the boost converter directly feeds the opamp.
But at startup DAC output of the STM32 and the negative voltage reference of the opamp is undefined which would let the output of the boost converter slip through to the pins of a potential connected target IC.

To completely eliminate unpredictable voltage spikes at startup I decided to turn off the complete supply to the boost converter.
At startup, first DAC output and OPAMP negative reference is initialized and later on demand boost converter voltage rail is turned on.

Why is the negative charge pump required for the opamp? The AS358 input and output ranges include 0V. Was it added because the AS358 sink current drops off below 1V? I get the feeling that it shouldn't be an issue.

To save cost. I wanted to use a cheap opamp (rail to rail opamps are much more expensive) and we really need 0V. With a non rail to rail opamp like the AS358 it is impossible to get 0V output with a 0V negative reference.
That's why the variant with the 2 diodes + PWM to generate a negative voltage for the opamp negative reference was chosen.

Have fun,

JS

[daveatol]

Thanks for the reply. 

It's for protection. The enable signal of the boost converter does not enable / disable the output. It is enabling / disabling the boost. So at startup, even without the enable signal present, you get +5V out of it.
The output of the boost converter directly feeds the opamp.
But at startup DAC output of the STM32 and the negative voltage reference of the opamp is undefined which would let the output of the boost converter slip through to the pins of a potential connected target IC.

The DAC pins are pulled low through 240k resistors, so on startup, the voltage is 0V. If the charge pump was removed, the negative voltage would always be stable.

To save cost. I wanted to use a cheap opamp (rail to rail opamps are much more expensive) and we really need 0V. With a non rail to rail opamp like the AS358 it is impossible to get 0V output with a 0V negative reference.

The AS358 has an output range of 0V to 13.5V, with a 15V supply voltage. The input voltage range also includes 0V. The only thing to note with the output voltage under 1V is that the current that the output can sink reduces rapidly.

I think you could remove 10 components and have it still function happily.

Cheers,

[js_12345678_55AA]

Thanks for the reply. 

It's for protection. The enable signal of the boost converter does not enable / disable the output. It is enabling / disabling the boost. So at startup, even without the enable signal present, you get +5V out of it.
The output of the boost converter directly feeds the opamp.
But at startup DAC output of the STM32 and the negative voltage reference of the opamp is undefined which would let the output of the boost converter slip through to the pins of a potential connected target IC.

The DAC pins are pulled low through 240k resistors, so on startup, the voltage is 0V. If the charge pump was removed, the negative voltage would always be stable.

Unfortunately not.... When you enable the DAC on STM32 the output is 100%. After initialization you can setup 0 value. So for a short moment DAC output is 100% during initialization.

To save cost. I wanted to use a cheap opamp (rail to rail opamps are much more expensive) and we really need 0V. With a non rail to rail opamp like the AS358 it is impossible to get 0V output with a 0V negative reference.

The AS358 has an output range of 0V to 13.5V, with a 15V supply voltage. The input voltage range also includes 0V. The only thing to note with the output voltage under 1V is that the current that the output can sink reduces rapidly.

I tried without the negative reference and could not program the ICs. I think the 2 extra diodes are ok... If I rememebr correctly I was never able to get 0V from opamp output with VIN- tied to GND. Have you tested / measured the result with AS358 and VIN- 0V?

I think you could remove 10 components and have it still function happily.
Cheers,

There are other places where you can remove a lot more components. E.g. the ADC feedback is not required for normal programing, the programmer would work without LEDs, the button is not required, some of the capacitors might be unnecessary, ... But all of them make things easier for debugging, and might come handy in future (stand alone programmer).


Have fun,

JS

[daveatol]

It sounds like you've already tested everything I've mentioned. I am surprised, though.
No, I haven't used AS358, but I have used LM358. I'll measure the output of the LM358 when I can find where I've put them.

Cheers,

[js_12345678_55AA]

It would be great if you can tell me what I am doing wrong all the time and thank you very much for your comments in the past.

Hi,

from your comments I see that you are not familiar with compiling from command line. Looks like you don't have a "make" program and you don't know about include / lib path traversal.

I created a step by step "walk through" how to install, setup, compile, write and test the Helloworld program on a regular Windows PC without any prerequisites:

Start CMD and create folder:

C:\>mkdir C:\freepdk

C:\>cd C:\freepdk

C:\freepdk>

Use a Browser to download files and unpack them:

Browser->Open: http://sdcc.sourceforge.net/snap.php
Download: "sdcc-snapshot-i586-mingw32msvc-20191102-11444.zip"  (or latest, NOT THE SETUP)

Extract "sdcc-snapshot-i586-mingw32msvc-....ZIP" to "C:\freepdk"
=> Verify that you have "C:\freepdk\sdcc\bin\sdcc.exe" and "C:\freepdk\sdcc\lib\pdk13\pdk13.lib"

Browser->Open: https://github.com/free-pdk/easy-pdk-programmer-software/releases
Download: "EASYPDKPROG_WIN_20190907_1.1.zip" (or latest)

Extract "EASYPDKPROG_WIN_....zip" to "C:\freepdk"
=> Verify that you have "C:\freepdk\EASYPDKPROG\easypdkprog.exe"


Now continue in CMD:

Compile the sources:
C:\freepdk>cd C:\freepdk\EASYPDKPROG\Examples\src

C:\freepdk\EASYPDKPROG\Examples\src>mkdir build

C:\freepdk\EASYPDKPROG\Examples\src>..\..\..\sdcc\bin\sdcc.exe -DPMS150C -mpdk13 -o build\helloworld_pms150c.ihx helloworld.c

C:\freepdk\EASYPDKPROG\Examples\src>..\..\..\sdcc\bin\sdcc.exe -DPFS154 -mpdk14 -o build\helloworld_pfs154.ihx helloworld.c

C:\freepdk\EASYPDKPROG\Examples\src>..\..\..\sdcc\bin\sdcc.exe -DPFS173 -mpdk15 -o build\helloworld_pfs173.ihx helloworld.c
=> Now you can find the compiled hex files (*.ihx) in folder "C:\freepdk\EASYPDKPROG\Examples\src\build"

Example: Connect programmer with a PFS154 on top.

Check for programmer and PFS154:
C:\freepdk\EASYPDKPROG\Examples\src>..\..\easypdkprog.exe probe
Probing IC... found.
TYPE:FLASH RSP:0xAA1 VPP=4.50 VDD=2.00
IC is supported: PFS154 ICID:0xAA1

Write PFS154:
C:\freepdk\EASYPDKPROG\Examples\src>..\..\easypdkprog.exe write build\helloworld_pfs154.ihx -nPFS154
Erasing IC... done.
Writing IC... done.
Calibrating IC (@4.00V IHRC SYSCLK=8000000Hz)... calibration result: 7991184Hz (0x81)  done.

Run PFS154:
C:\freepdk\EASYPDKPROG\Examples\src>..\..\easypdkprog.exe start --runvdd=4.0
Running IC (4.00V)... IC started, press [Esc] to stop.
Hello World!
Hello World!
Hello World!

IC stopped


Have fun,

JS

P.S. make sure that you really type in the complete bold text with all the dots and backslashes like ..\..\..\

[daveatol]

If I rememebr correctly I was never able to get 0V from opamp output with VIN- tied to GND. Have you tested / measured the result with AS358 and VIN- 0V?

I just connected an LM358 as a unity-gain buffer, on a 12V supply, which gave ~6mV output for 0V input, and 10.76V for 12V input.

The TI LM358 and the DI AS358 datasheets have the same simplified schematics (transistors and current sources), and I suspect that they're effectively the same device.
Cheers,

[js_12345678_55AA]

If I rememebr correctly I was never able to get 0V from opamp output with VIN- tied to GND. Have you tested / measured the result with AS358 and VIN- 0V?

I just connected an LM358 as a unity-gain buffer, on a 12V supply, which gave ~6mV output for 0V input, and 10.76V for 12V input.

The TI LM358 and the DI AS358 datasheets have the same simplified schematics (transistors and current sources), and I suspect that they're effectively the same device.
Cheers,

Yes, 6mV at 0V input. But the DAC of the STM32 has a 35mV DC offset and then the output was to high (not 0 enough anymore).

JS

[KaeTo]

Hi,

thank you very, very much js_12345678_55AA. I think it would be great, if you add your walk trough to the github readme. I finally got it to work. Because I thought the operation through the command window is a bit annoying, I wrote a little GUI for easier operation.
With it you can compile your c Files and probe/erase/flash the microcontroller. Therefor you can selct your uC via a drop down list. At the time I have insertet the PMS150C, PFS154 and PFS174. If you want I could share the software on github. If so should I put into the easy-pdk-programmer-software branch?

Another big thank you for your great support

[icraftcrafts]

Hi everyone. Thanks all for your great work on this project.

I built the programmer and need some help getting my programmer working please. The firmware to stm32 flashed correctly. I have a few PMS150c 8 pins I can use and have it connected.  When i use easypdkprog I get the message "No programmer found".

What I'd like to know is, is there any component I may have botched? When do the LEDs light up? Are there testpoints I can check for certain voltages to know if i damaged something? I did handsolder and the stm32 suffered the most with my "skills" but it seems to be ok.

Any assistance in the right direction is appreciated.

ADDED: I'm using ubuntu 18.04

[js_12345678_55AA]

The firmware to stm32 flashed correctly. I have a few PMS150c 8 pins I can use and have it connected.  When i use easypdkprog I get the message "No programmer found".

How did you flash the firmware? With DFU tool over USB from your Ubuntu installation?
If so please provide the output to make sure the complete firmware was written correctly (incorrect / not written firmware will give you the "no programmer found" message later)
Output should look like this:

dfu-util 0.9
   ...
   Opening DFU capable USB device...
   ID 0483:df11
   Run-time device DFU version 011a
   Claiming USB DFU Interface...
   Setting Alternate Setting #0 ...
   Determining device status: state = dfuIDLE, status = 0
   dfuIDLE, continuing
   DFU mode device DFU version 011a
   Device returned transfer size 2048
   DfuSe interface name: "Internal Flash  "
   Downloading to address = 0x08000000, size = 27635
   Download  [=========================] 100%        27635 bytes
   Download done.
   File downloaded successfully

=> Do not forget to unplug / replug the programmer from USB after firmware update, otherwise it can not be recognized.

After checking firmware was flashed correctly, USB is confirmed working already :-)

Now connect the programmer and run "dmesg" (without the quotes) in terminal and provide output (only last 10 lines are interesting). It should look like this:
...
[  955.834095] usb 2-2.1: new full-speed USB device number 6 using uhci_hcd
[  956.066910] usb 2-2.1: New USB device found, idVendor=0483, idProduct=5740
[  956.066913] usb 2-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  956.066915] usb 2-2.1: Product: Easy PDK Programmer
[  956.066917] usb 2-2.1: Manufacturer: free-pdk.github.io
[  956.066918] usb 2-2.1: SerialNumber: 1234567855AA
[  956.106462] cdc_acm 2-2.1:1.0: ttyACM0: USB ACM device

You also can run "lsusb" (without the quotes) in terminal and provide the output. It should look like this:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0483:5740 STMicroelectronics STM32...
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Next:
unplug the programmer and run "ls /dev/ttyACM*" (without the quotes). Output should be empty or show other serial ports attached to your system

connect programmer and run again "ls /dev/ttyACM*" (without the quotes). Output should show the serial port of programmer (any maybe other serial ports attached to your system):
/dev/ttyACM0

What I'd like to know is, is there any component I may have botched? When do the LEDs light up? Are there testpoints I can check for certain voltages to know if i damaged something? I did handsolder and the stm32 suffered the most with my "skills" but it seems to be ok.

The LEDs light up when easypdkprog is connected to the programmer and is doing some work. Just connecting the device to USB will not light the LEDs.
The schematic and PCB layout show the various voltage rails. But since you said you could write the firmware, you most likely do not have a short circuit / damaged component problem.

Can you take a good resolution picture of your PCB and attach it here? Maybe something can be spotted from the picture.

Have fun,

JS

[icraftcrafts]

Thanks for your reply JS. Here's a screenshot of the dfu-util output. dmesg -c before and after replugging (after flash) is blank. dmesg when putting stm in bootloader mode shows the correct stm output. no lsusb changes after flash. also my byte size is different from your screen output.

[ADDED] i will try to post a high res pic this eve.

[icraftcrafts]

shucks i actually see that dfu error only now   

[js_12345678_55AA]

shucks i actually see that dfu error only now   

Hi,

i see some other things from DFU output:

1) a warning that your DFU file is not having a valid DFU suffix
2) your DFU file size (83kB) is much bigger than the current release firmware (28kB)

=> most likely you flashed the wrong file. Maybe you downloaded a HTML web site from github (this sometimes happens when you right-click in source view on a file and download it... this will download the following HTML page instead of the file).

A pre compiled DFU file is included in the RELEASE of the easypdk programmer software: https://github.com/free-pdk/easy-pdk-programmer-software/releases  - for your system: "EASYPDKPROG_LINUX_20190907_1.1.zip"


Have fun,

JS

[icraftcrafts]

You are correct about incorrect file JS.It has html content. I've found the correct one in the firmware directory 

but success after a two day smd job. Im glad its working as im too embarassed to send a high res photo lol. heres the correct dmesg output below. I will get into trying the otp pms150c 8 pin as i have about 300 of them. i hope i can be of some assistance later on in this project. Thanks again JS

[icraftcrafts]

Im getting the below error when trying to flash the example code to the pms. led closest to side is blinking now  .

I think i saw somewhere in one of the posts you mentioned something about cabling being too long. Im currently using 200mm dupont cables but will swap them later.

 

[icraftcrafts]

Successful write and read. What i did was grab the bundle of wires together to sort of see if it creates a kind of shield or cancellation with ground or each other. Then i could manage to read it repeatedly with 200mm dupont wires. And the write was successful as can be seen in the output. Now i'd like to know if there's any way I can assist?

Regards.

[soFPG]

Is there any reverse engineering regarding the ICE (In-Circuit-Emulator) going on (didn't read the whole 32 pages)?

If not, I attached a picture of the top side of the PCB - in case anyone is interested (attention: huge image).

Couldn't find any information about the SGD0235R3 IC in the center (which is upside-down at the moment because the top side doesn't have any text on it) - my guess is it is an FPGA.

[soFPG]

and the backside.

[I wanted a rude username]

Is there any reverse engineering regarding the ICE (In-Circuit-Emulator) going on (didn't read the whole 32 pages)?

I got my ICE today as well. Here is a high resolution image:

The FPGA has no markings. It might be possible to capture the JTAG init sequence, if it doesn't store the configuration data inside the FPGA, because looks like there is no external configuration flash memory.

The USB device is a CY7C68013A, with high speed USB (480 Mbps) and an integrated 8051 CPU, that can be booted through USB (there is an interesting project, which implements a communication through such a Cypress chip to a FPGA over USB, FPGALink). So this could be a very flexible construction, booting first the firmware of the 8051, then booting the FPGA bitstream, all over USB. But I think it might be easier to develop a new emulator than trying to reverse engineer this. Would be nearly impossible to decode the FPGA bitstream back to the HDL code.

"usb-devices" shows the same as js_12345678_55AA wrote:

Code: [Select]

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=03 Dev#=  9 Spd=480 MxCh= 0                                                                                                                                             
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1                                                                                                                                                 
P:  Vendor=0797 ProdID=7002 Rev=80.01                                                                                                                                                                         
S:  Manufacturer=PADAUK                                                                                                                                                                                       
S:  Product=LGS_DEV FX2-HID 0.01                                                                                                                                                                             
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=500mA                                                                                                                                                                       
I:  If#= 0 Alt= 0 #EPs= 2 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid   


(Emphasis added)

[ali_asadzadeh]

JS I'm playing with your serialecho example, and modified it! I think the getchar is not working

here is the modified code , in the attached form

Please see the attached picture, it does not get anything and would stuck in the getchar in a loop, I have entered "w" and "q" in the terminal, and obviously it does not get anything from RX

Also Do you have some ADC examples?

I have written a simple makefile too, by juts running make run command, compilation, programming and running the device is done

Code: [Select]

# SDCC=../../sdcc/bin/sdcc
# Add enviroment path for SDCC to windows path
SDCC = sdcc.exe
OUTDIR=build

all: PFS173


PFS173:
mkdir -p $(OUTDIR)
$(SDCC) -DPFS173 -mpdk15 -o $(OUTDIR)/main.ihx main.c


clean:
rm -rf $(OUTDIR)

# Place easypdkprog.exe file inside the source folder of your .c file
prog:
easypdkprog write build\main.ihx -nPFS173

start:
@echo "Starting the Device"
easypdkprog start --runvdd=4.0

run: PFS173 prog start
.PHONY: all clean



[js_12345678_55AA]

JS I'm playing with your serialecho example, and modified it! I think the getchar is not working

Hi, I had a similar problem a few days ago with PFS173. Turns out PFS173 explicitly needs to setup digital inputs in the PxDIER (digital input enable register).
On PFS154 and PMS150C this is not needed.

So all you need to add is one line after setting up PAC:

  PADIER = 0x01;                                 //select PA.0 as digital input (required for PFS173)

The development branch has an updated example.
 
==> IMPORTANT FOR ALL:  PFS173 needs setup of PxDIER in case you want to use a digital input pin. PFS154/PMS150C do not need this but it will not harm to set it up as well <==

Also Do you have some ADC examples?

Not yet, but I work on something which needs the ADC.

Meanwhile have a look at CPLDCPUs git repo: https://github.com/cpldcpu/SimPad/blob/master/Toolchain/examples/ADC_PFS173/adc.c

JS

[ali_asadzadeh]

Thanks JS, you are a hero

Also Please try to add the industrial grad parts support too. I mean the PMC series, with a Operating temperature range: -40°C ~ 85°C.
Personally I like the ones with integrated ADC like the PMC271,PMC131,PMC232,PMC234 parts, As they can be used in the Industrial field and they can be very useful,replacing many parts

[ali_asadzadeh]

JS, your example baud rate is completely wrong! I have connected the PFS173 to an external FTDI to USB chip to test it.

I should make the baudrate 28800 to be able to get the messages write! Also I think the RXD is working some how, It just get the first char correctly, but the subsequent ones are missed. see the attached picture.