The assembler was contributed by Nicolas Lesser. I just merged a patch by him that fixes this issue.
Philipp
The assembler was contributed by Nicolas Lesser. I just merged a patch by him that fixes this issue.
Philipp
What would be the best way to get feedback and patches to him? I found and fixed a bug in enconding SL/SLC/SR/SRC. Fix attached.
Added you to free-pdk organization on github*.
Thanks a lot! I will put the programming protocol information there.
Btw, in general:
It seems like every other padauk device is using a different programming algorithm. So far, only two are known: PFS154 ("5-wire", confirmed twice), PMS150C ("six-wire". The PMC150C algorithm also works on the PMS154C, when changing datalen.
I tried a couple of other device:
- PMC251 uses six-wire physical interface, but was unresponsitve with the PMC150C algorithm
- PMS131 uses an eight-wire physical interface and seven when in an 8-pin package
It could get quite tedious to also decode all devices. Hopefully all MTP devices will use the 5-wire protocol.
To get the patches to him, I'd suggest opening an issue or pull request at his repo:
https://github.com/Rakete1111/sdcc-pdk
How about the PFS173? From the datasheet it looks as if it uses the same pins as the PFS154.
On the other hand, my information on the PFC232 and PFS232 indicates that these two use an interface different from the PFS154, and PA4 has a role in programming them (for a total of 6 pins in the interface).
- both assembled boards are working (tested basic functions: generate +15V, dual DAC+opamp can output specific voltages, USB ok, LEDs ok, button ok, ...)
- only 1 small mistake on test PCB (forgot to connect something to ground, was easy to fix with a jumper wire)
Nice!
May I suggest one addition for the next revision of the board:
Add another row of 8 holes in 2.54mm raster, spaced 15.24mm (6 rows in 2.54mm raster) from the current one. Connect all the holes to GND.
This would allow to later create small adapter pcbs, which can then be securely plugged on top of the programmer with pin header sockets. In these adapter pcbs you can then plug in programming sockets for the Padauk controllers.
See here for details of the idea: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2105053/#msg2105053
My initial idea was to go sideways.
I already created a small adapter PCB with a ZIF20 DIP small socket which can get connected to the 8 pins directly but also has pin header for every pin of the ZIF20 socket so it can be used as a generic adapter with jumper wires. This allows all PADAUK ICs to be written regardless of the pinout.
Anyway I also like the on top idea. But new problems will arise like can not see LEDs or reach user button anymore, ...
Posts: 101
Country: ht
View Profile Personal Message (Offline)
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #479 on: Yesterday at 10:39:40 am »
Say ThanksReplyQuote
I assembled the 2 PCBs of my "easy pdk programmer" today.
- complete design process was done using EasyEDA + JLPCB + LCSC.
- learning how to use EasyEDA was very easy
- ordering on JLPCB was smooth and very good price ($2 for 10 PCBs, if you panelize then you might get 40 programmer PCBs for just $2 + shipping)
- ordering components at LCSC based on EasyEDA BOM was also very easy, they offer to combine shipment with JLPCB so you pay shipping ($5 for normal delivery) only once.
- it only took 8 days from ordering PCB + components till arrival *wow*
- both assembled boards are working (tested basic functions: generate +15V, dual DAC+opamp can output specific voltages, USB ok, LEDs ok, button ok, ...)
- only 1 small mistake on test PCB (forgot to connect something to ground, was easy to fix with a jumper wire)
I will test programing a PFS154 and some other ICs within the next days. Hopefully getting everything ready before chinese new year starts (China closes on 30th of January for 2-3 weeks).
JS
P.S. I will upload schematics, gerber and firmware sources to github as soon as the stable programmer is confirmed working.
PPS:
The PCB on top of the picture is having the optional 4 pin SWD header for easy debugging. The PCB on bottom is having an optional GND pin for easy oscilloscope measurements. Both of this optional components are not required for normal operation of the programmer later.
The missing components are caused by choosing a different DCDC booster and by getting rid of the not required level shifter.
I'd also suggest to add another button connected BOOT0 to boot with the integrated usb bootloader. That way you don't need a SWD programmer for initial programming. This would make it easier for people to make their own padauk programmers when they don't regularly use STM32 or other controllers with SWD interface.
My initial idea was to go sideways.Yes, that would also work. But in my experience sideways going female headers (the ones that would go on the next pcb to the side) are more expensive and more rare than the straight ones. That is why I'd prefer to go on top.
I already created a small adapter PCB with a ZIF20 DIP small socket which can get connected to the 8 pins directly but also has pin header for every pin of the ZIF20 socket so it can be used as a generic adapter with jumper wires. This allows all PADAUK ICs to be written regardless of the pinout.Jumper wires are ok during programmer development. But I'd like to avoid them for regular use afterwards: they tend to create EMI problems and sometimes make bad contacts. So I'd prefer a solution with adapter pcbs which are made for one kind of Padauk controller. You can fit a lot of different ones on one 10x10 pcb.
Anyway I also like the on top idea. But new problems will arise like can not see LEDs or reach user button anymore, ...You could move the button to where the URL text is now.
BTW, what do you plan to use the button for?
I'd also suggest to add another button connected BOOT0 to boot with the integrated usb bootloader. That way you don't need a SWD programmer for initial programming. This would make it easier for people to make their own padauk programmers when they don't regularly use STM32 or other controllers with SWD interface.
Having the serial bootloader accessible would be nice, but it missing is not a deal breaker.
A lot of changes are requested/required (e.g. mounting holes, adapter on top, ...) I will see how much I can put into it.
I assembled the 2 PCBs of my "easy pdk programmer" today.
...
I will test programing a PFS154 and some other ICs within the next days. Hopefully getting everything ready before chinese new year starts (China closes on 30th of January for 2-3 weeks).
I only can strongly recommend to switch to real software development (use JTAG/SWD and a debugger) and avoid the "printf debugging" introduced by Arduino.
Setting up and learning how to use the free open source tool chains for real development and debugging is dead simply nowadays. And it is possible to use all Arduino libraries and sample code.
Just ditch the Arduino IDE!
Any success with programming so far?
Well, it looks like we are stuck with "printf debugging" with the Padauk controllers though. One thing I implemented was to use the programming interface as an SPI backchannel. The "programmer" (I am referring to my breadboard contraption) is resetting the MCU and is then listening to SPI transmissions on the programming interface lines as a slave. This allowed some degree of debugging. This may be an interesting addition to the firmware of your programmer as well.
But do you think SPI is a good choice? I used it in a previous test and had the problem that if a single bit was missing (e.g. after startup) the complete output was garbled.
spth made a small demo with a very simple UART. Maybe we should choose this method as it can handle transmission errors more easy (e.g. require 2 stop bits and we can resync).
Or we use SPI with CS(NSS) but then 1 more wire required.
Having an UART with autobaud would be the best option, but it's a bit more involved to implement this on host side. How would you do bitrate detection? By bitbanging? Or oversampling with DMA?
I adapted SDAS to PDK13, so it is now also possible to use a OSS toolchain for the true "$0.03 MCU". Not sure whether this will be available upstream anytime soon, as there is still some work to be done to allow PDK13 and PDK14 to coexist in SDCC. (Frankly, that is probably the harder part...)
Where can I find this sdas for pdk13? How is the target selected? An assembler directive similar to how ".cs08" switches the hc08 assembler to s08 mode and .hd64 switches the z80 assembler to z180 mode?
Philipp
0 0 0 0 1 1 c 7-bit MEM addr c 16 bit memory operations
0x03.. 0 0 0 0 1 1 0 M 0 STT16 M M ← Timer16 (last bit of M set to 0, M must be word aligned)
0x03.. 0 0 0 0 1 1 0 M 1 LDT16 M Timer16 ← M (last bit of M set to 1, M must be word aligned)