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

Anthocyanina, darkspr1te and 2 Guests are viewing this topic.

Offline jjflash

  • Newbie
  • Posts: 1
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1250 on: December 21, 2020, 05:55:48 pm »
Hello everyone,

I'm new here and in the first please excuse my extremly bad english. I'm a native speaken german. (Hi Tim, I see  :) you're staying here more often as in mikrocontroller.net).

So, why I'm writing the first post ever EEVblog has a simple reason (okay perhaps more reasons): At the first, thanks a lot to all the people who made it possible to handle with the ultra low cost Padauk controllers. I've build a Easy-PDK-Programmer :-) on breadboard and it works great, but due to the facts that a.) the used controller is currently rare and as a consequence of this, he is expensive.

The next thing ist, hobbiest aren't able to build a programmer what is a little bit pitty. So I thought an ATMega can do the job and I thought a lots of people have done such a thing, but terrifyingly I only found to projects to build a programmer that isn't based of the EASY-PDK. One is from socram8888 and I didn't get him to work. Voltage supply is the greatest problem, and the second project is from tim__ , sometimes it does the job and mor sometimes not.

So began to design an own ATmega based programmer for Padauk and I have done something like the Easy-Programmer with the voltages: An (old) switching regulator MC34063 works as a step-up converter und like Easy-Programmer I'll have an OP-Amp LM356 to generate the V_pp and V_dd. So, at the moment I can reliable flash a PFS154 Chip, but I can ONLY flash this type.

But... I want to flash a PFS173 too, and the second challenge begin. At the moment I can do :

- reading the device-ID (0EA2)
- erasing the device
- reading a word from the flash

But I cant write anything. After a write access not only one bit is writen. So I know, something with the protocol went wrong or something with the voltages (I use 8V for writing, 9V for erasing), or both went wrong.

So I'm slowly running out of ideas.

Has anywhere a documentation and / or oscillographs from the programming algorithm for PFS173 (like the analysis document on Tim's github https://github.com/cpldcpu/SimPad/blob/master/Protocol/PDKprogrammingsequence20v0.5.pdf )

-------------------------------------

So thanks a lot for reading ... and excuse the horrible english.

JJ / Ralph S.

Perhaps you want to have a look at my github ?

https://github.com/jjflash65/Padauk-pfs154
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1251 on: December 23, 2020, 05:57:02 pm »
Hi jjflash,

as far as I remember the PFS173 uses the exact same protocol as the PFS154.

You can see the differences in "fpdkicdata.c" from the programmer software source code : https://github.com/free-pdk/easy-pdk-programmer-software/blob/master/fpdkicdata.c

I marked the differences (parameters and voltages) for you below:

  { .name                         = "PFS154",
    .otpid                        = 0x2AA1,
    .id12bit                      = 0xAA1,
    .type                         = FPDK_IC_FLASH_1,
    .addressbits                  = 13,
    .codebits                     = 14,
    .codewords                    = 0x800,
    .ramsize                      = 0x80,
    .exclude_code_start           = 0x7E0,  //OTP area 16 words, contains empty space for user and BGTR IHRCR factory values
    .exclude_code_end             = 0x7F0,
    .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.8,
    .vpp_write_hv                 = 8.5,
    .write_block_size             = 4,
    .write_block_clock_groups     = 1,
    .write_block_clocks_per_group = 8,
    .vdd_cmd_erase                = 2.5,
    .vpp_cmd_erase                = 5.5,
    .vdd_erase_hv                 = 3.0,
    .vpp_erase_hv                 = 9.0,
    .erase_clocks                 = 2
  },

  { .name                         = "PFS173",
    .otpid                        = 0x2AA2,
    .id12bit                      = 0xEA2,
    .type                         = FPDK_IC_FLASH_1,
    .addressbits                  = 13,
    .codebits                     = 15,
    .codewords                    = 0xC00,
    .ramsize                      = 0x100,
    .exclude_code_start           = 0xBE0, //OTP area 16 words, contains empty space for user and BGTR IHRCR factory values
    .exclude_code_end             = 0xBF0,
    .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                = 6.5,
    .vdd_write_hv                 = 5.8,
    .vpp_write_hv                 = 9.0,
    .write_block_size             = 4,
    .write_block_clock_groups     = 1,
    .write_block_clocks_per_group = 8,
    .vdd_cmd_erase                = 2.5,
    .vpp_cmd_erase                = 5.5,
    .vdd_erase_hv                 = 3.0,
    .vpp_erase_hv                 = 9.0,
    .erase_clocks                 = 4
  },


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

Offline KaeTo

  • Contributor
  • Posts: 27
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1252 on: December 24, 2020, 09:07:58 am »
Hello,

first I want to thank you for the great work you did with the easy-pdk-programmer.

I build one myself month ago and did not have a problem so far. This week I updated the fireware from v1.1 to v1.3. At first it worked a bit, which means that erverything worked, but there was a noticeable delay from sending the probing/ereasing/writing command. Since the last days it does not work anymore. If I write the command nothing happens. The programmer is recognized under my Win7 PC as "STMicroelectronis Virtual COM Port"  in the device manager. It is also possible to flash an other firmware (I tried v1.1 with the relaiting exe, but that also did not work anymore). Could you please help me and tell me what I can try to get the programmer working again?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1253 on: December 24, 2020, 09:44:52 am »
Hi KaeTo,

First thing to do: Run the programming in verbose mode (add the -v option to command line) and let us have a look at the output.

Next thing to try, compile "easypdkprogtest" from source (make easypdkprogtest).
Remove any attached IC from programmer and run easypdkprogtest. You should see an output like this one: "Vdd: 4.96   vpp: 4.98    (vref= 3.28)".
At the same time measure VDD and VPP on programmer header.
Please share your results (output of easypdkprogtest and measured results).

Edit: Just to make sure it's not a Windows quirks... Go to device manager of windows, remove the STM32 windows virtual com port device / driver and reinstall it. Another guess... can it be that you installed some "libusb" driver / software which now interferes with the standard COM port? Maybe you installed something for the DFU firmware update? (a driver uninstall/reinstall of the STM32 virtual com port should fix this as well)?

JS
« Last Edit: December 24, 2020, 11:45:19 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline KaeTo

  • Contributor
  • Posts: 27
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1254 on: December 24, 2020, 12:47:43 pm »
I just tried it from another computer an the was no problem at all (with the same easypdkprog.exe). As soon as I am at home I will try it again. I think maybe the program is blocked (I used the exe from the releases and did not compile myself).

It seems like the programm had a problem with some of my other COM Ports (virtual bluetooth COM Ports), thats why it stuck at the search for the programmer
« Last Edit: January 01, 2021, 09:32:04 am by KaeTo »
 

Offline KaeTo

  • Contributor
  • Posts: 27
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1255 on: January 01, 2021, 09:42:46 am »
I habe another program,

I already build up one programmer and now build some more as a gift and as spare. So far the boards seem to work and I could flash them with the firmware. Tee problem I have with the new boards is, that if I connect them to the PC they always enter the mode to program them. I could not figure out why till now. I measured the connections and they seem to be okay. If I press the botton for the programming mode I get 3.3V on Pins Boot0 und PA15, but if I release the button I get 1.0V instead of 0V. So far I testet the pulldown resistor and it is connected correct and also switched the 20k to 10k without result (only the measured voltage droped a tiny bit). I could not figure out what I did wrong. I have to of this boards which show the same behavior. THe only difference to my first and working pdk programmer ist the supplier of the chips. The first came from lcsc but the chips from the other boards came frome a seller from ebay, because I could not find the chip from any distributor (lcsc, mouser, digikey, ...). Could it be that I have got fake chips (but if thats the case it is strange that I could program them without a problem).
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1256 on: January 01, 2021, 11:55:45 am »
I just tried it from another computer an the was no problem at all (with the same easypdkprog.exe). As soon as I am at home I will try it again. I think maybe the program is blocked (I used the exe from the releases and did not compile myself).

It seems like the programm had a problem with some of my other COM Ports (virtual bluetooth COM Ports), thats why it stuck at the search for the programmer

Thanks for the info. In this case you also can specify the port directly on the command line (no autodetect).

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 #1257 on: January 01, 2021, 12:00:44 pm »
I habe another program,

I already build up one programmer and now build some more as a gift and as spare. So far the boards seem to work and I could flash them with the firmware. Tee problem I have with the new boards is, that if I connect them to the PC they always enter the mode to program them. I could not figure out why till now. I measured the connections and they seem to be okay. If I press the botton for the programming mode I get 3.3V on Pins Boot0 und PA15, but if I release the button I get 1.0V instead of 0V. So far I testet the pulldown resistor and it is connected correct and also switched the 20k to 10k without result (only the measured voltage droped a tiny bit). I could not figure out what I did wrong. I have to of this boards which show the same behavior. THe only difference to my first and working pdk programmer ist the supplier of the chips. The first came from lcsc but the chips from the other boards came frome a seller from ebay, because I could not find the chip from any distributor (lcsc, mouser, digikey, ...). Could it be that I have got fake chips (but if thats the case it is strange that I could program them without a problem).

Are you really sure you program the correct firmware? (sometimes people try to download files from github with "Save as..." and do not recognize that in fact a HTML is saved instead of the requested file.)

The output of DFU utility when you do the flashing will be helpful to investigate further.

Regarding the measured 1V at Boot 0 pin... In case you did not flash a valid firmware, the STM32 has detections for this to automatically enter bootloader (e.g. on complete blank chip or if the reset vector points to nirvana). After entering bootloader the processor is executing it's code which might cause some state of the BOOT 0 pin where in fact a pull up or output is coming from STM32.

JS
« Last Edit: January 01, 2021, 04:58:39 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline KaeTo

  • Contributor
  • Posts: 27
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1258 on: January 01, 2021, 06:05:12 pm »
Yes I checked that thr flashing ist corect. I flashed the same firmware for both (my first and the new programmers). The firmware ist flashed and the progress bar reaches by all programmers the 100% and fineshes flashing.
What can I try next?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1259 on: January 02, 2021, 10:33:54 am »
Yes I checked that thr flashing ist corect. I flashed the same firmware for both (my first and the new programmers). The firmware ist flashed and the progress bar reaches by all programmers the 100% and fineshes flashing.
What can I try next?

Can you provide the output of DFU util so we can have a look?

By any chance, do you have a STLinkV2 *or* a FTDI USB UART adapter?
With STLink V2 you can connect to SWD pins (4 pins on bottom of board next to the "freepdk" text) and read out to vertify the IC and/or flash the firmware directly with a special ST tool (STLink Tool)
Same can be done with a FTDI USB UART adapter and another special ST tool (Flash Loader Demonstrator).

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

Offline KaeTo

  • Contributor
  • Posts: 27
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1260 on: January 02, 2021, 04:32:17 pm »

Can you provide the output of DFU util so we can have a look?


I attached a screenshot of the flashing in normal mode and a textfile with the output of the flashing in verbose mode.

I have a FTDI USB UART adapter. I tried the Flash Loader Demonstrator but I did not get it to work. How is the pinout on the programmer board? I checked the datasheet and the the schematic, but I only got GND,??, TX_UART2_STM32, VCC. ?? ist PINPA13 and has no UART function (only I/O and IR_OUT, SWDIO,USB_NOE) according to the datasheet.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1261 on: January 02, 2021, 10:56:46 pm »
Your DFU flashing looks 100% correct.

Time to investigate what was actually written to IC.

EDIT: I just remembered that you can read back the IC with dfu-util.
Execute the following command
dfu-util -d 0483:df11 -a "@Internal Flash  /0x08000000/064*0002Kg" --dfuse-address 0x08000000 -U readout.bin
...
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 = dfuERROR, status = 10
dfuERROR, clearing status
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  "
Limiting upload to end of memory segment, 131072 bytes
Upload   [=========================] 100%       131072 bytes
Upload done.

And then compare the readout.bin file with the firmware.dfu file (they should be identical at the beginning). You also might ZIP and attach the readout.bin to your next post.

Will be interesting to hear your results, especially if the READ contains the flashed DFU or not (in case you only can read 0xFF and also 5.) does not change the situation it means the STM32 do have a bad flash - most likely by overheating them when soldering / unsoldering them in case they are used).

JS


BTW: LCSC has STM32F072 in stock again... the price is a bit crazy but it is available again.
« Last Edit: January 02, 2021, 11:23:41 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline KaeTo

  • Contributor
  • Posts: 27
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1262 on: January 03, 2021, 09:22:49 am »
Readout of the the programmer worked with dfu-util. I compared the working programmer, the two not working and the firmware file.
The file from the working programmer and the firmware were the same. The file from the two not working programmers had some clear text errors like "Flash WRP is not setting...", "Flash WRP setting error!", "Checksum FAIL!!", ...
Readout files 2 and 3 are frome the "defect" programmers, file 1 from the working.

Thank you for the hint with the to high temperature. The were new but at first I soldered them the wrong way and had to desolder them (280°C for a few minutes) to turn them the right way.

Could you tell me from the readout, if the flash is really bad and if I have to switch the uC?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1263 on: January 03, 2021, 12:27:33 pm »
Readout of the the programmer worked with dfu-util. I compared the working programmer, the two not working and the firmware file.
The file from the working programmer and the firmware were the same. The file from the two not working programmers had some clear text errors like "Flash WRP is not setting...", "Flash WRP setting error!", "Checksum FAIL!!", ...
Readout files 2 and 3 are frome the "defect" programmers, file 1 from the working.

Thank you for the hint with the to high temperature. The were new but at first I soldered them the wrong way and had to desolder them (280°C for a few minutes) to turn them the right way.

Could you tell me from the readout, if the flash is really bad and if I have to switch the uC?

Hi,

Now we getting somewhere... The readout2 and readout3 show a complete different firmware. It looks like a Arduino / Bluepill / ... bootloader.

Most likely flash WRITE-PROTECTION has been set so this existing bootloader can not been overwritten by accident.

==> In order to write a new firmware to this used and locked ICs you have to clear the write protection.

I don't know how this is possible with DFU but I know for sure it is possible via UART bootloader.

For uart bootloader you need your FTDI adapter and connect:

FTDI_TX  ==> STM32_UART2_RX ==> PA13 ==> (solder wire to right side of push button)
FTDI_RX  ==> STM32_UART2_TX ==> PA14 ==> SWCLK
FTDI_GND ==> GND

The tool from ST can be found here:
https://www.st.com/en/development-tools/flasher-stm32.html

Start the ST Flash Loader Demonstrator, select the COM port from your connected FTDI adapter, click Next and if all goes well the STM32F072 is detected.
In case you can not detect the IC make sure, use a power bank or your phone charger and plug it into USB port of easy pdk programmer while holding the button.
(This prevents STM32 ROM bootloader to enter USB DFU which it would do in case USB activity is detected, instead it wait for UART connect which you will do with the ST tool).
Also you might need to exchange RX and TX (not sure how your FTDI adapter is labeled).

When STM32F072 was detected properly you can select a firmware to flash (you can use the DFU file directly - even that it asks you for bin file). When you try to flash it the ST tool will tell you that it needs to remove the WRITE PROTECTION, click on "yes" and this should do the trick.

==> This will finally reset your used STM32 to factory defaults and flash the new firmware. Since easypdk programmer firmware does not lock flash you can use DFU util to flash firmware updates later just like on a factory fresh IC.

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

Offline KaeTo

  • Contributor
  • Posts: 27
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1264 on: January 03, 2021, 01:15:58 pm »

Start the ST Flash Loader Demonstrator, select the COM port from your connected FTDI adapter, click Next and if all goes well the STM32F072 is detected.
In case you can not detect the IC make sure, use a power bank or your phone charger and plug it into USB port of easy pdk programmer while holding the button.
(This prevents STM32 ROM bootloader to enter USB DFU which it would do in case USB activity is detected, instead it wait for UART connect which you will do with the ST tool).
Also you might need to exchange RX and TX (not sure how your FTDI adapter is labeled).

When STM32F072 was detected properly you can select a firmware to flash (you can use the DFU file directly - even that it asks you for bin file). When you try to flash it the ST tool will tell you that it needs to remove the WRITE PROTECTION, click on "yes" and this should do the trick.


I tried it with both not working programmer, but none of them was detected. I made sure the PINs are connected correctly and the power came from a phone charger. I also pressed the button while connection to power. The ST Flash Tool always ran in a timeout.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1265 on: January 03, 2021, 08:25:37 pm »

Start the ST Flash Loader Demonstrator, select the COM port from your connected FTDI adapter, click Next and if all goes well the STM32F072 is detected.
In case you can not detect the IC make sure, use a power bank or your phone charger and plug it into USB port of easy pdk programmer while holding the button.
(This prevents STM32 ROM bootloader to enter USB DFU which it would do in case USB activity is detected, instead it wait for UART connect which you will do with the ST tool).
Also you might need to exchange RX and TX (not sure how your FTDI adapter is labeled).

When STM32F072 was detected properly you can select a firmware to flash (you can use the DFU file directly - even that it asks you for bin file). When you try to flash it the ST tool will tell you that it needs to remove the WRITE PROTECTION, click on "yes" and this should do the trick.


I tried it with both not working programmer, but none of them was detected. I made sure the PINs are connected correctly and the power came from a phone charger. I also pressed the button while connection to power. The ST Flash Tool always ran in a timeout.

Have you tried to swap RX / TX in case your FTDI adapter is labeled incorrectly?.

I just tried it myself and everything is working as expected.
I observed that I had to hold button, connect power and after this connect FTDI USB adapter to computer (otherwise TX line from FTDI was feeding some voltage to STM which was enough to start it...)

Attached some pictures / screen shots.

Don't get confused from the color of the wires in the picture: (WHITE = FTDI_RX , BLACK = FTDI_TX , BROWN = FTDI_GND)

JS

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

Offline pacmancoder

  • Newbie
  • Posts: 6
  • Country: ua
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1266 on: January 03, 2021, 08:57:32 pm »
Hello there! I have implemented a software UART generator with Web UI available!
It generates C transmit and receive functions with (I hope?) clock-precise inline assembly code. Maybe It will be useful for someone  :D

Take a look at the page on my website:
https://pacmancoder.xyz/freepdk-uart-gen/

CLI version is also available, but it should be compiled from sources manually as I didn't prepare the release executables yet.

The generator itself is open-sourced at https://github.com/pacmancoder/freepdk-gen , so if anyone wants to improve it / use it as a base for other generators - welcome to the project's GitHub repo! Web UI glue code is currently a part of my personal website, but it is also open-sourced at https://github.com/pacmancoder/pacmancoder.github.io too.
 

Offline KaeTo

  • Contributor
  • Posts: 27
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1267 on: January 13, 2021, 05:09:32 am »
When STM32F072 was detected properly you can select a firmware to flash (you can use the DFU file directly - even that it asks you for bin file). When you try to flash it the ST tool will tell you that it needs to remove the WRITE PROTECTION, click on "yes" and this should do the trick.

I finally got the programer running with the help of a friend. He had a STM programmer und with it it worked flawlessly. Now the programer behaves like expected.

Thank you for all your great help :)
 

Offline C. Tracy

  • Newbie
  • Posts: 2
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1268 on: January 18, 2021, 04:38:47 am »
Hello,
   1st of all, big thank you to everyone who worked on this incredible project.
   I have an issue, I have carefully assembled the Easy-pdk-programmer pcb 2 times (although I think I got PTSD from soldering it) and both times I get the same result; 9193-33 regulator (U2 on schematic) heats up rather quickly and PC does not recognize that a device has been plugged into USB. I can find no shorts or cold joints. Is it possible I cooked one of the components while soldering? I know this is super vague but any suggestions before I try to solder a 3rd board and ruin that one too would be great. Thanks.

*edit* I get less than 1 ohm of resistance across C5, C7, C8, C9, C12. That will mean that the Vout of the regulator is essentially shorted to ground (which explains why board doesn't start) but can't tell in-circuit what the issue is. seems like maybe I should try and re-solder the microcontroller because it has a bunch of pins where 3.3v and GND are adjacent, so most likely that is where the problem is?
« Last Edit: January 18, 2021, 06:10:09 am by C. Tracy »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1269 on: January 18, 2021, 07:27:32 am »
I may have found a strange bug (feature?) in the IO ports of the PFS154.

I used the following code to switch a PGIO between logical high ("Hi") and high impedance state ("Z").

Code: [Select]
PA |=1<<4:

PAC |=1<<4;   // HI

PAC &=~(1<<4); // Z

This works fine. But if another port is accessed in between, it appears that the state of PA is lost?


Code: [Select]
PA |=1<<4:

PA |=1<<3;  // turn on PA3

PAC |=1<<4;   // This will not activate the pin anymore!

PAC &=~(1<<4); // Z

Very odd. Has anybody seen similar?

 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1270 on: January 18, 2021, 07:43:23 am »
Below you can find a very efficient code to implement an ADC with the internal resistor ladder based on the SAR principle. Maybe it is uselful to some.

It works well with the LRC clock (53 kHz main clock). I don't know how fast the comparator actually is, it may be neccessary to introduce wait states when clocking the CPU at a much higher frequency.

Code: [Select]
GPCC = GPCC_COMP_ENABLE | GPCC_COMP_MINUS_BANDGAP_1V2; // Activate comparator. Negative input is bandgap, positive input is resistor ladder

// SAR ADC using the internal resistor ladder
__asm
mov a, #0x20  ; GPCS.4 = 0  GPCS.5 = 1

or      a, #0x08   ; Bit 3
mov     __gpcs,a
t0sn    __gpcc, #6
xor     a, #0x08

or      a, #0x04   ; Bit 2
mov     __gpcs,a
t0sn    __gpcc, #6
xor     a, #0x04

or      a, #0x02   ; Bit 1
mov     __gpcs,a
t0sn    __gpcc, #6
xor     a, #0x02

or      a, #0x01   ; Bit 0
mov     __gpcs,a
t0sn    __gpcc, #6
xor     a, #0x01

and     a,#15 // Result is now in A register.

set0    __gpcc,#7  ; turn comparator off
                ret
__endasm;

p.s.: Only 3 instructions per bit would be needed of the resistor ladder had a R/W register. But alas, it's WO.

 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1271 on: January 18, 2021, 07:50:33 am »
Hello,
   1st of all, big thank you to everyone who worked on this incredible project.
   I have an issue, I have carefully assembled the Easy-pdk-programmer pcb 2 times (although I think I got PTSD from soldering it) and both times I get the same result; 9193-33 regulator (U2 on schematic) heats up rather quickly and PC does not recognize that a device has been plugged into USB. I can find no shorts or cold joints. Is it possible I cooked one of the components while soldering? I know this is super vague but any suggestions before I try to solder a 3rd board and ruin that one too would be great. Thanks.

*edit* I get less than 1 ohm of resistance across C5, C7, C8, C9, C12. That will mean that the Vout of the regulator is essentially shorted to ground (which explains why board doesn't start) but can't tell in-circuit what the issue is. seems like maybe I should try and re-solder the microcontroller because it has a bunch of pins where 3.3v and GND are adjacent, so most likely that is where the problem is?

That sounds like a short indeed. Are you certain there are no solder bridges or similar? I guess you already started probing with your multimeter, that's definitely the way to go. DId you try to make some hi resolution photographs to check bad solder joints? May also help posting them here, becuase otherwise it's tough to tell what is wrong.

 

Offline C. Tracy

  • Newbie
  • Posts: 2
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1272 on: January 18, 2021, 01:58:47 pm »
Tim_, thank you for your response. There was indeed a solder bridge between pin 8 and 9 of the stm32.  Don't know how I didn't see it last night.  My eyes must have been fatigued as I don't have a magnifier.  I tried to take pictures but they've come out super grainy, apparently my light or camera (or both) isn't up to the task.  But now I get about 40K of resistance across the caps, and an actual 3.3v (well 3.28 on the meter) output when plugged in.  PC however still doesn't recognize that anything has been plugged in.  Button is working at least I can tell that much.  I'll take this to work tonight and use their magnifier to inspect the board.  Somehow I think I'm going to end up soldering a 3rd. Again thanks for the response.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1273 on: January 19, 2021, 03:23:05 pm »
I may have found a strange bug (feature?) in the IO ports of the PFS154.

I used the following code to switch a PGIO between logical high ("Hi") and high impedance state ("Z").

Code: [Select]
PA |=1<<4:
PAC |=1<<4;   // HI
PAC &=~(1<<4); // Z

This works fine. But if another port is accessed in between, it appears that the state of PA is lost?

Code: [Select]
PA |=1<<4:
PA |=1<<3;  // turn on PA3
PAC |=1<<4;   // This will not activate the pin anymore!
PAC &=~(1<<4); // Z

Very odd. Has anybody seen similar?

Hi,

I used your code, made a test program and compiled it to see the assembly output (in order to check if there is a compiler problem):

;   test.c: 14: PA |=1<<4;
   set1   __pa, #4
;   test.c: 16: PA |=1<<3;  // turn on PA3
   set1   __pa, #3
;   test.c: 18: PAC |=1<<4;   // This will not activate the pin anymore!
   set1   __pac, #4
;   test.c: 20: PAC &=~(1<<4); // Z
   set0   __pac, #4


Output looks 100% correct so not a compiler problem.

Next I wanted to check what you see and what to expect and I think I know what happens:

   set1   __pa, #4   ;PA.4 set 1 (but PA.4 was not setup as output before) ==> no output on PA.4

==> here I think might be your problem: In case PADIER.4 is set to 1 (PA.4 is a digital input) then with every SYSCLK? or "port access"? the content of PA.4 is assigned the value of the PIN PA.4 read as digital input. If the next instruction is your switch of PAC.4 then most likely there was no time? / no port access and therefore no update of PA.4. If you put instructions in between (which access the port?) then PA.4 might get updated with the digital input pin value.
 
   set1   __pa, #3   ;PA.3 set 1 (but PA.3 was not setup as output before) ==> no output on PA.3

   set1   __pac, #4 ;PAC.4 set 1 => PA.4 is output now, from now on you can write to PA.4 to set output values
   set0   __pac, #4 ;PAC.4 set 0 => PA.4 is input now, from now on PA.4 will update internally depending on input voltage


My guess would be a simple addition of:

  PADIER &= ~(1<<4);

at the beginning of your test code will most likely bring up the behavior you expect.
You also should consider explicitly setting up PAPH (disable pull high).

EDIT:
Details: Chapter "5.9 IO Pins" in PFS154 manual => see "Fig. 7: Hardware diagram of IO buffer"

After looking at the diagram the flip flops and the signals all is orchestrated by the MUX. There should be no influence of the value in the WR-flip-flop by any other port access.

EDIT2:

MAYBE, you use an older version of SDCC which in fact generates assembly instructions to "read port value, do arithmetic, write port value". Then the behavior would be explainable with a wrongly configured "PADIER".

Can you check the assembler output of your code if bit set/clr instructions or port reads are used?


JS
« Last Edit: January 19, 2021, 03:37:58 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1274 on: February 04, 2021, 03:38:10 am »
Hi everyone:
Padauk IDE 0.91 version. It update PDK "29" version
Don't depdk it?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf