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

0 Members and 2 Guests are viewing this topic.

Offline ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: ir
    • ASiD Designer
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #625 on: August 31, 2019, 05:17:29 am »
Quote
Because some people have trouble compiling on/for Windows, I added automatic builds (using travis-ci) to the freepdk github repository.

Every commit will now build the software for all 3 platforms (Linux/Mac/Windows) and check for errors.

Tags will automatically create ZIP files with the compiled binaries for all 3 platforms, available under "releases".

I created a temporary tag "1.1-development" from development branch. Here you can find the 1.1-development (work in progress) binaries for all 3 platforms:
https://github.com/free-pdk/easy-pdk-programmer-software/releases

Have fun,

JS

Thanks JS :-+ :-+
You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 29947
  • Country: au
    • EEVblog
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #626 on: August 31, 2019, 06:23:05 am »
Quote
open source hardware programmer: https://github.com/free-pdk/easy-pdk-programmer-hardware

I have checked it, it has only the hardware files, where is the software files for the STM32 MCU and also the PC side software

I just tried to get this board made and it's in a 4x1 panel format, but only one of the boards is populated. Kinda annoying, can this be updated to just be a single non-panelised PCB?
Looks like no original PCB file available?
I don't want to edit the gerber files so I'll just get the panel made as is for testing.

Yep, JLC rejected my PCB, Can I get a single PCB gerber files or the original PCB file please? (KiCAD/Eagle/Altium?) Thanks.
 

Offline HwAoRrDk

  • Frequent Contributor
  • **
  • Posts: 632
  • Country: gb
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #627 on: August 31, 2019, 06:44:20 am »
Dave, you can find the EasyEDA project here:

https://easyeda.com/tenbaht/schematic

If you open up the PCB layout, looks like you can either edit the panel down to a single PCB and export Gerbers, or export to Altium (folder icon top-left, 'Export', 'Altium') and do it there.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #628 on: August 31, 2019, 06:53:54 am »
Hi,

I just tried to get this board made and it's in a 4x1 panel format, but only one of the boards is populated. Kinda annoying, can this be updated to just be a single non-panelised PCB?

According to EasyEDA documentation this is the modern way to create a panel: https://docs.easyeda.com/en/PCB/Panelize/index.html
"the panelized file only panelize the board outline. ... Normally, all the PCB factory will support this panelized file, if you not sure, you need to contact your PCB factory support."

The exact same Gerber ZIP file you found was used to produce the 4x1 panel using JLCPCB.com. You can order 5 panels for USD$2 there.

Looks like no original PCB file available?
In case you want to modify the design you can find the complete source schematics/pcb design files in the github repository (look in easyeda folder)


BTW: EasyEDA was used since it is a complete free, easy to use, no installation required PCB editor (very nice for open source projects). It also combines very nice with JLCPCB.com and LCSC.com (right now they are the most affordable source for PCBs and components, which is also a big win for the open source project).


Have fun,

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

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #629 on: August 31, 2019, 07:10:24 am »
Yep, JLC rejected my PCB, Can I get a single PCB gerber files or the original PCB file please? (KiCAD/Eagle/Altium?) Thanks.

This is very odd. Several users used the exact same gerber.zip file to order from JLCPCB before and it was accepted.
What was the exact reason for the rejection?

In the mean time I will create a non panelaized Gerber and put it to the github project page.

Edit: https://github.com/free-pdk/easy-pdk-programmer-hardware/tree/master/pcb also contains a single board gerber now: "Gerber_EASYPDKPROG_PCB12_NoSilk.zip"

JS
« Last Edit: August 31, 2019, 07:15:51 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 29947
  • Country: au
    • EEVblog
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #630 on: August 31, 2019, 07:19:52 am »
Yep, JLC rejected my PCB, Can I get a single PCB gerber files or the original PCB file please? (KiCAD/Eagle/Altium?) Thanks.

This is very odd. Several users used the exact same gerber.zip file to order from JLCPCB before and it was accepted.
What was the exact reason for the rejection?

It's because the gerber looks like a panel with V score, and they said:
Quote
Sorry to tell you that the size of your panel is too small to be made with v-cut, it needs to 7 *7 cm at least to get through the v-cut machine, could you please kindly check? And you can add edge rail to the the boards as the attachment ,then it can be produced by V-cut ,thank you !



Quote
In the mean time I will create a non panelaized Gerber and put it to the github project page.
Edit: https://github.com/free-pdk/easy-pdk-programmer-hardware/tree/master/pcb also contains a single board gerber now: "Gerber_EASYPDKPROG_PCB12_NoSilk.zip"

Thanks!
Looks good this time:

« Last Edit: August 31, 2019, 07:21:44 am by EEVblog »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #631 on: August 31, 2019, 07:25:54 am »
It's because the gerber looks like a panel with V score, and they said:
Quote
Sorry to tell you that the size of your panel is too small to be made with v-cut, it needs to 7 *7 cm at least to get through the v-cut machine, could you please kindly check? And you can add edge rail to the the boards as the attachment ,then it can be produced by V-cut ,thank you !

Thanks for the feedback. It looks like JLCPCB changed the rules recently (New: v-cut panel must be >= 7x7cm now) . A week ago I ordered some other PCBs and my panel was much smaller.

JS

Edit: I updated the panel version to have the rails on the side so the resulting panel matches the new "panel >= 7x7cm" rule.
« Last Edit: August 31, 2019, 07:32:02 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: ir
    • ASiD Designer
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #632 on: August 31, 2019, 08:10:54 am »
Dave you can check out my Altium project!

JS, I have compiled the ARM program and flashed the easyPaduk, but unfortunately it says the firmware is a mismatch! (I have flashed the programmer with the new Bin file) also can you please update the make file for the PC side software to generate the .exe file for windows too( I mean inside ubuntu)

You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #633 on: August 31, 2019, 08:11:31 am »
I ordered directly out of easyeda about three weeks ago and had no issue at all.
Got 5 pcbs from JLPCB.

One thing I noticed: I would suggest changing all the text to silk screen. It's quite hard to read on a blue pcb.
 

Online EEVblog

  • Administrator
  • *****
  • Posts: 29947
  • Country: au
    • EEVblog
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #634 on: August 31, 2019, 08:17:14 am »
Dave you can check out my Altium project!

IIRC you didn't get it working or had some issue with it?
I went with JS's gebers for now because it's been reported working, I just want to get it up and running for a video with the least fuss.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #635 on: August 31, 2019, 08:45:57 am »
Hi,

JS, I have compiled the ARM program and flashed the easyPaduk, but unfortunately it says the firmware is a mismatch! (I have flashed the programmer with the new Bin file)

Can it be that you compiled the firmware from master branch? The development version also needs the firmware from development branch. There is a pre compiled "EASYPDKPROG.dfu" in the firmware directory of development branch. I just checked and it works 100% correct.
DEVELOPMENT FIRMWARE FOR DEVELOPMENT EASYPDKPROG: https://github.com/free-pdk/easy-pdk-programmer-software/tree/development/Firmware

also can you please update the make file for the PC side software to generate the .exe file for windows too( I mean inside ubuntu)

The same makefile is used also for cross compiling. You need to set the correct environment variables in order to use Ubuntu to cross compile for windows.
You can have a look in the .travis files in the development branch. All settings are there. On Ubuntu, at minimum, you have to install the mingw package, and set the following environment variables:

Install:
sudo apt install gcc-mingw-w64-i686

Compile:
export OSTYPE=msys
export host_alias=i686-w64-mingw32
export CC=i686-w64-mingw32-gcc
export STRIP=i686-w64-mingw32-strip

make

mv easypdkprog easypdkprog.exe


A more easy way to compile for Windows is to install "MSYS2" on Windows and use the MinGW shell.

JS
« Last Edit: August 31, 2019, 08:47:54 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: ir
    • ASiD Designer
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #636 on: August 31, 2019, 10:54:09 am »
Thanks JS, I managed to flash the Dev branch to the ARM and now it's working, But still only probing is working |O |O |O any Idea what might goes wrong?

You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #637 on: August 31, 2019, 12:54:21 pm »
Thanks JS, I managed to flash the Dev branch to the ARM and now it's working, But still only probing is working |O |O |O any Idea what might goes wrong?

Now you have to check your hardware variant. On the picture I saw that C1 is not populated and also Y1 is missing. A cap on the 15V rail is essential since VCC/VDD draw some power during programing. The crystal is used to get better tuning results after the CPU is flashed, without it the drift might be much higher or you create a very special clock path using the HSI48 with sync to USB frames (then programmer can not be used stand alone - a feature planned for future use, just like WRITER).

Also, since you changed the opamp, it might be possible that the output voltages differ. You can use the "easypdkprogtest" program to check that the output voltage is correct:

DO THIS WITHOUT A MCU CONNECTED TO THE PROGRAMMER

make easypdkprogtest

./easypdkprogtest
vdd: 5.01   vpp: 4.98    (vref= 3.30)


Please check that VDD and VPP are 5V and VREF is 3.3V. Also measure them on your PCB.

In case VDD and VPP voltages are incorrect you need to tune the DAC reference values for your specific hardware (in fpdk.c you need to change FPDK_VDD_DAC_MAX_MV / FPDK_VPP_DAC_MAX_MV).


JS
« Last Edit: August 31, 2019, 12:56:01 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #638 on: August 31, 2019, 02:24:47 pm »
FYI, I just finished my own built of the easypdk programmer. I built up two PCBs and they both work without a hitch, even though i manually soidered... Very good job, js!

There was one bizarre isseue with MSYS when compiling the command line tool. I had to change the line "CC ?= GCC" in the makefile to "CC = GCC". Not sure what is going on, because i know that the ?= directive works in other makefiles i use.

I still have PCBs and components for three more programmers left. If somebody in Germany is interested, I would donate them.

Building up the PCB was not that easy. Too many small components. To allows easier access for other people it may be helpful to have a version with fewer components or identify an option of having the pcb populated by some company.

« Last Edit: August 31, 2019, 02:53:04 pm by tim_ »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #639 on: August 31, 2019, 06:28: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
...

I fully agree with this approach. I wonder, has anybody already been looking into this? Right now, I am cleaning up some of my old examples.
« Last Edit: August 31, 2019, 06:48:32 pm by tim_ »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #640 on: August 31, 2019, 07:01:07 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
...

I fully agree with this approach. I wonder, has anybody already been looking into this? Right now, I am cleaning up some of my old examples. So far I have defined everything in line.

I'm working on it. Right now I work on a PMS150C based project and created a full include file for it. Right now I wait for PCB delivery. As soon as it's done I will put the project online.
Fixing the PDK13 bit SDCC compiler was one of the time consuming tasks, but now it seems to be very stable (same as for PDK14/PDK15).

JS

work in progress:

pms150c.h
Code: [Select]
#ifndef __PMS150C_H__
 #define __PMS150C_H__

 #include "pdkcommon.h"

//set calibration macros
 #define EASY_PDK_CALIBRATE_IHRC EASY_PDK_CALIBRATE_IHRC_H8
 #define EASY_PDK_CALIBRATE_ILRC EASY_PDK_CALIBRATE_IHRC_L8

//IO register definitions
//__sfr __at(0x00) _flag;
//0x01
//__sfr __at(0x02) _sp;
__sfr __at(0x03) _clkmd;
__sfr __at(0x04) _inten;
__sfr __at(0x05) _intrq;
__sfr __at(0x06) _t16m;
//0x07
//0x08
__sfr __at(0x09) _tm2b;
__sfr __at(0x0a) _eoscr;
__sfr __at(0x0b) _ihrcr;
__sfr __at(0x0c) _integs;
__sfr __at(0x0d) _padier;
//0x0e
//0x0f
__sfr __at(0x10) _pa;
__sfr __at(0x11) _pac;
__sfr __at(0x12) _paph;
//0x13
//0x14
//0x15
//0x16
__sfr __at(0x17) _tm2s;
//0x18
__sfr __at(0x19) _bgtr;
__sfr __at(0x1a) _gpcc;
__sfr __at(0x1b) _misc;
__sfr __at(0x1c) _tm2c;
__sfr __at(0x1d) _tm2ct;
__sfr __at(0x1e) _gpcs;
__sfr __at(0x1f) _ilrcr;

//T16C register
__sfr16          _t16c;

//clkmd definitions
 #define CLKMD_ENABLE_PA5RST          0x01
 #define CLKMD_ENABLE_WATCHDOG        0x02
 #define CLKMD_ENABLE_ILRC            0x04
 #define CLKMD_ENABLE_IHRC            0x10
 #define CLKMD_IHRC_DIV2              0x20
 #define CLKMD_IHRC_DIV4              0x00
 #define CLKMD_IHRC_DIV8              0x28
 #define CLKMD_IHRC_DIV16             0x08
 #define CLKMD_IHRC_DIV32             0x68
 #define CLKMD_IHRC_DIV64             0x88
 #define CLKMD_ILRC                   0xe0
 #define CLKMD_ILRC_DIV4              0xc0

//interrupt enable definitions
 #define INTEN_PA0                    0x01
 #define INTEN_T16                    0x04
 #define INTEN_COMP                   0x10
 #define INTEN_TM2                    0x40

//interrupt request definitions
 #define INTRQ_PA0                    0x01
 #define INTRQ_T16                    0x04
 #define INTRQ_COMP                   0x10
 #define INTRQ_TM2                    0x40

//tm16 definitions
 #define T16_INTSRC_8BIT              0x00
 #define T16_INTSRC_9BIT              0x01
 #define T16_INTSRC_10BIT             0x02
 #define T16_INTSRC_11BIT             0x03
 #define T16_INTSRC_12BIT             0x04
 #define T16_INTSRC_13BIT             0x05
 #define T16_INTSRC_14BIT             0x06
 #define T16_INTSRC_15BIT             0x07
 #define T16_CLK_DIV1                 0x00
 #define T16_CLK_DIV4                 0x08
 #define T16_CLK_DIV16                0x10
 #define T16_CLK_DIV64                0x18
 #define T16_CLK_DISABLE              0x00
 #define T16_CLK_SYSCLK               0x20
 #define T16_CLK_PA4_FALL             0x60
 #define T16_CLK_IHRC                 0x80
 #define T16_CLK_ILRC                 0xC0
 #define T16_CLK_PA0_FALL             0xE0

//eosc definitions
 #define EOSC_LVD_BANDGAP_SHUTDOWN    0x01

//integs definitions
 #define INTEGS_PA0_BOTH              0x00
 #define INTEGS_PA0_RISING            0x01
 #define INTEGS_PA0_FALLING           0x02
 #define INTEGS_T16_RISING            0x00
 #define INTEGS_T16_FALLING           0x04
 #define INTEGS_COMP_BOTH             0x00
 #define INTEGS_COMP_RISING           0x40
 #define INTEGS_COMP_FALLING          0x80

//padie definitions
 #define PADIE_PA0_WAKEUP_ENABLE      0x01
 #define PADIE_PA3_WAKEUP_ENABLE      0x08
 #define PADIE_PA4_WAKEUP_ENABLE      0x10
 #define PADIE_PA5_WAKEUP_ENABLE      0x20
 #define PADIE_PA6_WAKEUP_ENABLE      0x40
 #define PADIE_PA7_WAKEUP_ENABLE      0x80

//misc definitions
 #define MISC_WATCHDOG_8K_ILRC        0x00
 #define MISC_WATCHDOG_16K_ILRC       0x01
 #define MISC_WATCHDOG_64K_ILRC       0x02
 #define MISC_WATCHDOG_256K_ILRC      0x03
 #define MISC_LVR_DISABLE             0x04
 #define MISC_FAST_WAKEUP_ENABLE      0x20

//tm2c definitions
 #define TM2C_CLK_DISABLE             0x00
 #define TM2C_CLK_SYSCLK              0x10
 #define TM2C_CLK_IHRC                0x20
 #define TM2C_CLK_EOSC                0x30
 #define TM2C_CLK_ILRC                0x40
 #define TM2C_CLK_COMPOUT             0x50
 #define TM2C_CLK_PA0_RISE            0x80
 #define TM2C_CLK_PA0_FALL            0x90
 #define TM2C_CLK_PB0_RISE            0xA0
 #define TM2C_CLK_PB0_FALL            0xB0
 #define TM2C_CLK_PA4_RISE            0xC0
 #define TM2C_CLK_PA4_FALL            0xD0
 #define TM2C_OUT_DISABLE             0x00
 #define TM2C_OUT_PB2                 0x04
 #define TM2C_OUT_PA3                 0x08
 #define TM2C_OUT_PB4                 0x0C
 #define TM2C_MODE_PERIOD             0x00
 #define TM2C_MODE_PWM                0x02
 #define TM2C_INVERT_OUT              0x01

//tm2s definitions
 #define TM2S_PWM_RES_8BIT            0x00
 #define TM2S_PWM_RES_6BIT            0x80
 #define TM2S_PRESCALE_NONE           0x00
 #define TM2S_PRESCALE_DIV4           0x20
 #define TM2S_PRESCALE_DIV16          0x40
 #define TM2S_PRESCALE_DIV64          0x60

//gpcc definitions
 #define GPCC_COMP_PLUS_VINT          0x00
 #define GPCC_COMP_PLUS_PA4           0x01
 #define GPCC_COMP_MINUS_PA3          0x00
 #define GPCC_COMP_MINUS_PA4          0x02
 #define GPCC_COMP_MINUS_BANDGAP_1V2  0x04
 #define GPCC_COMP_MINUS_VINT_R       0x06
 #define GPCC_COMP_MINUS_PA6          0x08
 #define GPCC_COMP_MINUS_PA7          0x0A

//gpcs definitions
 #define GPCS_COMP_CASE1              0x00
 #define GPCS_COMP_CASE2              0x10
 #define GPCS_COMP_CASE3              0x20
 #define GPCS_COMP_CASE4              0x30
 #define GPCS_COMP_WAKEUP_ENABLE      0x40
 #define GPCS_COMP_OUTPUT_PA0         0x80

 //__PMS150C_H__


pdkcommon.h
Code: [Select]
#ifndef __PDKCOMMON_H__
 #define __PDKCOMMON_H__

//macros so we can use defines in assembler strings
 #define _STRINGIFY(x)
 #define _ASMV(x) "_"_STRINGIFY(x)
 #define _ASMD(x) _STRINGIFY(x)

//definitions for built in opcodess
 #define __engint()  __asm__("engint\n")
 #define __disgint() __asm__("disgint\n")
 #define __stopsys() __asm__("stopsys\n")
 #define __stopexe() __asm__("stopexe\nnop\n")
 #define __set0(x,y)  __asm__("set0 "_ASMV(x)", #"_ASMD(y)"\n")
 #define __set1(x,y)  __asm__("set1 "_ASMV(x)", #"_ASMD(y)"\n")

//macros for clock setup
 #define EASY_PDK_INIT_SYSCLOCK_8MHZ()   {_clkmd=CLKMD_ENABLE_ILRC|CLKMD_ENABLE_IHRC|CLKMD_IHRC_DIV2;}
 #define EASY_PDK_INIT_SYSCLOCK_4MHZ()   {_clkmd=CLKMD_ENABLE_ILRC|CLKMD_ENABLE_IHRC|CLKMD_IHRC_DIV4;}
 #define EASY_PDK_INIT_SYSCLOCK_2MHZ()   {_clkmd=CLKMD_ENABLE_ILRC|CLKMD_ENABLE_IHRC|CLKMD_IHRC_DIV8;}
 #define EASY_PDK_INIT_SYSCLOCK_1MHZ()   {_clkmd=CLKMD_ENABLE_ILRC|CLKMD_ENABLE_IHRC|CLKMD_IHRC_DIV16;}
 #define EASY_PDK_INIT_SYSCLOCK_512kHz() {_clkmd=CLKMD_ENABLE_ILRC|CLKMD_ENABLE_IHRC|CLKMD_IHRC_DIV32;}

//place holder for EASYPDK serial inserted from easypdkprog
 #define EASY_PDK_SERIAL(sname) static const uint8_t sname[8] = {'F','P','S','E','R','I','A','L'}

//place holder for EASYPDK calibrations executed / replaced by easypdkprog
 #define EASY_PDK_CALIBRATE_IHRC_H8(frequency,millivolt) \
__asm__(                      \
  "and a, #'H'                \n"\
  "and a, #'8'                \n"\
  "and a, #("#frequency")     \n"\
  "and a, #("#frequency">>8)  \n"\
  "and a, #("#frequency">>16) \n"\
  "and a, #("#frequency">>24) \n"\
  "and a, #("#millivolt")     \n"\
  "and a, #("#millivolt">>8)  \n"\
)

 #define EASY_PDK_CALIBRATE_ILRC_L8(frequency,millivolt) \
__asm__(                      \
  "and a, #'L'                \n"\
  "and a, #'8'                \n"\
  "and a, #("#frequency")     \n"\
  "and a, #("#frequency">>8)  \n"\
  "and a, #("#frequency">>16) \n"\
  "and a, #("#frequency">>24) \n"\
  "and a, #("#millivolt")     \n"\
  "and a, #("#millivolt">>8)  \n"\
)
 #define EASY_PDK_CALIBRATE_IHRC_H9(frequency,millivolt) \
__asm__(                      \
  "and a, #'H'                \n"\
  "and a, #'9'                \n"\
  "and a, #("#frequency")     \n"\
  "and a, #("#frequency">>8)  \n"\
  "and a, #("#frequency">>16) \n"\
  "and a, #("#frequency">>24) \n"\
  "and a, #("#millivolt")     \n"\
  "and a, #("#millivolt">>8)  \n"\
  "and a, #0                  \n"\
)

 #define EASY_PDK_CALIBRATE_ILRC_L9(frequency,millivolt) \
__asm__(                      \
  "and a, #'L'                \n"\
  "and a, #'9'                \n"\
  "and a, #("#frequency")     \n"\
  "and a, #("#frequency">>8)  \n"\
  "and a, #("#frequency">>16) \n"\
  "and a, #("#frequency">>24) \n"\
  "and a, #("#millivolt")     \n"\
  "and a, #("#millivolt">>8)  \n"\
  "and a, #0                  \n"\
)

 //__PDKCOMMON_H__


example main.c
Code: [Select]
#include <stdint.h>
 #include "pms150c.h"

unsigned char _sdcc_external_startup(void)
{
  EASY_PDK_INIT_SYSCLOCK_8MHZ();              //use 8MHz to save power
  EASY_PDK_CALIBRATE_IHRC(8000000,3300);      //tune SYSCLK to 8.0MHz @ 3.300V
  return 0;                                   //perform normal initialization
}

void main(void)
{
  for(;;)
  {
     //YOUR CODE HERE
  }
}

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

Offline ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: ir
    • ASiD Designer
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #641 on: September 01, 2019, 06:07:39 am »
Dear JS
Thanks for help and support,
I could not compile the code on ubuntu with the commands that you said! :-X :-X :-X

But I managed to install MSYS2 on my machine and finally it could compile the code, But there is something very weird! the code just does not run |O |O |O also I could compile the easypdkprogtest program too, but It can not run either!

See these pictures? what's going on wrong? the size of easypdkprog.exe that is compiled on my machine with MSYS2 is 55.5KB,but your compiled version is about 79KB

The MSYS2 compile output


when I run the code, it just hangs and do nothing, so I should close it with ctrl + C


Also when I try to run it from command prompt it says some missing MSYS2 DLL |O

You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #642 on: September 01, 2019, 06:37:25 am »
Well, did you try to locate msys2.dll? It appears that you are trying to execute easypdkprog by starting it from the explorer. Try starting it from the MSYS shell. Only then the proper path is set.

Btw - i used mingw32/msys1 to compile the exe and had no issues. I had problems with mingw64 in the past.

Why don't you use the binaries provided by js? They work well.
« Last Edit: September 01, 2019, 07:20:48 am by tim_ »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #643 on: September 01, 2019, 07:57:25 am »
But I managed to install MSYS2 on my machine and finally it could compile the code, But there is something very weird! the code just does not run |O |O |O also I could compile the easypdkprogtest program too, but It can not run either!

I said you should use the MinGW shell (from MSYS2) to compile (look in your start menu, the MSYS2 installer has created MSys2 Shell and MinGW Shell shortcuts).

Your MSYS2 compile looks fine and it also will work. You only need to use it in standard Windows CMD-Prompt (you can not run it from MSys2 Shell). You also need to copy the MSYS-2.0.DLL to the same directory as easypdkprog.exe (or to Windows system directory).

In case you use MinGW shell the resulting exe file will be smaller and there will be no dependency to any DLL which is not already present on a standard Windows installation (That's why I still prefer MinGW for compiling).


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

Offline ali_asadzadeh

  • Frequent Contributor
  • **
  • Posts: 896
  • Country: ir
    • ASiD Designer
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #644 on: September 01, 2019, 08:29:56 am »
Thanks JS, Now the program would run from the MSYS2 shell, The voltages are a bit high


They are 5.17v and 5.18v with my voltmeter, are they in expected range?how should I calculate the offset and change.
You can order parts from www.ASiDesigner.com
we are a wire-based company
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #645 on: September 01, 2019, 09:39:17 am »
Thanks JS, Now the program would run from the MSYS2 shell, The voltages are a bit high
They are 5.17v and 5.18v with my voltmeter, are they in expected range?how should I calculate the offset and change.

The voltages look indeed a bit high, which most likely cause the problems you have.

ADC is working good since it detected the voltage to be 5.16V (you measured 5.17V/5.18V) => Maybe I will add a self calibration later.

For you now the easiest way is to do the following:

1. change source code of easypdkprogtest.c  and put 2 times "100.0" instead of "5.0" as requested output voltage (Don't worry, it can output max 15V):

  //be carefully, remove IC from programmer!
  FPDKCOM_SetOutputVoltages(comfd, 100.0, 100.0);


compile and run it, then write down the reported voltages:

./easypdkprogtest
vdd: 6.29   vpp: 13.30    (vref= 3.30)   


This are the maximum voltages the hardware can produce (for standard easypdk programmer):
VDD: 6.29 V = 6290 mV
VPP: 13.30 V = 13300 mV

2. go to firmware source, file "fpdk.c" an change the values of the DAC reference voltage:

//board specific max values (DAC max => mV max after opamp output / -30 mV DAC DC offset)
 #define FPDK_VDD_DAC_MAX_MV ( 6290 - 30)
 #define FPDK_VPP_DAC_MAX_MV (13300 - 30)


3. compile and flash firmware

4. change back easypdkprogtest to 2 times 5.0V and check output

It should now report 5.0V for VDD and VPP.


Have fun,

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

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #646 on: September 01, 2019, 07:52:30 pm »
I spent some time tinkering with a toolchain setup for SDCC and easypdkprog. You can find my work in progress here:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain

Notable findings:

Includes
- I wrote a small python script that automatically generates include files from the CSV that JS posted a while ago. This should greatly reduce the work of creating include files for all MCUS. you can find it at
https://github.com/cpldcpu/SimPad/tree/master/Toolchain/util
- The goal is currently to have one master "io.h" file that automatically includes the architecture specific files.
- The architecture specific includes contain information about i/o register locations. The descriptions of the individual bits seem to be universial for all devices and have therefore been moved into a common file.
- I also introduced F_CPU to allow for a proper delay function.

Makefile
- Unversial makefile added, based on STM8-bare-min. Everything is automated now.

SDCC
- I was pleasantly surprised to learn that SDCC can infer SET0/SET1 now. Therefore it is not necessary to introduce specific macros for set0/set1
- Since SDCC implements a very unusual way of defining SFRs, intellisense/vscode is not able to identify the register definitions. This is somewhat unfortunate. There is an open ticked about this at the vscode github since last year, but apparently it is not a priority. Is there any workaround? Doing it like AVR-GCC ("__sfr(register)") would allow using defines, which is more compatible to intellisense.
- It does not seem to be possible to use local labels in inline assembler? This is inconvenient because it does not allow inlining of functions with assembler code when they use labels...
- It appears the -p options is not yet supported for the PDK architecture? This would be very useful, because it would allow distinguishing different processors from the makefile. May use a define as a workaround for now...

Easypdkprog
 does not write the last byte of the ihx for some reason. This is only noticable when linking several files. Already submitted an issue.

I will add more examples soon. Also planning to integrates JS autocalibration code.

Let me know what you think. There are still many things to be clarified regarding naming etc.
« Last Edit: September 01, 2019, 08:09:46 pm by tim_ »
 
The following users thanked this post: icraftcrafts

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #647 on: September 01, 2019, 10:59:03 pm »
So I have mostly given up on getting the programmer running on the ATtiny - it's just not capable of doing so much realtime stuff at once - either you break USB, or you break the SMPS regulation, you can't have both at once.

Therefore, I have switched to plan B - using an Arduino as development platform instead. And it turns out this is probably the way I should have chosen from the start.

While certainly not the most professional-looking alternative, it sure is the easiest to build. It uses as little components as possible.

The schematic is attached, and the firmware along with upload scripts can be found in https://github.com/socram8888/ArduinoPDKProgrammer. This already supports uploading and verifying IHX files, as those generated by SDCC.
 
The following users thanked this post: edavid, icraftcrafts, tim_

Offline socram

  • Regular Contributor
  • *
  • Posts: 63
  • Country: es
    • Totodile!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #648 on: September 01, 2019, 11:23:53 pm »
@tim_: I have used your blinkyasm example for testing my programmer. However, while the LED turns ON, it never turns back off. I've tried commenting out the wait busy loop and I can see now with the scope the GPIO toggling. Could you tell me if the IHX file you are getting for that matches mine?

Code: [Select]
:20000000022F8201782F8301012F9101101E101C0630FF2F820B830B82110C3083110C30C7
:020020007A0064
:00000001FF

I have just compiled it using the SDCC snapshot for today (1st September 2019), so I am not sure if the compilation is broken.

My other guessing is that the SRAM is bad in this chip (hence the DCSN never reaches zero to leave). Has anybody else experienced something like this in its Padauk IC, where the CPU is indeed working but the SRAM is dead?
 
The following users thanked this post: icraftcrafts

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 188
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #649 on: September 02, 2019, 05:53:29 am »
I spent some time tinkering with a toolchain setup for SDCC and easypdkprog. You can find my work in progress here:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain

Notable findings:

Includes
- I wrote a small python script that automatically generates include files from the CSV that JS posted a while ago. This should greatly reduce the work of creating include files for all MCUS. you can find it at
https://github.com/cpldcpu/SimPad/tree/master/Toolchain/util
- The goal is currently to have one master "io.h" file that automatically includes the architecture specific files.
- The architecture specific includes contain information about i/o register locations. The descriptions of the individual bits seem to be universial for all devices and have therefore been moved into a common file.
- I also introduced F_CPU to allow for a proper delay function.

Makefile
- Unversial makefile added, based on STM8-bare-min. Everything is automated now.

SDCC
- I was pleasantly surprised to learn that SDCC can infer SET0/SET1 now. Therefore it is not necessary to introduce specific macros for set0/set1
- Since SDCC implements a very unusual way of defining SFRs, intellisense/vscode is not able to identify the register definitions. This is somewhat unfortunate. There is an open ticked about this at the vscode github since last year, but apparently it is not a priority. Is there any workaround? Doing it like AVR-GCC ("__sfr(register)") would allow using defines, which is more compatible to intellisense.
- It does not seem to be possible to use local labels in inline assembler? This is inconvenient because it does not allow inlining of functions with assembler code when they use labels...
- It appears the -p options is not yet supported for the PDK architecture? This would be very useful, because it would allow distinguishing different processors from the makefile. May use a define as a workaround for now...

Easypdkprog
 does not write the last byte of the ihx for some reason. This is only noticable when linking several files. Already submitted an issue.

I will add more examples soon. Also planning to integrates JS autocalibration code.

Let me know what you think. There are still many things to be clarified regarding naming etc.

I think auto generating the IO header files is not the way to go.
The most work was to add all the bit definitions for the specific IO registers (see "pms150.h" from above).
This is needed to do simple things like: _clkmd=CLKMD_ENABLE_ILRC | CLKMD_ENABLE_IHRC | CLKMD_IHRC_DIV2;

Also since SDCC defines "_sp" and "_flags" internally I think we should keep the "_" prefix for all other registers as well

I also created a Makefile similar to yours. I will release it with the project as soon as the PCBs arrived and I testes everything

The last byte missing problem from easypdkprog seems odd and it does not happen to me. Maybe programming the last byte was not working on your hardware and some tweaking of the code is required to make this more reliable.

JS

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


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf