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

0 Members and 1 Guest are viewing this topic.

Offline cnlohr

  • Newbie
  • Posts: 4
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #575 on: May 08, 2019, 05:16:56 pm »
do a port to the '8266
I wonder what the usecase for that is? For example for me it would be much more work to integrate the esp into my network than just to plug in a usb cable.
A side-goal of mine is I want to make an arduino-style development environment, that is 100% web-based. This part is purely for funzies.  It's something I've wanted to dink with for a while.  Currently most of the web-based ones are for high-level languages, but these are not interesting to me, and this here affords me an opportunity to cut my teeth with web-based compilation.  EDIT: Because of the power rail complexity, I am definitely feeling discouraged from an ESP8266 solution.

2) Any idea how sensitive the voltages are, for instance what the optimal values are for VPP and VDD at different stages?  Do we ever /need/ to set VPP higher than 8.3V?
VPP must go to 10.8. There are some reports of problems when not getting the voltages right in this thread.
Understood.

3) Why didn't you guys go STM32F042 I didn't see anyone mentioning it?  The crystal-less operation makes things really convenient and cheap.
The ´72 is very similar, also does crystal-less. But the ´42 is not as common and more expensive.

The '72 is much more expensive than the '42.  A while go, the cost difference for the crystal + a '70 was sufficient to warrant the '42, but now the cost difference looks like it's pulled ahead to almost $0.10... $0.05 for the added through-hole assy cost + $0.05 for a crystal.  Looks like it's about a wash now.  Just something to keep in mind in the future.


NEW Q:
Are there any other hangouts or areas that people interested in the Padauk chips hang out in?  I've read all the way through this thread, and want to make sure I don't make redundant work for folks.

EDIT:
There were other design decisions that I really questioned, but as I've read more and looked into it more, I'm starting to understand the rationale behind them.  This is a really awesome design both from a software and hardware end!
« Last Edit: May 08, 2019, 05:29:06 pm by cnlohr »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #576 on: May 09, 2019, 11:40:32 am »
Hi,

STM32F072 is by far the most cheap processor fulfilling the requirements I had in mind:

- USB for easy power supply and connectivity
- 2x DAC to create different VPP and VDD voltage references (no DAC on STM32F042)
- 2x ADC to read/monitor the final (amplified) VPP/VDD
- enough IO for all data lines
- > 12kB of RAM to hold the max. complete program (3k words @ 16 bit) (STM32F042 has only 6 kB!)
- good price (STM32F072C8T6 $1.1 compared to STM32F042C6T6 $1.4 ==> source: lcsc.com) (the cheaper F042 variants do not have enough IO)

The crystal I added is for calibration of the written IC. Crystalless operation would require to have USB connected to sync to the SOF in order to have a relatively good clock for reference, but still drifting. This would make a standalone use of the programmer (just with a battery pack) impossible.
But it is possible just to not solder the crystal and use it since the STM32F072 has also crystalless mode.


Comment for choice of serial port:
* Windows 10 auto downloads the correct driver, works out of the box (only on older Windows you just need to install the "signed" driver form ST which is included in the release)
* macOS does not need any driver, works out of the box
* Linux does not need any driver, works out of the box (udev rule is only for "speed up" of the availability of the programmer after attaching USB. Some older Linux distributions bundled "Modem Manager" which always spends some seconds with every new attached serial port to find out if it is a telephony modem...)

Any HID implementation need to take into account that:
* HID is specified to be unreliable (you need to handle packet loss/drop yourself which makes the protocol more complex)
* HID with Linux is also not easy. Either you need ROOT permissions for running your software or you need ROOT permissions to install libusb in order to access HID for normal user programs.


Comments ESP8266:
* not sure if ESP8266 has 5V tolerant pins which you really need to have
* any non USB solution (e.g. with ESP8266) would need an extra power supply

Regarding GPL: The GPL was chosen intentionally for a good reason. Only fully open source should be the goal of the open source programmer we try to create here. There are no plans to re-license anything.


JS

BTW:
In development branch of the programmer software ( https://github.com/free-pdk/easy-pdk-programmer-software/tree/development ) you can see that I added several new IC types (probe/read for now).
I already identified 2 more protocol variants. It looks like the older processor generations require *all* 8 pins ( 3: VDD/VPP/GND + 5: CLK,DATIN,DATOUT,CLK2,ACK) for programming.
Out of pure luck the existing design of the programmer can be used for all of them :)

Yesterday I got my order from LCSC.com. I think I have all PADAUK and PUOLOP ICs now which I can easily source from public sellers:

UPDATE: The PUOLOP ICs are 100% identical compared to their PADAUK pendants. Exact same IC ID is reported when probing/reading. -> There are no Puolop specific ICs.

Work in progress in development branch (most are probe/read only right now):

./easypdkprog list
Supported ICs:
 PMC251   (0x058): OTP  : 1024 (16 bit), RAM:  96 bytes
 PMS132   (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS132B  (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS150C  (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes
 PMS152   (0xA27): OTP  : 1280 (14 bit), RAM:  80 bytes
 PMS271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes
 PFS154   (0xAA1): FLASH: 2048 (14 bit), RAM: 128 bytes
 PMS133   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes
 PMS134   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes
 PMS131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes
 PMS171B  (0xD36): OTP  : 1536 (14 bit), RAM:  96 bytes
 PMS154B  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS154C  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PFS173   (0xEA2): FLASH: 3072 (15 bit), RAM: 256 bytes
« Last Edit: May 09, 2019, 10:23:02 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: thm_w

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #577 on: May 10, 2019, 05:00:24 pm »
How about the Puolop PTBO164SX? According to Puolop, it has 1.75 KW of ROM, but I don't see a part with that amount of ROM in the Padauk catalog.

According to my understanding and communication with Padauk, Puolop is a reseller of Padauk devices. However, Padauk also makes customer-specific devices. Could it be that the PTBO164SX is a device made by Padauk exclusively for Puolop?

Philipp

P.S.: There are actually a few places in the pdf metadata of the Puolop datasheet, where a PMC164 is mentioned. I guess we can assume that Padauk made the device using PMC164 as the internal name for Puolop, who uses the name PTBO164SX (and just replaced the text in the datasheet given to them by Padauk forgetting a few places).
« Last Edit: May 10, 2019, 05:08:25 pm by spth »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #578 on: May 10, 2019, 11:28:08 pm »
How about the Puolop PTBO164SX? According to Puolop, it has 1.75 KW of ROM, but I don't see a part with that amount of ROM in the Padauk catalog.

Unfortunately I could not find any place where this IC is sold.

@contributors from SZ: Puolop HQ is in SZ. Maybe someone can talk to them or go there and get some of the mysterious PTBO164 ?

JS

EDIT: Not so mysterious after all. PADAUK IDE has a "PMS164.INC" include file. OTP-ID is 0x2A31. RAM-SIZE is 0x80 and ROM-SIZE is 0x800 (same as PMS/PFS154).
« Last Edit: May 10, 2019, 11:31:31 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #579 on: May 29, 2019, 02:14:19 pm »
The adapter pcbs for Padauk controllers in SOT23-6 I designed arrived recently. I could test them successfully with a PMS150C-U06. Unfortunately I couldn't persuade LCSC yet to add PFS154-U06 to their catalog.

You can download all source files and documentation from here:
https://github.com/electroniceel/easy-pdk-programmer-hardware/tree/adapter-pcbs/adapter-pcbs
Update: the adapter files have been merged and you can now get them from here:
https://github.com/free-pdk/easy-pdk-programmer-hardware/tree/master/adapter-pcbs

I also uploaded a set of gerbers of a complete panel with the programmer and all my adapters. When I ordered this at JLCPCB I didn't have to pay any extra fee for the panel. But I heard that they recently changed their policy and now charge extra for a panel with different pcbs on it. So YMMV or maybe try another pcb service like Elecrow.
« Last Edit: May 31, 2019, 06:14:41 pm by electronic_eel »
 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #580 on: May 31, 2019, 06:27:25 pm »
@js: thanks for merging my stuff.

I have a question about the clock calibration: when you presented the calibration logic in https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2184683/#msg2184683, you used #defines like EASY_PDK_CALIBRATE_IHRC.

Is there a header file with these defines available somewhere? If not, wouldn't it make sense to publish it and provide it in the easy-pdk-programmer-software package or with sdcc?

@spth: do you think it is possible and makes sense to publish such a header with sdcc? I think it would make the code more portable since the header directory of sdcc itself is usually automatically searched for header files, while the correct header directory of easy-pdk-programmer-software would have to be located first by some kind of script, autotools, cmake,...
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #581 on: June 01, 2019, 04:14:03 pm »
Hi,

I'm working on header file(s). I started to create them while doing some real projects.

Right now I'm undecided if we should have multiple includes, different for each variant, or a generic one with sections specific to architectures like 13/14/15/16 bit.

Attached is my current WORK IN PROGRESS version (one big include file for all). It includes the calibration definitions and many other useful stuff.

JS

Here some examples where I use it:

typical sdcc_external_startup implementation:
Code: [Select]
unsigned char _sdcc_external_startup(void)
{
  PDK_INIT_SYSCLOCK_4MHZ();                   //use 4MHz so we can use 3.0V VDD
  EASY_PDK_CALIBRATE_IHRC(4000000,3000);      //tune SYSCLK = 4MHz @ 3.000V
  return 0;                                   //perform normal initialization
}

interrupt:
Code: [Select]
void interrupt(void) __interrupt(0)
{
  if(_intrq & INTRQ_T16)                      //interrupt request for timer16?
  {
    //do something here...

    _intrq &= ~INTRQ_T16;                     //clear this interrupt request
  }
}

SPI send receive in assembler (universal version, works with 13bit):
Code: [Select]
#define SPI_PORT        _pa
#define SPI_PORTC       _pac
#define SPI_NCS_PIN     4
#define SPI_CLK_PIN     0
#define SPI_OUT_PIN     6
#define SPI_IN_PIN      7

//...

uint8_t SPI_SendReceive(uint8_t s)
{
  __asm__(
    "  mov a, #8                                      \n"  //loop 8 times
    "__SPI_SNDRCV_BIT:                                \n"
    "  set0 "_ASMV(SPI_PORT)", #"_ASMD(SPI_OUT_PIN)"  \n"  //SPI-OUT = 0
    "  t0sn _SPI_SendReceive_PARM_1, #7               \n"  //s.7==0 ?
    "  set1 "_ASMV(SPI_PORT)", #"_ASMD(SPI_OUT_PIN)"  \n"  //SPI-OUT = 1
    "  set1 "_ASMV(SPI_PORT)", #"_ASMD(SPI_CLK_PIN)"  \n"  //SPI-CLK = 1
    "  sl _SPI_SendReceive_PARM_1                     \n"  //s<<=1
    "  t0sn "_ASMV(SPI_PORT)", #"_ASMD(SPI_IN_PIN)"   \n"  //SPI-IN==0 ?
    "  set1 _SPI_SendReceive_PARM_1, #0               \n"  //s.0=1
    "  set0 "_ASMV(SPI_PORT)", #"_ASMD(SPI_CLK_PIN)"  \n"  //SPI-CLK = 0
    "  dzsn a                                         \n"  //loop--
    "  goto __SPI_SNDRCV_BIT                          \n"  //loop again if>0
  );
  return s;
}
« Last Edit: June 01, 2019, 04:16:29 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #582 on: June 02, 2019, 10:47:38 am »
Attached is my current WORK IN PROGRESS version (one big include file for all). It includes the calibration definitions and many other useful stuff.
thanks for posting. This is indeed much more than just the cal definitions.

I think it would make sense to split it up into different files according to pdk-architecture or controllers, maybe also by functions, like cal definition, register definition and so on. But I suggest you first put it up on github so that others can better contribute. Then we can try out what kind of structuring makes most sense, maybe evolve it over time.

Also I still think it may be an option to include it into sdcc. That would make using it easier. But contributing changes would become more complicated as all changes would have to go through the sdcc svn and can't just be merged in github.

 

Offline GromBeestje

  • Frequent Contributor
  • **
  • Posts: 276
  • Country: nl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #583 on: June 23, 2019, 03:39:46 pm »
Regarding GPL: I see the firmware uses ST's USB middleware, which is under ST's SLA0044 license. Ain't this incompatible with GPL (eg. Do you need a linking exception to allow the ST USB Middleware to be used?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #584 on: June 25, 2019, 10:09:26 am »
Hi,

The developed FREE-PDK software is GPL. This is the authors choice and 100% valid.

Regarding ST USB middleware and SLA0044. Not sure which paragraph of SLA0044 you see as problematic.

I see the firmware uses ST's USB middleware, which is under ST's SLA0044 license.
->(1) The USB middleware source code by itself is still under ST license (see file headers of ST USB middleware for details).

Ain't this incompatible with GPL (eg. Do you need a linking exception to allow the ST USB middleware to be used?
->(2) It is explicitly allowed to use the compiled firmware containing ST code to be used on ST microprocessors (which is the case here).

Even the explicit mentioned GPL in (5) refers to another fact. It tries to make clear that the middleware software from ST can never become GPL licensed (which is not the case here, it still falls under the original ST license visible in all ST files).

Maybe this will not fulfill the strict 100% GPL requirements of a complete compiled software package required from some Linux distributions like Debian and therefor the software can not be bundled with Debian but this does not mean that there is a problem using GPL for the FREE-PDK software.

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

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #585 on: June 26, 2019, 08:02:05 am »
The developed FREE-PDK software is GPL. This is the authors choice and 100% valid.
I don't think GromBeestje questioned this.

Even the explicit mentioned GPL in (5) refers to another fact. It tries to make clear that the middleware software from ST can never become GPL licensed (which is not the case here, it still falls under the original ST license visible in all ST files).
The problem is that this is incompatible with the GPL. The GPL requires that all parts of the program are compatible with the GPL. As the ST files are linked into the final program, you can't distribute a binary that complies with the GPL.

Maybe this will not fulfill the strict 100% GPL requirements of a complete compiled software package required from some Linux distributions like Debian and therefor the software can not be bundled with Debian but this does not mean that there is a problem using GPL for the FREE-PDK software.
It means noone, not just linux distributions, is allowed to distribute binary packages of free-pdk as it can't be done in a legally clean manner that complies with the GPL and the SLA0044. i idea. The moment there are contributions from other people in the codebase, even you can't distribute compiled binaries on github anymore unless you have the written permission of all contributors to publish these binaries under a different license than the GPL (as the GPL forbids distributing stuff linked with GPL-incompatible parts). I don't think this is what you intended.

The solution GromBeestje suggested is a good alternative I think: The code stays GPL, but with an added exception that the code may be linked with the ST usb middleware. Then everyone is allowed to distribute binaries, but it does not allow anyone to modify free-pdk without providing the source under gpl conditions.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #586 on: June 27, 2019, 01:32:46 pm »
Hmmmm,

I never looked at it like this.

To me it looks a bit strange to add a text like this:

"GPL linking exception for FREE PDK Programmer STM32 firmware binary: You are allowed to compile and link the complete code from this repository, including the included ST USB middleware, in order to build a binary firmware which you can use on the STM32 based Free PDK programmer."

Do you think this will solve the "problem"?

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

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #587 on: June 27, 2019, 03:46:27 pm »
"GPL linking exception for FREE PDK Programmer STM32 firmware binary: You are allowed to compile and link the complete code from this repository, including the included ST USB middleware, in order to build a binary firmware which you can use on the STM32 based Free PDK programmer."
The GPL doesn't forbid you to compile and link something non-GPL-compliant, it forbids you to distribute this binary. Unfortunately careful wording is required to avoid the pitfalls of legalese...

GPL exceptions are a common thing and I suggest to re-use and adapt what others have done. It looks like for example wget uses something that would fit. See https://en.wikipedia.org/wiki/Wget#License.

I suggest to adapt it like this:

Code: [Select]
Additional permission under GNU GPL version 3 section 7

If you modify this program, or any covered work, by linking or combining it with the STMicroelectronics STM32 USB Device Library (or a modified version of that library),
you are granted additional permission to convey the resulting work. Corresponding Source for a non-source form of such a combination shall include the source code for the
parts of the STM32 USB Device Library used as well as that of the covered work.

 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #588 on: June 28, 2019, 10:04:33 am »
"GPL linking exception for FREE PDK Programmer STM32 firmware binary: You are allowed to compile and link the complete code from this repository, including the included ST USB middleware, in order to build a binary firmware which you can use on the STM32 based Free PDK programmer."
The GPL doesn't forbid you to compile and link something non-GPL-compliant, it forbids you to distribute this binary. Unfortunately careful wording is required to avoid the pitfalls of legalese...

GPL exceptions are a common thing and I suggest to re-use and adapt what others have done. It looks like for example wget uses something that would fit. See https://en.wikipedia.org/wiki/Wget#License.

I suggest to adapt it like this:

Code: [Select]
Additional permission under GNU GPL version 3 section 7

If you modify this program, or any covered work, by linking or combining it with the STMicroelectronics STM32 USB Device Library (or a modified version of that library),
you are granted additional permission to convey the resulting work. Corresponding Source for a non-source form of such a combination shall include the source code for the
parts of the STM32 USB Device Library used as well as that of the covered work.

Hi electronic_eel,

Thank you very much for digging this out and your suggestion. I will adapt this and extend the license of the firmware code using the text from you.

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 #589 on: June 30, 2019, 11:52:38 am »
Hi,

To understand the register mappings on different PDK CPU types better I created a list (based on include files from original IDE).

https://github.com/free-pdk/fppa-pdk-documentation/blob/master/PDK_register_mapping_scroll_right.csv

Attached is a colorful version as PNG from it.

Based on this info (most registers jump around for different types and only a few number remains static) I think the best idea would be to create one include file per supported processor like:

pdk/pmc150c.h
pdk/pfs154.h
pdk/pfs173.h
...

Comments? Suggestions?


JS
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: oPossum, thm_w

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #590 on: July 01, 2019, 05:45:50 am »
Quote
Hi,

To understand the register mappings on different PDK CPU types better I created a list (based on include files from original IDE).

https://github.com/free-pdk/fppa-pdk-documentation/blob/master/PDK_register_mapping_scroll_right.csv

Attached is a colorful version as PNG from it.

Based on this info (most registers jump around for different types and only a few number remains static) I think the best idea would be to create one include file per supported processor like:

pdk/pmc150c.h
pdk/pfs154.h
pdk/pfs173.h
...

Comments? Suggestions?


JS
I agree with you, also we can copy what ST has done to STM32, and the HAL and libraries for them, they are very good :)
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline vollmars

  • Newbie
  • Posts: 1
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #591 on: July 01, 2019, 12:11:04 pm »
Hi,

To understand the register mappings on different PDK CPU types better I created a list (based on include files from original IDE).

https://github.com/free-pdk/fppa-pdk-documentation/blob/master/PDK_register_mapping_scroll_right.csv

Attached is a colorful version as PNG from it.

Based on this info (most registers jump around for different types and only a few number remains static) I think the best idea would be to create one include file per supported processor like:

pdk/pmc150c.h
pdk/pfs154.h
pdk/pfs173.h
...

Comments? Suggestions?


JS

Hi,

thank you, for all the work you done.
In the table i miss the Timer3 registers for the PFS154.

vollmars
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #592 on: July 02, 2019, 08:48:32 pm »
In the table i miss the Timer3 registers for the PFS154.

Yes I forgot TM3 for PFS154, but for sure there are more mistakes in the table. I just did it to get an idea of the register mapping.

JS

« Last Edit: July 02, 2019, 09:47:39 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline lanserge

  • Newbie
  • Posts: 1
  • Country: gb
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #593 on: July 23, 2019, 06:37:38 pm »
Hi, Guys

I have joined the forum to say big thank you for the work you have done.

Today I managed to get stable read and write PMS150c-u06 with the knowledge from this forum.
I made programmer from mostly assembled modules from e-bay.
I used ready MT3608 step up module to get 16V out of 5V.
I used two MCP4725 modules to have two programmable DACs (on one of the modules I soldered jumper to have different address on I2C).
Also I soldered LM358S-13 IC  on DIP adapter, double OP-AMP powered from 16V to get programmable VDD and VPP: each op-amp has plus input connected to corresponded MCP4725 module output, minus input connected to voltage divider with 8.2k to the ground and 16.2k to the op-amp output.
Basically idea from here: http://henrysbench.capnfatz.com/henrys-bench/arduino-projects-tips-and-more/a-powerful-little-arduino-programmable-10v-supply/  but without transistor (small current expected).
And finally I used CH341A mini programmer with I2C connected to MCP4725 modules and other pins in next order:
D0 which is marked as CS on the board connected to chip MISO (the D7 MISO on CH341 is not suitable,
because needs to be D0-D5 for bit banging)
D3 which is marked as SCK - to chip SCK
D5 which is marked as MOSI - to chip MOSI
I set chip VDD and VPP via I2C programming MCP4725 modules and
I wrote my own python code that utilising bitbanging protocol of the CH341A IC to do the rest.
The target VDD used is 5V.
So everything works and I checked everything with my Saleae logic analyser.

The only question I have is some odd behaviour I found.
If I use aborted write cycle to read chip ID I get 0xA16 but if I use second read cycle I always get 0x50B which is obviously shifted by a bit to the right.
So my question is which is actually right ID? Who said it should be 0xA16 and not 0x50B?
Also if I have aborted write cycle I need to power off IC because the state machine is off but with read cycle everything continue to work stable.
So I prefer the second way.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37626
  • Country: au
    • EEVblog
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #594 on: July 24, 2019, 04:25:33 am »
I haven't followed this thread for a long time, but it sounds like there has been huge progress in this?
Can someone give me a TLDR; of the current status?
Thanks.
 
The following users thanked this post: ucanel, icraftcrafts

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #595 on: July 24, 2019, 06:26:29 am »
The programming algorithm for many Padauk microcontrollers is reverse engineered, a C compiler (SDCC) was ported to it and is stable for most types, an open source programmer was developed and many chips could be flashed successfully.

Details:
- my 4 channel ADC project, with which I sampled the programming signals of an original Padauk programmer:  https://www.eevblog.com/forum/projects/4-channel-adc-10-mhz-8-bit-design/msg2075176/
- sample recording: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2096917/#msg2096917
- first protocol reverse engineering: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2099854/#msg2099854
- open source hardware programmer: https://github.com/free-pdk/easy-pdk-programmer-hardware
- C compiler: https://github.com/free-pdk/sdcc-pdk-code-examples
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 
The following users thanked this post: EEVblog, ucanel, icraftcrafts

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #596 on: July 24, 2019, 07:39:25 am »
Quote
C compiler: https://github.com/free-pdk/sdcc-pdk-code-examples
Thanks for the info, this link is only the examples, though I installed SDCC, how to compile the examples? what's the command?
There is no makefile with the examples and compiling the count-pfs154 example with this command generate lot's of errors and warnings!


ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #597 on: July 24, 2019, 09:48:48 am »
I downloaded the latest snapshot of SDCC from this site (was sdcc-snapshot-amd64-unknown-linux2.5-20190723-11326.tar.bz2 for my Linux system). Then I could compile it like this:
Code: [Select]
~/sdcc/bin/sdcc -lpdk15 -mpdk15 count.c

It creates a lot of output files:

Code: [Select]
-rw-r--r-- 1 frank frank  4424 Jul 24 11:44 count.sym
-rw-r--r-- 1 frank frank 19123 Jul 24 11:44 count.rst
-rw-r--r-- 1 frank frank  6046 Jul 24 11:44 count.rel
-rw-r--r-- 1 frank frank  8774 Jul 24 11:44 count.map
-rw-r--r-- 1 frank frank 19123 Jul 24 11:44 count.lst
-rw-r--r-- 1 frank frank   192 Jul 24 11:44 count.lk
-rw-r--r-- 1 frank frank  1132 Jul 24 11:44 count.ihx
-rw-r--r-- 1 frank frank     0 Jul 24 11:44 count.cdb
-rw-r--r-- 1 frank frank  1720 Jul 24 11:37 count.c
-rw-r--r-- 1 frank frank  6843 Jul 24 11:44 count.asm

I think the ihx file then can be programmed with easypdkprog, as you can see here.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #598 on: July 24, 2019, 01:02:28 pm »
Thanks FrankBuss :-+ :-+ :-+
That works here too, how did you find the commands -lpdk15 -mpdk15, there is nothing like them in the help

If I just type SDCC in the command
Quote
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk14/pdk15 3.9.0 #11195 (MINGW64)
published under GNU General Public License (GPL)
Usage : sdcc [options] filename
Options :-

General options:
      --help                Display this help
  -v  --version             Display sdcc's version
      --verbose             Trace calls to the preprocessor, assembler, and linker
  -V                        Execute verbosely. Show sub commands as they are run
  -d                        Output list of mcaro definitions in effect. Use with -E
  -D                        Define macro as in -Dmacro
  -I                        Add to the include (*.h) path, as in -Ipath
  -A
  -U                        Undefine macro as in -Umacro
  -M                        Preprocessor option
  -W                        Pass through options to the pre-processor (p), assembler (a) or linker (l)
  -S                        Compile only; do not assemble or link
  -c  --compile-only        Compile and assemble, but do not link
  -E  --preprocessonly      Preprocess only, do not compile
      --c1mode              Act in c1 mode.  The standard input is preprocessed code, the output is assembly code.
  -o                        Place the output into the given path resp. file
      --print-search-dirs   display the directories in the compiler's search path
      --vc                  messages are compatible with Micro$oft visual studio
      --use-stdout          send errors to stdout instead of stderr
      --nostdlib            Do not include the standard library directory in the search path
      --nostdinc            Do not include the standard include directory in the search path
      --less-pedantic       Disable some of the more pedantic warnings
      --disable-warning     <nnnn> Disable specific warning
      --Werror              Treat the warnings as errors
      --debug               Enable debugging symbol output
      --cyclomatic          Display complexity of compiled functions
      --std-c89             Use ISO C90 (aka ANSI C89) standard (slightly incomplete)
      --std-sdcc89          Use ISO C90 (aka ANSI C89) standard with SDCC extensions
      --std-c95             Use ISO C95 (aka ISO C94) standard (slightly incomplete)
      --std-c99             Use ISO C99 standard (incomplete)
      --std-sdcc99          Use ISO C99 standard with SDCC extensions
      --std-c11             Use ISO C11 standard (incomplete)
      --std-sdcc11          Use ISO C11 standard with SDCC extensions (default)
      --std-c2x             Use ISO C2X standard (incomplete)
      --std-sdcc2x          Use ISO C2X standard with SDCC extensions
      --fdollars-in-identifiers  Permit '$' as an identifier character
      --fsigned-char        Make "char" signed by default
      --use-non-free        Search / include non-free licensed libraries and header files

Code generation options:
  -m                        Set the port to use e.g. -mz80.
  -p                        Select port specific processor e.g. -mpic14 -p16f84
      --stack-auto          Stack automatic variables
      --xstack              Use external stack
      --int-long-reent      Use reentrant calls on the int and long support functions
      --float-reent         Use reentrant calls on the float support functions
      --xram-movc           Use movc instead of movx to read xram (xdata)
      --callee-saves        <func[,func,...]> Cause the called function to save registers instead of the caller
      --profile             On supported ports, generate extra profiling information
      --fomit-frame-pointer  Leave out the frame pointer.
      --all-callee-saves    callee will always save registers used
      --stack-probe         insert call to function __stack_probe at each function prologue
      --no-xinit-opt        don't memcpy initialized xram from code
      --no-c-code-in-asm    don't include c-code as comments in the asm file
      --no-peep-comments    don't include peephole optimizer comments
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment

Optimization options:
      --nooverlay           Disable overlaying leaf function auto variables
      --nogcse              Disable the GCSE optimisation
      --nolabelopt          Disable label optimisation
      --noinvariant         Disable optimisation of invariants
      --noinduction         Disable loop variable induction
      --noloopreverse       Disable the loop reverse optimisation
      --no-peep             Disable the peephole assembly file optimisation
      --no-reg-params       On some ports, disable passing some parameters in registers
      --peep-asm            Enable peephole optimization on inline assembly
      --peep-return         Enable peephole optimization for return instructions
      --no-peep-return      Disable peephole optimization for return instructions
      --peep-file           <file> use this extra peephole file
      --opt-code-speed      Optimize for code speed rather than size
      --opt-code-size       Optimize for code size rather than speed
      --max-allocs-per-node  Maximum number of register assignments considered at each node of the tree decomposition
      --nolospre            Disable lospre
      --allow-unsafe-read   Allow optimizations to read any memory location anytime
      --nostdlibcall        Disable optimization of calls to standard library

Internal debugging options:
      --dump-ast            Dump front-end AST before generating i-code
      --dump-i-code         Dump the i-code structure at all stages
      --dump-graphs         Dump graphs (control-flow, conflict, etc)
      --i-code-in-asm       Include i-code as comments in the asm file
      --fverbose-asm        Include code generator comments in the asm output

Linker options:
  -l                        Include the given library in the link
  -L                        Add the next field to the library search path
      --lib-path            <path> use this path to search for libraries
      --out-fmt-ihx         Output in Intel hex format
      --out-fmt-s19         Output in S19 hex format
      --xram-loc            <nnnn> External Ram start location
      --xram-size           <nnnn> External Ram size
      --iram-size           <nnnn> Internal Ram size
      --xstack-loc          <nnnn> External Stack start location
      --code-loc            <nnnn> Code Segment Location
      --code-size           <nnnn> Code Segment size
      --stack-loc           <nnnn> Stack pointer initial value
      --data-loc            <nnnn> Direct data start location
      --idata-loc
      --no-optsdcc-in-asm   Do not emit .optsdcc in asm

Special options for the mcs51 port:
      --model-small         internal data space is used (default)
      --model-medium        external paged data space is used
      --model-large         external data space is used
      --model-huge          functions are banked, data in external space
      --stack-size          Tells the linker to allocate this space for stack
      --parms-in-bank1      use Bank1 for parameter passing
      --pack-iram           Tells the linker to pack variables in internal ram (default)
      --no-pack-iram        Deprecated: Tells the linker not to pack variables in internal ram
      --acall-ajmp          Use acall/ajmp instead of lcall/ljmp
      --no-ret-without-call  Do not use ret independent of acall/lcall

Special options for the z80 port:
      --callee-saves-bc     Force a called function to always save BC
      --portmode=           Determine PORT I/O mode (z80/z180)
      --asm=                Define assembler name (rgbds/asxxxx/isas/z80asm)
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment
      --no-std-crt0         For the z80/gbz80 do not link default crt0.rel
      --reserve-regs-iy     Do not use IY (incompatible with --fomit-frame-pointer)
      --oldralloc           Use old register allocator
      --fno-omit-frame-pointer  Do not omit frame pointer
      --emit-externs        Emit externs list in generated asm

Special options for the z180 port:
      --callee-saves-bc     Force a called function to always save BC
      --portmode=           Determine PORT I/O mode (z80/z180)
      --asm=                Define assembler name (rgbds/asxxxx/isas/z80asm)
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment
      --no-std-crt0         For the z80/gbz80 do not link default crt0.rel
      --reserve-regs-iy     Do not use IY (incompatible with --fomit-frame-pointer)
      --oldralloc           Use old register allocator
      --fno-omit-frame-pointer  Do not omit frame pointer
      --emit-externs        Emit externs list in generated asm

Special options for the r2k port:
      --callee-saves-bc     Force a called function to always save BC
      --portmode=           Determine PORT I/O mode (z80/z180)
      --asm=                Define assembler name (rgbds/asxxxx/isas/z80asm)
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment
      --no-std-crt0         For the z80/gbz80 do not link default crt0.rel
      --reserve-regs-iy     Do not use IY (incompatible with --fomit-frame-pointer)
      --oldralloc           Use old register allocator
      --fno-omit-frame-pointer  Do not omit frame pointer
      --emit-externs        Emit externs list in generated asm

Special options for the r3ka port:
      --callee-saves-bc     Force a called function to always save BC
      --portmode=           Determine PORT I/O mode (z80/z180)
      --asm=                Define assembler name (rgbds/asxxxx/isas/z80asm)
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment
      --no-std-crt0         For the z80/gbz80 do not link default crt0.rel
      --reserve-regs-iy     Do not use IY (incompatible with --fomit-frame-pointer)
      --oldralloc           Use old register allocator
      --fno-omit-frame-pointer  Do not omit frame pointer
      --emit-externs        Emit externs list in generated asm

Special options for the gbz80 port:
      -bo                   <num> use code bank <num>
      -ba                   <num> use data bank <num>
      --callee-saves-bc     Force a called function to always save BC
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment
      --no-std-crt0         For the z80/gbz80 do not link default crt0.rel

Special options for the tlcs90 port:
      --callee-saves-bc     Force a called function to always save BC
      --portmode=           Determine PORT I/O mode (z80/z180)
      --asm=                Define assembler name (rgbds/asxxxx/isas/z80asm)
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment
      --no-std-crt0         For the z80/gbz80 do not link default crt0.rel
      --reserve-regs-iy     Do not use IY (incompatible with --fomit-frame-pointer)
      --oldralloc           Use old register allocator
      --fno-omit-frame-pointer  Do not omit frame pointer
      --emit-externs        Emit externs list in generated asm

Special options for the ez80_z80 port:
      --callee-saves-bc     Force a called function to always save BC
      --portmode=           Determine PORT I/O mode (z80/z180)
      --asm=                Define assembler name (rgbds/asxxxx/isas/z80asm)
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --dataseg             <name> use this name for the data segment
      --no-std-crt0         For the z80/gbz80 do not link default crt0.rel
      --reserve-regs-iy     Do not use IY (incompatible with --fomit-frame-pointer)
      --oldralloc           Use old register allocator
      --fno-omit-frame-pointer  Do not omit frame pointer
      --emit-externs        Emit externs list in generated asm

Special options for the ds390 port:
      --model-flat24        use the flat24 model for the ds390 (default)
      --stack-8bit          use the 8bit stack for the ds390 (not supported yet)
      --stack-size          Tells the linker to allocate this space for stack
      --pack-iram           Tells the linker to pack variables in internal ram (default)
      --no-pack-iram        Deprecated: Tells the linker not to pack variables in internal ram
      --stack-10bit         use the 10bit stack for ds390 (default)
      --use-accelerator     generate code for ds390 arithmetic accelerator
      --protect-sp-update   will disable interrupts during ESP:SP updates
      --parms-in-bank1      use Bank1 for parameter passing

Special options for the pic16 port:
      --pstack-model=       use stack model 'small' (default) or 'large'
  -y  --extended            enable Extended Instruction Set/Literal Offset Addressing mode
      --pno-banksel         do not generate BANKSEL assembler directives
      --obanksel=           set banksel optimization level (default=0 no)
      --denable-peeps       explicit enable of peepholes
      --no-optimize-goto    do NOT use (conditional) BRA instead of GOTO
      --optimize-cmp        try to optimize some compares
      --optimize-df         thoroughly analyze data flow (memory and time intensive!)
      --asm=                Use alternative assembler
      --mplab-comp          enable compatibility mode for MPLAB utilities (MPASM/MPLINK)
      --link=               Use alternative linker
      --preplace-udata-with=  Place udata variables at another section: udata_acs, udata_ovr, udata_shr
      --ivt-loc=            Set address of interrupt vector table.
      --nodefaultlibs       do not link default libraries when linking
      --use-crt=            use <crt-o> run-time initialization module
      --no-crt              do not link any default run-time initialization module
      --debug-xtra          show more debug info in assembly output
      --debug-ralloc        dump register allocator debug file *.d
      --pcode-verbose       dump pcode related info
      --calltree            dump call tree in .calltree file
      --gstack              trace stack pointer push/pop to overflow
      --no-warn-non-free    suppress warning on absent --use-non-free option

Special options for the pic14 port:
      --debug-xtra          show more debug info in assembly output
      --no-pcode-opt        disable (slightly faulty) optimization on pCode
      --stack-size          sets the size if the argument passing stack (default: 16, minimum: 4)
      --no-extended-instructions  forbid use of the extended instruction set (e.g., ADDFSR)
      --no-warn-non-free    suppress warning on absent --use-non-free option

Special options for the TININative port:
      --model-flat24        use the flat24 model for the ds390 (default)
      --stack-8bit          use the 8bit stack for the ds390 (not supported yet)
      --stack-size          Tells the linker to allocate this space for stack
      --pack-iram           Tells the linker to pack variables in internal ram (default)
      --no-pack-iram        Deprecated: Tells the linker not to pack variables in internal ram
      --stack-10bit         use the 10bit stack for ds390 (default)
      --use-accelerator     generate code for ds390 arithmetic accelerator
      --protect-sp-update   will disable interrupts during ESP:SP updates
      --parms-in-bank1      use Bank1 for parameter passing
      --tini-libid          <nnnn> LibraryID used in -mTININative

Special options for the ds400 port:
      --model-flat24        use the flat24 model for the ds400 (default)
      --stack-8bit          use the 8bit stack for the ds400 (not supported yet)
      --stack-size          Tells the linker to allocate this space for stack
      --pack-iram           Tells the linker to pack variables in internal ram (default)
      --no-pack-iram        Deprecated: Tells the linker not to pack variables in internal ram
      --stack-10bit         use the 10bit stack for ds400 (default)
      --use-accelerator     generate code for ds400 arithmetic accelerator
      --protect-sp-update   will disable interrupts during ESP:SP updates
      --parms-in-bank1      use Bank1 for parameter passing

Special options for the hc08 port:
      --model-small         8-bit address space for data
      --model-large         16-bit address space for data (default)
      --out-fmt-elf         Output executable in ELF format
      --oldralloc           Use old register allocator

Special options for the s08 port:
      --model-small         8-bit address space for data
      --model-large         16-bit address space for data (default)
      --out-fmt-elf         Output executable in ELF format
      --oldralloc           Use old register allocator

Special options for the stm8 port:
      --model-medium        16-bit address space for both data and code (default)
      --model-large         16-bit address space for data, 24-bit for code
      --codeseg             <name> use this name for the code segment
      --constseg            <name> use this name for the const segment
      --out-fmt-elf         Output executable in ELF format


ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline oPossum

  • Super Contributor
  • ***
  • Posts: 1413
  • Country: us
  • Very dangerous - may attack at any time
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #599 on: July 24, 2019, 01:14:42 pm »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf