EEVblog #1144 - Padauk Programmer Reverse Engineering

[EEVblog]

You saw Dave struggling when he tried his own "Hello World" (even that there are fully working and pre compiled examples including make files coming with the EasyPDK programmer software... He just overlooked this).
EDIT: Direct link to EasyPDK code examples: https://github.com/free-pdk/easy-pdk-programmer-software/tree/master/Examples  <=============== CODE EXAMPLES

Yep, missed that!
But why didn't the code I had work on the PMS150C?

[tim_]

Awesome work Tim!
If people can buy a turn-key assembled board from JLC then that wold be awesome, but one-off's aren't practical so someone in each country couldn't make up a bunch on sell locally perhaps?
Don't JLC have a public open source projects thing?
Will this be going back into the git?

Thanks a lot! Although the amount of work I had to invest does of course pale to that of the original design.

There are still some things to be clarified before this can be released. I will add some more notes later. The easiest would be to host the files on github with clear instructions how to order.

I agree that economics of this would improve a lot if people shared orders. The MOQ for many of the components is not even reached yet, so the cost would go down further when panelizing and ordering 20 or 50 boards at once. I don't have a good idea how to organize this other than people taking the initiative to redistribute locally.

[spth]

Fully agree. To be really honest, we may need to solve the issue of having example code for four different environments first. (Small C examples, Philips examples with no make file, my examples using different includes etc.).

When I wrote my examples, the idea was to have them as part of short tutorials, such as I did for STM8 (and MCS-51) before:

http://www.colecovision.eu/stm8/

There I am trying to give a full walkthrough on a simple code example to get to "Hello, world!" (or blinking LEDs, or a benchmark - the latter won't work on pdk due to lack of RAM) for oneboard at a time, covering many common boards.

However, the samples also worked well for a workshop on µC-programming for bachelor students (with previous C experience, but no µC experience) that I did a year ago at the university of Freiburg.

I guess in the end, there will be multiple code samples and tutorials by many people anyway; at some point it might be a good idea to have a wiki page or such giving a quick overview / comparison of them.

[greenpossum]

Hi I whipped up a Code::Blocks wizard for Padauk projects at:

https://github.com/kenyapcomau/codeblocks-wizard-pdk

I don't actually have any hardware at the moment, I just tested with a dummy main.c file with SDCC 3.9 so please raise an issue at the repository if I have got anything wrong. I have a dropdown for pdk14 and pdk15. Should I add pdk13 and pdk16? Which is the best default choice in the dropdown?

[spth]

Hi I whipped up a Code::Blocks wizard for Padauk projects at:

https://github.com/kenyapcomau/codeblocks-wizard-pdk

I don't actually have any hardware at the moment, I just tested with a dummy main.c file with SDCC 3.9 so please raise an issue at the repository if I have got anything wrong. I have a dropdown for pdk14 and pdk15. Should I add pdk13 and pdk16? Which is the best default choice in the dropdown?

Thanks.

As of current SDCC 4.0, pdk14 and pdk15 are considered stable, pdk13 is considered experimental / in development (sinceit has recevied less testing that pdk14 and pdk15). We are still quite far away from pdk16 support. So I suggest to have pdk13, pdk14 and pdk15 in the dropdown.

[greenpossum]

Ok, done. Dropdown contains pdk{13,14,15}.

[js_12345678_55AA]

You saw Dave struggling when he tried his own "Hello World" (even that there are fully working and pre compiled examples including make files coming with the EasyPDK programmer software... He just overlooked this).
EDIT: Direct link to EasyPDK code examples: https://github.com/free-pdk/easy-pdk-programmer-software/tree/master/Examples  <=============== CODE EXAMPLES

Yep, missed that!
But why didn't the code I had work on the PMS150C?

Hi Dave,

the code actually seemed to work. You just did not include the IC calibration. This means, the internal clock of every PADAUK IC differs from part to part so a calibration of the clock frequency is required. EASY PDK Programmer can do this for you. You only need to add a macro and programmer will detect this and tune your IC during writing. Have a look at the examples mentioned in programmer repository (in Examples/src folder).
If you do not tune the IC the SYSCLOCK most likely will 80% to slow or 80% to fast. In your video it was clearly visible, that the serial output was there, just used totally wrong timing..

JS

BTW: MANY THANKS for providing this platform for people like us to discuss and develop this kind of projects! 

[js_12345678_55AA]

Ok, done. Dropdown contains pdk{13,14,15}.

Hi,

could you have a look at the examples from free pdk software: https://github.com/free-pdk/easy-pdk-programmer-software/tree/master/Examples/src

There are header files for some ICs: https://github.com/free-pdk/easy-pdk-programmer-software/tree/master/Examples/src/easypdk
and also examples what you need as minimum when you start a new project.

Especially the tuning of the IC SYSCLOCK:

#include "easypdk/pdk.h"

unsigned char _sdcc_external_startup(void)
{
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,4000);        //tune SYSCLK to 8MHz @ 4.000V
  return 0;                                     //perform normal initialization
}

void main(void)
{
  //...
}

Compile with one of those lines:

sdcc -DPMS150C -mpdk13 -o myprog_pms150c.ihx myprog.c
sdcc -DPFS154 -mpdk14 -o myprog_pfs154.ihx myprog.c
sdcc -DPFS173 -mpdk15 -o myprog_pfs173.ihx myprog.c


Write to IC with one of this lines:

easypdkprog --icname=PMS150C  write myprog_pms150c.ihx
easypdkprog --icname=PFS154  write myprog_pfs154.ihx
easypdkprog --icname=PFS173  write myprog_pfs173.ihx



Example output when programing IC:
Erasing IC... done.
Writing IC... done.
Calibrating IC (@4.00V IHRC SYSCLK=8000000Hz)... calibration result: 7946104Hz (0x84)  done.

JS

[greenpossum]

Ok I've augmented the sample main program. Also added a hint to define the processor model in project options.

How should I handle the defines for the variants? Currently one chooses the architecture which sets the -m and -l options and any project specific defines are up to the programmer.

If the dropdown is a list of chips implying an architecture, then that list might keep expanding, unlike architectures which expand slowly (only pdk16 expected later). Also each target will have different options, and if a project has multiple targets that can be handled by C::B like this:

http://forums.codeblocks.org/index.php?topic=9277.0
https://imagecraft.com/help/ICCV8AVR/iccavr/3-ide_codeblocks/multi-target_support_and_build_properties.htm

So I'm inclined to keep the list of architectures in the dropdown as it is now for simplicity and let people who use multiple targets tweak the options.

I don't know how to register and interface programs like easypdkprog to C::B. Maybe a plugin is required, I have to find out.

[HwAoRrDk]

I don't know how to register and interface programs like easypdkprog to C::B. Maybe a plugin is required, I have to find out.

I suppose that would fall under the categorisation of a Code::Blocks 'Tool'. That's how I have, for instance, stm8flash and stm8gal set up in C::B. You can use variables in the command-line parameters of each tool for things like the output file, etc.

For example, I have the parameters set up for stm8flash like so:

Executable: C:\[...]\stm8flash.exe
Parameters: -c stlinkv21 -p ${MCU} -s flash -w "${TARGET_OUTPUT_FILE}"
Working Dir: ${PROJECT_DIR}

The MCU variable is defined in the project's build options (e.g. MCU = STM8S208RB).

So, I think in the case of easypdkprog, because the chip model needs to be passed both as a macro definition when compiling, as well as to the programmer command line, then for the new project wizard you'd want it to set up an MCU (or whatever appropriate name) variable in the build options (with value e.g. "PFS154"), then also in build options compiler settings add a #define of ${MCU} (so it gets passed as a -D option to the compiler).

Then, the tool could be configured as follows:

Executable: \path\to\easypdkprog
Parameters: --icname=${MCU} write "${TARGET_OUTPUT_FILE}"
Working Dir: ${PROJECT_DIR}

The one thing I don't know is whether you can have pre-defined tool definitions be installed, or whether they're only user-configurable.

[greenpossum]

Yeah I discovered that too. I see that it's stored in the users global config not in the project config so cannot be generated by a template. So I'll leave it for now.

[electronic_eel]

p.s.: It seems that EasyEDA has updated all their libraries with slightly increased solder pad sizes. If you update the footprints, a lot of designrules in the easypdkprogrammer pcb are violated.

So essentially they change something in their library or program, and your project, which was previously completely fine, now requires lot's of changes just to get it into a working shape again. That is why I really dislike cloud services like this.

So I'd prefer if we move to a different EDA suite which is known for being more stable than this. I think the work being done by thomasesr in https://github.com/free-pdk/easy-pdk-programmer-hardware/pull/14 is the better direction for going forward. A JLCPCB SMT optimized or lite version could then be based on top of that.

[tim_]

p.s.: It seems that EasyEDA has updated all their libraries with slightly increased solder pad sizes. If you update the footprints, a lot of designrules in the easypdkprogrammer pcb are violated.

So essentially they change something in their library or program, and your project, which was previously completely fine, now requires lot's of changes just to get it into a working shape again. That is why I really dislike cloud services like this.

So I'd prefer if we move to a different EDA suite which is known for being more stable than this. I think the work being done by thomasesr in https://github.com/free-pdk/easy-pdk-programmer-hardware/pull/14 is the better direction for going forward. A JLCPCB optimized or lite version could then be based on top of that.

No, actually they ask you if you want to update. But if you confirm, your next DRC will look aweful. Probably this can be fixed by adjusting design rules.

[electronic_eel]

No, actually they ask you if you want to update. But if you confirm, your next DRC will look aweful. Probably this can be fixed by adjusting design rules.

But can you decline the update, keep the pcb untouched by their updates and still make changes to it?

[tim_]

No, actually they ask you if you want to update. But if you confirm, your next DRC will look aweful. Probably this can be fixed by adjusting design rules.

But can you decline the update, keep the pcb untouched by their updates and still make changes to it?

Well, that's what I did after I learned from my mistake

[greenpossum]

I suppose that would fall under the categorisation of a Code::Blocks 'Tool'. That's how I have, for instance, stm8flash and stm8gal set up in C::B. You can use variables in the command-line parameters of each tool for things like the output file, etc.

As well as being a tool and outside the scope of the wizard template, I think easypdkprog should be at least wrapped in a shell/cmd script so that it will prompt for the MCU to be inserted and get confirmirmation before burning. I don't have any chips or programmer so that's something for another hacker or another day.

[js_12345678_55AA]

p.s.: It seems that EasyEDA has updated all their libraries with slightly increased solder pad sizes. If you update the footprints, a lot of designrules in the easypdkprogrammer pcb are violated.

So essentially they change something in their library or program, and your project, which was previously completely fine, now requires lot's of changes just to get it into a working shape again. That is why I really dislike cloud services like this.

So I'd prefer if we move to a different EDA suite which is known for being more stable than this. I think the work being done by thomasesr in https://github.com/free-pdk/easy-pdk-programmer-hardware/pull/14 is the better direction for going forward. A JLCPCB optimized or lite version could then be based on top of that.

No, actually they ask you if you want to update. But if you confirm, your next DRC will look aweful. Probably this can be fixed by adjusting design rules.

This looks like a quirks in EasyEDA... I found that it has something to do with IMPERIAL / METRIC settings and rounding.
I could prevent this by switching Units to "mil" in canvas settings, then do the PCB update, then switch back to "mm".

JS

[wolf22]

When I look onto the shown schematics, I think, a usual PIC programmer would do the same job. Just apply a programmable Vcc, a also programmable Vpp and a clock + data.

And do not say, that a STM32F103 cannot do the job. I append a small PIC programmer of my own. Use it as you want (if you want).

Looking on the firmware of the 'easypdkprog' I feel, that it is wrong to implement the algorithms into the programmer hardware. They should remain on the PC side. The firmware of the programmer should do only the basic low level functions, so that any changes in the algorithms do not require any update of the programmer itself.

btw: it also seems to me not useful to have a DIL tht footprint on the programmer. All the Padauk controllers come in SMD and so the board where they reside needs a socket for a kind of programming cable. So the programmer itself only needs to have also a connector for this cable.
regards

[spth]

btw: it also seems to me not useful to have a DIL tht footprint on the programmer. All the Padauk controllers come in SMD and so the board where they reside needs a socket for a kind of programming cable. So the programmer itself only needs to have also a connector for this cable.
regards

Some connector is needed anaway, so it might be as well the DIL footprint. While LCSC currently only stocks SMD parts, according to Padauk datasheets, DIL parts exist.

[tim_]

This looks like a quirks in EasyEDA... I found that it has something to do with IMPERIAL / METRIC settings and rounding.
I could prevent this by switching Units to "mil" in canvas settings, then do the PCB update, then switch back to "mm".

Indeed, that could be it. The deviations are usually quite small, so maybe it's a rounding error at minium dimensions.

Btw, could you comment on the functionality of the three LEDS in the easypdkprog? I could not find any documentation, but probably i looked into the wrong place. Would it be ok to remove one so there is space for some text to describe functionality?

[tim_]

When I look onto the shown schematics, I think, a usual PIC programmer would do the same job. Just apply a programmable Vcc, a also programmable Vpp and a clock + data.

And do not say, that a STM32F103 cannot do the job. I append a small PIC programmer of my own. Use it as you want (if you want).

...

btw: it also seems to me not useful to have a DIL tht footprint on the programmer. All the Padauk controllers come in SMD and so the board where they reside needs a socket for a kind of programming cable. So the programmer itself only needs to have also a connector for this cable.
regards

Well, the PIC programming protocoll is very similar, so it is no surprise the programmers are functionally similar. There are some extras though, like the clock calibration, that may not be covered with other programmers.
Your programmer uses many different component, so it also does not have a very optimized BOM for production.

I agree about the connector. Best would be to add a connector to a flatband cable for a SOIC8 clamp. That's what I use for ICP.

[electronic_eel]

btw: it also seems to me not useful to have a DIL tht footprint on the programmer. All the Padauk controllers come in SMD and so the board where they reside needs a socket for a kind of programming cable. So the programmer itself only needs to have also a connector for this cable.

I think the DIL connector was chosen so you can easily plug in a common programming socket. I use this one: https://www.aliexpress.com/item/32716376199.html and it works quite well.
You can also use a clamp style connector like this one: https://www.aliexpress.com/item/32822110321.html

[DenCraw]

HI.
Great job!.

any chance to make a simulator?... i know the IC's are cheap but....
anyway again thank's Dave for sharing this amazing work!. i have a  lot to learn now. don't worry I'll RTFM before asking.

[wolf22]

Your programmer uses many different component, so it also does not have a very optimized BOM for production.

Yes, this programmer has a quite different approach. It is intended to feed VCC to a board, which may consume more current than the PIC itself would need. Also it is intended to set the voltage on VCC to values from approx. 2 volts to nearly 7 volts from the supply via USB and maintains the logic levels according to this span. That's probably a bigger gun than required for programming a Padauk controller.

But there are some details in the hardware, I would like to point on: the setup of the voltages is separated from the switches, it needs only a usual PWM and it is limited by the choosen values of the resistors, so no fault can occure if the software fails to limit it to the bounds given by the manufacturer.

But this is only a matter of hardware.

My problems with the easypdkprog are software problems, in particular the lacking definitions of the protocol between PC and programmer on the USB. I use to start any development by writing down the interface and protocol between different parts (like PC software and µC firmware), so the whole development can be divided into smaller parts and can be written separately.

And I love to split down the necessary functions of the programmers firmware to atomic ones, so the algorithms can be left on the PC side without making the whole procedere clumsy. If there is an interest in this, I can post it here.

regards

[spth]

HI.
Great job!.

any chance to make a simulator?... i know the IC's are cheap but....
anyway again thank's Dave for sharing this amazing work!. i have a  lot to learn now. don't worry I'll RTFM before asking.

There is some (i.e. core is fully supported, but some peripherals are still lacking) support in the ucsim simulator (it comes with SDCC). Also, for development, you can just use a pin-compatible flash part, rather than an OTP one (however, the flash parts are more expensive, typically in the range of 0.07$ each).