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

0 Members and 1 Guest are viewing this topic.

Offline oPossum

  • Super Contributor
  • ***
  • Posts: 1413
  • Country: us
  • Very dangerous - may attack at any time
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #500 on: January 27, 2019, 09:12:54 am »
lsb will always be 0, the bits in the opcode are in the correct bit position, just make bit 0 be 0 always.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #501 on: January 29, 2019, 07:29:00 am »
lsb will always be 0, the bits in the opcode are in the correct bit position, just make bit 0 be 0 always.


Thanks! That makes a lot of sense, indeed.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #502 on: January 29, 2019, 01:07:54 pm »
Project update for "Easy PDK Programer":

First of all... IT'S ALIVE. Programing PFS154 and PFS154B worked flawlessly.

After some modifications to the test pcb (thanks to your comments and some testing) following things got improved:

- use MT3608 as dc-dc-booster
- user button can be used to enter STM32 ROM bootloader for USB-DFU (easy to change firmware, can not get "bricked")
- generated VDD/VPP voltage is very stable (ripple <20mV)
- moved pins around to completely free up TIM2 for IC calibration
- moved pins around to be able to use hardware SPI for IC calibration
- moved pins around to be able to have a serial port on 5V tolerant pins going to IC for easy debugging
- added two 8 pin female header to plugin adapter for programing on top (not going to side anymore)
  => the 8 pin rows are connected that a standard TSOP16-DIP adapter can be plugged in directly and many PADAUK IC variants (esp. the flash variants like PFS154) can be programmed without an additional adapter PCB.
  => adapter PCB can be designed easily for other types and plugged on top
  => the unused connector pins are not connected to anything on purpose so they will not connect unused IC pins during programing (when using the TSOP adapter directly).

Some pictures:

The first 3 pictures show the modded 1.1 pcb (used to verify) improvements with different attachments of adapter / sockets / ... . The last 2 show the (hopefully final) schematic and pcb (just ordered).

BTW: Thanks for the tip with panelize. I will get 40 pcbs this time for $2 + shipping :)
So total cost again reduced: BOM+PCB now smaller than $2 :-)

JS
« Last Edit: January 29, 2019, 01:30:38 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: oPossum, edavid, rhodges

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1896
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #503 on: January 29, 2019, 06:01:52 pm »
Big thumbs up js_12345678_55AA  :-+ :-+ :-+

Is there progress regarding the rest of the family?
ASiDesigner, Stands for Application specific intelligent devices
I'm a Digital Expert from 8-bits to 64-bits
 

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #504 on: January 29, 2019, 08:40:14 pm »
Big thumbs up from me too  :-+

- added two 8 pin female header to plugin adapter for programing on top (not going to side anymore)
  => the 8 pin rows are connected that a standard TSOP16-DIP adapter can be plugged in directly and many PADAUK IC variants (esp. the flash variants like PFS154) can be programmed without an additional adapter PCB.
  => adapter PCB can be designed easily for other types and plugged on top
good idea.

So your plan is that you usually solder a DIP 16 ZIF socket directly onto the programmer pcb and then plug a SOIC adapter into the zif socket. Optionally you can plug in adapter pcbs into the zif socket. Correct?
Or do you not want to use the zif socket and use female pin headers instead and plug the SOIC adapter into them?

A zif socket like this: https://www.aliexpress.com/item//32905413905.html has a width of 15mm. Did you check if there is enough space on your pcb? The footprint on the bottom right, a bit left to the zif socket, looks very close to me. It is probably for the button.
« Last Edit: January 29, 2019, 08:46:34 pm by electronic_eel »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #505 on: January 30, 2019, 11:07:46 am »
So your plan is that you usually solder a DIP 16 ZIF socket directly onto the programmer pcb and then plug a SOIC adapter into the zif socket. Optionally you can plug in adapter pcbs into the zif socket. Correct?
Or do you not want to use the zif socket and use female pin headers instead and plug the SOIC adapter into them?

Neither of this.

Like I wrote I will add two 8 pin female header (like arduino female header).

In this header you can plug the TSOP/SOIC adapter (you can see in the pictures) directly.

If you want to use a ZIF socket or any other socket it is easy to build an adapter pcb (like an arduino shield).


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 #506 on: February 06, 2019, 11:58:30 am »
Hi,

since PCB delivery is delayed due to Chinese new year a friend and I played a bit making a 3D printable case for the Easy PDK Programmer.

In the pictures below you can see a first case version and mocks of the final look. The round hole will hold a 3D printed button and the long hole will get a transparent inlay for the led to shine through.

I also made some progress with the programmer firmware. Serial input for debugging from IC with auto baud detection and forwarding over USB is working. Next thing on my list is calibration.

Have fun,

JS

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

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13677
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #507 on: February 06, 2019, 01:25:41 pm »
Hi,

since PCB delivery is delayed due to Chinese new year a friend and I played a bit making a 3D printable case for the Easy PDK Programmer.
why... :palm:
Just design the PCB to fit a standard Hammond box.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #508 on: February 06, 2019, 02:37:20 pm »
Hi,

since PCB delivery is delayed due to Chinese new year a friend and I played a bit making a 3D printable case for the Easy PDK Programmer.
why... :palm:
Just design the PCB to fit a standard Hammond box.

Why? Because we can ;D

You also can mount the pcb in a "Hammond box", do some cutting for USB and the pin header and end up with a boring square case where the case alone costs more than the complete programmer.
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13677
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #509 on: February 06, 2019, 06:44:00 pm »
Hi,

since PCB delivery is delayed due to Chinese new year a friend and I played a bit making a 3D printable case for the Easy PDK Programmer.
why... :palm:
Just design the PCB to fit a standard Hammond box.

Why? Because we can ;D

You also can mount the pcb in a "Hammond box", do some cutting for USB and the pin header and end up with a boring square case where the case alone costs more than the complete programmer.
..and how much time & material does a crappy-looking 3D printed case cost ?

If you use something like these, you can use PCBs as end panels, so no manual  hole cutting etc. 
https://www.hammfg.com/electronics/small-case/plastic/1593

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #510 on: February 06, 2019, 09:47:40 pm »
Hi,

since PCB delivery is delayed due to Chinese new year a friend and I played a bit making a 3D printable case for the Easy PDK Programmer.
why... :palm:
Just design the PCB to fit a standard Hammond box.

Why? Because we can ;D

You also can mount the pcb in a "Hammond box", do some cutting for USB and the pin header and end up with a boring square case where the case alone costs more than the complete programmer.
..and how much time & material does a crappy-looking 3D printed case cost ?

If you use something like these, you can use PCBs as end panels, so no manual  hole cutting etc. 
https://www.hammfg.com/electronics/small-case/plastic/1593


Crappy? I think this is a personal opinion.

I printed it with a very fine resolution (0.2mm nozzle, 0.1mm layer height) so it  took a bit longer than needed, however your can print this in less than 30 minutes.

Here the stats:
Build time: 1 hours 43 minutes
Filament length: 2200.6 mm
Plastic weight: 6.62 g (0.01 lb)
Material cost: 0.30 USD

(3D printer used from our local hacker space, Filament used PET-G, not this rubbish ABS).

So not sure how fast you get those expensive cases you mentioned delivered or do you work for them?
The box you mentioned (e.g. 1593KBK) costs around 3.68 USD.

The programmer PCB + components is less than 2 USD + 0.30 USD for the 3D printed cases. All together still less than the much bigger, space wasting  1593KBK box.

Also if somebody does not like it, he can change it, make a new one or even use some commercial stuff.


And best part (before you can rant about this). The custom printed case DOES SHOW THE PINOUT (printed on PCB)  ;D
« Last Edit: February 06, 2019, 10:07:13 pm by js_12345678_55AA »
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 #511 on: February 07, 2019, 04:03:50 pm »
Regarding calibration I came up with the following idea:

(I will use SDCC from now on for any future development)

If somebody wants to insert calibration in a program we can do this by using a sequence of NOP instructions.
So if somebody compiles the program and uses a programmer which does not support calibration the NOP sequence will not do any harm.

Now the trick. Instead of using plain simple NOPs I plan to use a sequence of "AND A, ..."
Since it is absolutely impossible that someone wants to AND A a times in a row with different values we can use the immediate 8 bit value to encode information and have a strong marker:

and a, #'I'
and a, #'H'
and a, #'R'
and a, #'C'
and a, #(16000000)
and a, #(16000000)>>8
and a, #(16000000)>>16
and a, #(16000000)>>24

Like this we can encode a marker ("IHRC" for calibration of internal high speed RC / "ILRC" of the internal low speed RC) and the desired tuning frequency.
If you compile and flash the code with another programmer without doing calibration it will just do 8 ANDs and most likely result in A=0 since frequency>>24 is for sure not desired ;-)

Easy-PDK-Writer now can scan the binary for the magic ANDs with 'I' 'H' 'R' 'C' / 'I' 'L' 'R' 'C' + frequency value, dynamically insert the calibration code, write the IC, do the calibration, write the calibration result to IC and change the calibration code to NOPs.

TO make it more convenient I wrote 2 macros for SDCC:

Code: [Select]
#define EASY_PDK_CALIBRATE_IHRC(frequency) \
__asm__(                      \
  "and a, #'I'                \n"\
  "and a, #'H'                \n"\
  "and a, #'R'                \n"\
  "and a, #'C'                \n"\
  "and a, #("#frequency")     \n"\
  "and a, #("#frequency">>8)  \n"\
  "and a, #("#frequency">>16) \n"\
  "and a, #("#frequency">>24) \n"\
)
Code: [Select]
#define EASY_PDK_CALIBRATE_ILRC(frequency) \
__asm__(                      \
  "and a, #'I'                \n"\
  "and a, #'L'                \n"\
  "and a, #'R'                \n"\
  "and a, #'C'                \n"\
  "and a, #("#frequency")     \n"\
  "and a, #("#frequency">>8)  \n"\
  "and a, #("#frequency">>16) \n"\
  "and a, #("#frequency">>24) \n"\
)

So if you want to insert calibration to your program you only have to add one line to _sdcc_external_startup after setting clkmd:

Code: [Select]
unsigned char _sdcc_external_startup(void)
{
  clkmd = 0x34;                       // Use IHRC / 2 = 8 Mhz for system clock, disable ILRC, disable watchdog
  EASY_PDK_CALIBRATE_IHRC(8000000);   // calibrate IHRC to 8 MHz system clock
  return 0;
}


What do you think?

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 #512 on: February 07, 2019, 05:57:15 pm »
I like the idea of using the #defines for inserting the calibration routine into the code. That is convenient.

But how about this change: The asm code in the define is the actual calibration routine used. That makes what actually happens more obvious to the user and is less of a magic number.

The programmer then writes the unmodified program to the controller and does the calibration.

The flash control program then offers two options:
1. it can try to find the actual bytecode of the calibration routine in the hex file. If it finds it, it can write the calibration value and nop out the rest

2. it can't find the exact bytecode, but you can manually specify the calibration value address, nop start address and nop length.

The 2nd option allows the user to easily experiment with different calibration routines without having to change the flash control program each time.

One reason for a custom calibration routine that comes to mind would be calibration for two different vcc voltage levels, for example if the controller will be used with varying battery voltage.
« Last Edit: February 07, 2019, 09:56:31 pm by electronic_eel »
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #513 on: February 09, 2019, 11:46:35 pm »
So I've a long time without time to spend on my programmer, I've finally had some to test the double software-controlled SEPIC DC-DC converters for feeding the PFS154.

Good thing is, the SEPIC design works perfectly fine. Bad thing is, the overly simplistic feedback loop I am using isn't really any good and many time it gets stuck oscillating while the PWM rate changes like mad. I guess I'll have to actually look at how PI loops work.

 

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #514 on: February 10, 2019, 11:10:35 am »
DC-DC converters tend to be hard to control when they have low/no load.

Try adding 100R dummy loads to each output.

Enviado de meu Moto MAXX usando o Tapatalk

 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #515 on: February 10, 2019, 02:58:12 pm »
Hi,

I did some initial experiments with calibration of PFS154.

Here my measurements + notes:

1st experiment: Use PADAUK IDE, let WRITER calibrate the IC and then use our calibration loop and measure:

- .ADJUST_IC   SYSCLK=IHRC/2, IHRC=16MHz, VDD=5.0V;
- use IHRC 16MHz @ 5.0V @ 20°C
- SYSCLK = IHRC/2 => IC runs instructions @8 MHz (clkmd = 0x34, IDE calculated this value)
- our calibration loop toggles a pin on / off  within 8 clocks (7 instructions => 7 clocks + 1 extra clock from goto)
=> 1 MHz output on pin expected when measured with oscilloscope

measured: 1.0021 MHz - 1.0029 MHz  (slight temp up/down like put finger or blow over it: 1.0015 - 1.0036 MHz)

notes:
@7ED start val for IHRCR on PFS154: 0x80
@7EE start val for BGTR on PFS154: 0x5A
@7FE IHRCR value from WRITER: 0x81 (used for normal execution)


2nd experiment: Use PADAUK IDE, disable any calibration from WRITER and then use our calibration loop and measure:
- .ADJUST_IC DISABLE;
- use IHRC 16MHz @ 5.0V @ 20°C
- SYSCLK = IHRC/2 => IC runs instructions @8 MHz (clkmd = 0x34, IDE calculated this value)
- our calibration loop toggles a pin on / off  within 8 clocks (7 instructions => 7 clocks + 1 extra clock from goto)
=> 1 MHz output on pin expected when measured with oscilloscope

measured: 591.3 - 591.6 kHz  :-// :-// :-//

So it looks like we really need calibration or at least use the standard value of 0x80 for IHRCR on PFS154.

Unfortunately the PADAUK IDE does not allow to compile a program which sets IHRCR (error: "The 'IHRCR' not be supported at User Mode") so I'm stuck here.

=> Time to focus on the PC program to send data to easy pdk programmer for easy flashing of sdcc generated programs.


JS

UPDATE:

After some more experiments, the following IHRCR values for the specific PFS154 I try this with results in this values:

IHRCR
0x00 =>  591.4 kHz
...
0x80 =>  990.5 kHz
0x81 => 1002.5 kHz
...
0xFF => 1490.8 kHz


WOW, almost 1.5 MHz which translates to approx 12MHz sysclock (24MHz IHRC)  :) :)
« Last Edit: February 10, 2019, 09:29:08 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #516 on: February 10, 2019, 08:45:35 pm »
Try adding 100R dummy loads to each output.
Thanks. I've tried it and it gets somewhat better, but still gets screwed every now and then. I guess I'll try that the PID controller.

Development is going slightly slow given my current limited debugging (literally doing single byte hex prints over serial) and lack of knowledge on the matter.
 

Offline GonzoTheGreat

  • Regular Contributor
  • *
  • Posts: 120
  • Country: aq
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #517 on: February 13, 2019, 02:29:30 am »
I had thought about getting an ATtiny261, running V-USB on it and have the smallest and simplest, all-DIP programmer.
Whay not use a Padauk MCU to program Padauk MCUs.
...+ some off-the shelf discrete components.
 

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #518 on: February 13, 2019, 02:36:06 am »
I am looking into an ESP8266 wifi enabled programmer. Check esplink for arduinos and ARMs.

I am usually terrified of direct copper to my expensive-ish computers while developing stuff that may blow up. :-)

Enviado de meu Moto MAXX usando o Tapatalk

 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #520 on: February 14, 2019, 05:12:12 pm »
I had thought about getting an ATtiny261, running V-USB on it and have the smallest and simplest, all-DIP programmer.
Whay not use a Padauk MCU to program Padauk MCUs.
...+ some off-the shelf discrete components.

It's an egg-and-chiken problem: I can't develop a programmer using a Padauk device if I can't get them programmed the first place  ;D
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #521 on: February 16, 2019, 10:09:07 am »
Well after seeing how hard was to get a SEPIC driver working, and specially, seeing how it didn't actually improve board size because of how large the inductors were, I've went back to a single boost converter using a series of transistors to switch where VDD is connected to. This time I've made the high side switch work properly.

Here's my current schematic:


And this time, instead of wiring everything on a breadboard, I've decided to make a tiny prototype PCB:


It turns out to be pretty small. It better be after five hours moving and adjusting components  |O

I'm a computer engineer, not an electronics engineer, so if anybody is able to spot any error, it'd be nice to let me know to fix it before ordering it.
« Last Edit: February 16, 2019, 10:11:01 am by socram »
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #522 on: February 17, 2019, 07:53:54 pm »
I don't think it makes sense to build a boost converter yourself, except for fun and learning. There are so many ICs out there which does this, probably at lcsc.com for cheap as well, which need just one external inductor. The performance and regulation is probably better than your DIY version, and parts costs might be lower. And for each part, you would need to pay assembly cost too, if a manufacturer does the full board for you. Using a fixed voltage boost converter and a microcontroller with a DAC, and an OpAmp, would then be the easiest and most reliable way to regulate it, and with low noise and ripple.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #523 on: February 17, 2019, 08:42:07 pm »
I don't think it makes sense to build a boost converter yourself, except for fun and learning. There are so many ICs out there which does this, probably at lcsc.com for cheap as well, which need just one external inductor. The performance and regulation is probably better than your DIY version, and parts costs might be lower. And for each part, you would need to pay assembly cost too, if a manufacturer does the full board for you. Using a fixed voltage boost converter and a microcontroller with a DAC, and an OpAmp, would then be the easiest and most reliable way to regulate it, and with low noise and ripple.
No matter which way I go, I still need one inductor, one diode and one capacitor for a boost converter. It is true that using a dedicated converter would simplify the boost converter design (by removing the MOSFET and the enable PNP and replacing that with a boost IC with input enable pin).

However, I would then need a way to reliably adjust the output voltage, by either making an array of feedback resistor dividers or by using that DAC+OpAmp configuration. The former needs several resistors, increasing the required board space, plus pins on the microcontroller that I don't have. The later would need another IC plus the charge pump JS has had to use on his design, which also means more parts and larger board.

Regarding regulation quality and noise, remember it's just a digital IC. So far using this design I've successfully programmed data on it using any voltage from 5.8 up to 6.2. Thus, it's not really sensitive and I'd be good to go with it.

Thus by any means I fail to see how using a dedicated boost controller would make things any easier, smaller, or cheaper.
 

Offline oPossum

  • Super Contributor
  • ***
  • Posts: 1413
  • Country: us
  • Very dangerous - may attack at any time
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #524 on: February 18, 2019, 01:00:54 am »
Fresh baked PCBs.

Quad voltage source with DAC084S085 & ALM2402 x2
Quad level shifter with 74LVCH1T45 x4
PMS150C (13 bit)
PFS154  (14 bit)
PFS173  (15 bit)

Next step is to write some code and test the quad voltage source for stability, accuracy, and slew rate.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf