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

0 Members and 4 Guests are viewing this topic.

Offline electronic_eel

  • Regular Contributor
  • *
  • Posts: 201
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #450 on: January 16, 2019, 10:49:52 pm »
Do we really need to fully send the value for IHRCR? Wouldn't it be sufficient if we always start with 0xFF and allow the programmer to decrease the value by 1 when setting PA.6 high for one cycle?

That way the programmer has still control over IHRCR, albeit a tad slower, but a few milliseconds don't matter during calibration. But you wouldn't need to reset A to 0 and you wouldn't need the SL. Or do I miss something?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #451 on: January 16, 2019, 11:35:47 pm »
Do we really need to fully send the value for IHRCR?
This idea was a using less instructions and had the benefit of controlling the value.

Wouldn't it be sufficient if we always start with 0xFF and allow the programmer to decrease the value by 1 when setting PA.6 high for one cycle?
That way the programmer has still control over IHRCR, albeit a tad slower, but a few milliseconds don't matter during calibration. But you wouldn't need to reset A to 0 and you wouldn't need the SL. Or do I miss something?

There is a problem to know which cycle is the correct cycle to set PA.6 high for one cycle.
In order to be sure that it will trigger the single test instruction for PA.6 in the loop you must set the PA.6 high for all instructions in the loop -1 (or -2 cycles) you get from the non taken JUMP and setup of new IHRCR. This is a very hard to do timing, especially if you try to calibrate a chip clock drift (you have to assume that the clock on the Padauk IC is not working at correct speed... we just try to find a good value to let it work at the correct speed).

EDIT: Hmm, on the other hand we could use the SPI way and send a single bit (8 bit SPI sending 0x01)

So like "tim_" V1 mixed with reuse of startup code:

_STARTUP:
      MOV A,0xFF                 ;immediate value 0xFF with all bits 1, will be changed to MOV A,0x12 (0x12 = determined calibration value) after calibration was done
_STARTUP_IHRCR:     
      MOV IHRCR, A               ;set the calibration value
      GOTO _CALIBRATION          ;jump to calibration code, will be overwritten with NOP after calibration
     
      ;set SP, init .BSS, init .DATA, ...

      ;user code here     


_CALIBRATION:
      SET1 PAC.5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, it is same as RESET pin
_CAL_TOGGLE_LOOP:
      SET1 PA.5                  ;set output of PA.5 to 1
      SET0 PA.5                  ;set output of PA.5 to 0
      T1SN PA.6                  ;read bit from PA.6
      GOTO _CAL_TOGGLE_LOOP
      ADD A,1                    ;increment A
      GOTO _STARTUP_IHRCR


now: 3 + 7 instructions ( not bad compared to the 73 instructions from PADAUK standard PFS154 calibration: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg1982153/#msg1982153 )

JS
« Last Edit: January 17, 2019, 12:07:34 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #452 on: January 17, 2019, 03:27:20 am »
According to the PMS150C datasheet it boots with ILRC not IHRC. May need setting CLKMD before calibration.

To avoid strict timing requirements the loop can be rewritten to make it slower. In the code below it should be safe to change PA.6 any time PA.5 is low, and it should stay low a lot longer than high. On the programmer set a rising edge-triggered interrupt on PA.5, busy-wait until cleared, then change PA.6.

Also, accidentally shaved one instruction away. :-) At least if rewriting IHRCR and PAC with the same values has no side efects.

Code: [Select]
_STARTUP:
      MOV A,0xFF                 ;immediate value 0xFF with all bits 1, will be changed to MOV A,0x12 (0x12 = determined calibration value) after calibration was done
_STARTUP_IHRCR:     
      MOV IHRCR, A               ;set the calibration value
      GOTO _CALIBRATION          ;jump to calibration code, will be overwritten with NOP after calibration

      ;user code here     


_CALIBRATION:
      SET1 PAC.5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, it is same as RESET pin
      SET1 PA.5                  ;set output of PA.5 to 1
      T0SN PA.6                  ;read bit from PA.6
      ADD A,1                    ;increment A
      SET0 PA.5                  ;set output of PA.5 to 0
      GOTO _STARTUP_IHRCR

P.S.: Just figured what you guys meant by using the SPI to generate a pulse. It was supposed to be slave-mode on the programmer, right?
« Last Edit: January 17, 2019, 03:54:50 am by lucas.hartmann »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #453 on: January 17, 2019, 06:20:35 am »


Nice work, JS and Lucas. This looks much better than the original :) I would reorder the ADD A,1 as below, because otherwise the delay between the clock cycle and data may bee too low. This may lead to glitches with the SPI slave.


Code: [Select]
_STARTUP:
      MOV A,0xFF                 ;immediate value 0xFF with all bits 1, will be changed to MOV A,0x12 (0x12 = determined calibration value) after calibration was done
_STARTUP_IHRCR:     
      MOV IHRCR, A               ;set the calibration value
      GOTO _CALIBRATION          ;jump to calibration code, will be overwritten with NOP after calibration

      ;user code here     


_CALIBRATION:
      T0SN PA.6                  ;read bit from PA.6
      ADD A,1                    ;increment A
      SET1 PAC.5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, it is same as RESET pin
      SET1 PA.5                  ;set output of PA.5 to 1
      SET0 PA.5                  ;set output of PA.5 to 0
      GOTO _STARTUP_IHRCR

« Last Edit: January 17, 2019, 06:37:56 am by tim_ »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #454 on: January 17, 2019, 06:32:37 am »
On the other hand, I likes JS proposal very much, which allows the programmer to control the actual calibration value: https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2125579/#msg2125579

With the sequential mode you have to go through 100+ steps of measuring and sending the signal to decrease. Since this is a very long sequence, there is a high probablity for a glitch to occur.  And there is no way to detect something is off, other than repeating the complete sequence again. Being able to control this value directly will allow to avoid this risk.

In addition, it is possible to use faster algorithms like a binary search. See for example the micronucleuos oscillator calibration. (C-Code is at the bottom). https://github.com/micronucleus/micronucleus/blob/master/firmware/osccalASM.S

Btw, I noticed now that it is not possible to remove the CLR A, from JS original code. However, I think it is possible to use "swapc IO.n" instruction to remove the sequence of "T1SN PA.6, OR A,1"? Example below. Sorry, I am in a hurry, maybe there is  stilla  bug.

Code: [Select]
_STARTUP:
      MOV A,0xFF                 ;immediate value 0xFF with all bits 1, will be changed to MOV A,0x12 (0x12 = determined calibration value) after calibration was done
_STARTUP_IHRCR:     
      MOV IHRCR, A               ;set the calibration value
      GOTO _CALIBRATION          ;jump to calibration code, will be overwritten with NOP after calibration
     
      ;set SP, init .BSS, init .DATA, ...

      ;user code here

     
_CALIBRATION:
      MOV  A,0
      SET1 PAC.5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, it is same as RESET pin
_CAL_TOGGLE_LOOP:
      SET1 PA.5                  ;set output of PA.5 to 1
      SET0 PA.5                  ;set output of PA.5 to 0

      SWAPC PA.6
      SLC A
      T0SN CF                    ;CF not set?
      GOTO _CAL_TOGGLE_LOOP
      GOTO _STARTUP_IHRCR

There surely are some peculiar instructions on the Padauk. But they all seem to be useful :)

 

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #455 on: January 17, 2019, 12:22:43 pm »
You can skip multiple IHRCR values at once simply by keeping pa6 high and counting pa5 pulses. Measuring takes a while, incrementing is fast.

You can double check for synchronization glitches at the end of calibration by fast skipping to IHRCR 0xff and 0x00, and redoing measurements. If the frequencies are far apart then we are ok.

If the frequencies end up close together then we missed a few steps and we were not at 0xff and 0x00. In this case simply reset and redo the calibration.

Enviado de meu SM-N910C usando o Tapatalk

 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #456 on: January 17, 2019, 12:34:32 pm »
According to the PMS150C datasheet it boots with ILRC not IHRC. May need setting CLKMD before calibration.
Sure.
CLKMD command should be precede any calibration and IHRC calibration is optional, same as a ILRC calibration (same scheme).

To avoid strict timing requirements the loop can be rewritten to make it slower. In the code below it should be safe to change PA.6 any time PA.5 is low, and it should stay low a lot longer than high. On the programmer set a rising edge-triggered interrupt on PA.5, busy-wait until cleared, then change PA.6.
Since on host (e.g. STM32) we can utilize a hardware SPI with DMA we can handle >24MHz SPI clock which for sure the IC will never achieve. But of course reordering is possible and should be done.

Also, accidentally shaved one instruction away. :-) At least if rewriting IHRCR and PAC with the same values has no side efects.
I like :-)


P.S.: Just figured what you guys meant by using the SPI to generate a pulse. It was supposed to be slave-mode on the programmer, right?
Yes.


Ok, now that calibration code is so short that we could think of 2 options:
* last 8 words of padauk IC specifies CRC (2words), ROLLING CODE (4 words) and holds the RET with the calibrated IHRC value.
 -> we could use this 7 words for calibration code (CRC seems to be stupid waste of space there and rolling code feature could be implemented different if required).

* I also found 1 more instruction to "shave": we could now place the short calibration code in startup directly and overwrite all 6 instructions with NOP after calibration

Code: [Select]
_STARTUP:
      MOV A,0xFF                 ;immediate value 0xFF with all bits 1, will be changed to MOV A,0x12 (0x12 = determined calibration value) after calibration was done
_STARTUP_IHRCR:     
      MOV IHRCR, A               ;set the calibration value
_CALIBRATION:
      SET1 PAC.5                 ;PA.5 as output (NOP after calibration)
      SET1 PA.5                  ;set output of PA.5 to 1  (NOP after calibration)
      T0SN PA.6                  ;read bit from PA.6  (NOP after calibration)
      ADD A,1                    ;increment A  (NOP after calibration)
      SET0 PA.5                  ;set output of PA.5 to 0 (NOP after calibration)
      GOTO _STARTUP_IHRCR

      ;user code here     


2+6 instructions :D

EDIT: Depending on CLKMD setting for WATCHDOG we might need to add a "WDRESET" instruction to the loop (optional +1)

JS
« Last Edit: January 17, 2019, 12:37:57 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 163
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #457 on: January 17, 2019, 01:57:01 pm »
* I also found 1 more instruction to "shave": we could now place the short calibration code in startup directly and overwrite all 6 instructions with NOP after calibration

Depends. For the 8-core pdk16, there is only 8 bytes in between the fppa7 entry point and the irq handler. You rourinte is 2 + 6 bytes, but once the 6 are overwritten by nop, the next instruction is already in the interrupt handler, so there is no space left for the goto to the startup routine.

Philipp
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #458 on: January 17, 2019, 02:15:31 pm »
* I also found 1 more instruction to "shave": we could now place the short calibration code in startup directly and overwrite all 6 instructions with NOP after calibration

Depends. For the 8-core pdk16, there is only 8 bytes in between the fppa7 entry point and the irq handler. You rourinte is 2 + 6 bytes, but once the 6 are overwritten by nop, the next instruction is already in the interrupt handler, so there is no space left for the goto to the startup routine.

Philipp

Startup does not need to be aligned at 0x000. Also there will be as set for CLKMD before and a WDRESET if required.

JS
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 #459 on: January 17, 2019, 04:22:19 pm »
Well I received yesterday some PFS154s, and I already have managed to get have them programmed. I've made the programmer as simple and as hobbyist-friendly as possible, using only DIP parts.

On the hardware size:

The boost converter is composed of L1, Q1, D1 and C1. The part values were mostly chosen at random until the circuit worked reliably. 1N4007 is possibly the worst choice but it's the only diode I have at the moment  ;D.

R1 is there to ensure the gate doesn't float, shorting the MOSFET. R2 and R3 form a 1/10 voltage divider for feedback. Q2 is required to cut voltage from the boost converter to the microcontroller during reset, and pass voltage only once it is stable.

VDD may be chosen from two different sources: from the SMPS through Q3, or from a fixed 3.3V supplied by a Holtek HT7133 linear regulator (U1) through Q4.

R5, R6, R7 and R8 form the standard voltage divider for data lines, for reducing 5V to 3.3V. I have settled on those values because higher ones (ie 3.3k/2.2k) introduced errors on the transmissions and I had to lower programming speed.

Now on the software side:

The Arduino's ADC is set to free running mode sampling from FB at the max allowed speed by the ATmega328 datasheet (1MHz). It is also set to use the internal 1.1V bandgap as reference, to avoid noise on the USB VCC to affect the quality of the regulation.

On every read sample, it is compared against a target voltage. If lower, the DRV pin is toggled. Otherwise, it is set to low. Given the 78KHz sampling rate, that means the buck frequency is around 37KHz at max current drain.

Now, to start a command (kudos to JS for the sequence):
  • Sets boost target to 5.8V, and waits for voltage stabilization
  • Lowers VPP_EN to send 5.8V to chip's PA5
  • Waits 100uS
  • Lowers VDD_33_EN to send 3.3V to chip's VDD
  • Waits 500uS
  • Sends the well-known payload to start command

For writing, after sending the command it sets VDD_33_EN to high impedance, and then immediately lowers VDD_SMPS_EN, thus connecting both VPP and VDD to 5.8V, which seems to be the required voltage for programming.

For wiping flash, after sending the command it then raises the target voltage to 6.5V, and then proceeds with the erase sequence.

I'm open to suggestions and improvements. I had thought about getting an ATtiny261, running V-USB on it and have the smallest and simplest, all-DIP programmer.
 
The following users thanked this post: oPossum

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #460 on: January 17, 2019, 04:37:47 pm »
@socram: Great work.

I also got my programer PCBs today... This weekend I will solder everything and try to get it running. I tried to make it as cheap and flexible and small as possible (SMD 0603,  USB powered, multiple VPP and multiple VDD voltages for tuning)

JS

BTW: Somehow I managed with over voltage? to overwrite the PFS154 fixed chip ID section (with totally different value 0x0808). I still can read the IC reliable. The program inside does start but chip ERASE or WRITE to this section is not working anymore. Maybe I converted the flash part to OTP ?
« Last Edit: January 17, 2019, 04:43:20 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline Treehouseman

  • Supporter
  • ****
  • Posts: 58
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #461 on: January 17, 2019, 04:48:23 pm »
BTW: Somehow I managed with over voltage? to overwrite the PFS154 fixed chip ID section (with totally different value 0x0808). I still can read the IC reliable. The program inside does start but chip ERASE or WRITE to this section is not working anymore. Maybe I converted the flash part to OTP ?

Did you try repeating the process (over volting) to change the ID?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #462 on: January 17, 2019, 06:34:10 pm »
BTW: Somehow I managed with over voltage? to overwrite the PFS154 fixed chip ID section (with totally different value 0x0808). I still can read the IC reliable. The program inside does start but chip ERASE or WRITE to this section is not working anymore. Maybe I converted the flash part to OTP ?

Did you try repeating the process (over volting) to change the ID?

Not yet. It was just an "accident". I had VPP at 12V and VDD at 8V for the PFS part (should be VPP 8.5V / VDD 5.9V), ... experiments...  :)

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

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #463 on: January 17, 2019, 06:56:02 pm »
@socram: I find the PNP transistors should be insufficient to block Vboost in reaching VPP and VDD. If Vboost>5V then the base voltage will be lower than the emitter's, there may be current, and the transistors may accidentally turn on.

I would suggest using 2 additional NPNs to connect VPP_EN and VDD_EN to ground when required.

An added bonus is that it would also work with 3.3V MCUs on the programmer.

Enviado de meu SM-N910C usando o Tapatalk

 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #464 on: January 17, 2019, 07:07:12 pm »
@socram: I find the PNP transistors should be insufficient to block Vboost in reaching VPP and VDD. If Vboost>5V then the base voltage will be lower than the emitter's, there may be current, and the transistors may accidentally turn on.

I would suggest using 2 additional NPNs to connect VPP_EN and VDD_EN to ground when required.

An added bonus is that it would also work with 3.3V MCUs on the programmer.
I found yesterday night that too, the hard way too, when I spent about one hour trying to figure out why the voltage didn't go to zero.

What I've done is drive them in an open collector mode. Instead of:
Code: [Select]
digitalWrite(pin, LOW);
...
digitalWrite(pin, HIGH);
I'm using:
Code: [Select]
digitalWrite(pin, LOW);
pinMode(pin, OUTPUT); // ground PNP base
...
pinMode(pin, INPUT); // high impedance PNP base
 

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #465 on: January 17, 2019, 08:27:57 pm »
High Z may not help you, the high side mosfet of most GPIO has an intrinsic, non controllable, diode to VCC. As long as Vboost is higher than VCC (+2*Vdiode, but that is cutting close) you shouldn't be able to turn off the outputs.

Exceptions are the 5V tolerant IO on some 3.3V STM32, pins that are shared with VPP, and some dedicated/hardware open collector pins (like RA4 on PICs). Checking absolute maximum ratings should clarify that.

Enviado de meu SM-N910C usando o Tapatalk

 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #466 on: January 17, 2019, 10:43:43 pm »
Hmm that actually makes sense. I guess I'll try to replace it with a TO-92 p-channel MOSFET which shouldn't have this problem.
 

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #467 on: January 17, 2019, 11:30:45 pm »
P-mosfet will have the exact same issue. If Vgs < -2V it will turn on. 2V or something like that, look for Vgs_th for your mosfet.

If Vboost is above VCC+2V then you won't be able to turn it off.

Vg = high = VCC = 5V
Vs = Vboost = 10V (example)
Vgs = Vg-Vs = 5V-10V = -5V = on state

Vg=low makes it even more "on"

Try something like the circuit attached, where "+12V" is the boost output, "VPP" goes to the target, and VPPEN comes from the programmer MCU. I used AO3401 and AO3402 because I have hundreds, but any logic-level mosfet will do.
« Last Edit: January 17, 2019, 11:49:31 pm by lucas.hartmann »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #468 on: January 18, 2019, 11:00:30 am »
I'm open to suggestions and improvements. I had thought about getting an ATtiny261, running V-USB on it and have the smallest and simplest, all-DIP programmer.

FWIW, a few days ago I analyzed the analalog datalogs that Frank Buss took of the PFS154 programming sequence. Thanks to the high resolution analog recording it was possible to deduce the dataline direction (ICPDA) for some of the ambiguous cases.

Specifically, for your code:

The first three bits after command are driven from host. Not an issue the way you did it now.

Code: [Select]
uint16_t padauk_command(uint8_t cmd) {
  padauk_spi_write( 0xA5A, 12);
  padauk_spi_write(0x5A5A, 16);
  padauk_spi_write(cmd, 4);

/*
  padauk_spi_input();

  padauk_spi_clock();
  padauk_spi_clock();
  padauk_spi_clock();
*/
  padauk_spi_write(0, 3);

  padauk_spi_input();
  padauk_spi_clock();

  uint16_t ack = padauk_spi_read(12);

  padauk_spi_clock();
  padauk_spi_output();
  return ack;
}

This is important: The clock following the data is a bus reversal cycle. The slave will only free the bus after the rising edge, so you should only take back control after this clock cycle or risk shorts on the bus.

Code: [Select]
uint16_t padauk_flash_read(uint16_t addr) {
  padauk_spi_write(addr, 13);
  padauk_spi_input();
  uint16_t data = padauk_spi_read(14);
//  padauk_spi_output();
  padauk_spi_clock();
  padauk_spi_output();
  return data;
}

PDF here: https://github.com/cpldcpu/SimPad/tree/master/Protocol*

*Just to clarify, I am not looking into creating a "competing" github repository to free-pdk. I'd be happy to put relevant information there. But I was honestly not aware who is running it due to a lack of identifiable members on the site. Also someone would need to grant write access to me.

Tim
« Last Edit: January 18, 2019, 11:04:08 am by tim_ »
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #469 on: January 18, 2019, 11:06:17 am »
Quote
    Well I received yesterday some PFS154s, and I already have managed to get have them programmed. I've made the programmer as simple and as hobbyist-friendly as possible, using only DIP parts.

    For writing, after sending the command it sets VDD_33_EN to high impedance, and then immediately lowers VDD_SMPS_EN, thus connecting both VPP and VDD to 5.8V, which seems to be the required voltage for programming.

Very nice! I like the idea of using VPP=VDD for for PFS154 to reduce circuit complexity.

Regarding controlling VDD or VPP when it is higher than the MCU voltage. Maybe one way of doing this could be how it is done in the PicKit. This is actually also what Lucas proposed above. See here: https://pic-microcontroller.com/wp-content/uploads/2013/04/Schematic-PICkit-2.jpg

Q3 forms an inverter to generate a higher control voltage and Q4 switches Vpp.

Quote
    I'm open to suggestions and improvements. I had thought about getting an ATtiny261, running V-USB on it and have the smallest and simplest, all-DIP programmer.

One challenge is that V-USB will occupy all interrupt time. So this would conflict with the way you are controlling the boost converter now. One option could be to let the booster "coast" during USB transmissions. One other challenge will be, that you somehow have to deal with the fact that no USB transmission can be accepted during programming. This would require special timing from the host program. In principle it could be possible to do it in a similar way to micronucleus. Everything would be much easier though when not having to deal with soft-USB :)
« Last Edit: January 18, 2019, 11:08:50 am by tim_ »
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #470 on: January 18, 2019, 11:17:31 am »
Thanks for the tips about the timing of the writes.

Regarding the voltage generation, I am considering replacing the whole thing with two buck/boost 2-switch converters, so I can switch the VCC before going inside the converter, rather than the 8V coming from the converter. That would also let me remove the HT7133.

I was also considering changing the ADC ISR, from instead of controlling directly the drive pin, to adjusting PWMs duty cycle, so it can be left running somewhat unattended while servicing V-USB interrupts.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #471 on: January 18, 2019, 11:55:49 am »
Regarding the voltage generation, I am considering replacing the whole thing with two buck/boost 2-switch converters, so I can switch the VCC before going inside the converter, rather than the 8V coming from the converter. That would also let me remove the HT7133.

I think you still need a way to switch on and off VDD. If you rely only on the boost converter there will be very slow ramps. This could lead to malfunctioning of the reset circuit in the MCU. This could be a rare occurence, though.
 

Offline socram

  • Regular Contributor
  • *
  • Posts: 72
  • Country: es
    • orca.pet
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #472 on: January 18, 2019, 12:08:23 pm »
So here's a comparison table of the different versions of the circuit I'm considering, with new schematics attached:
VersionLDOsNMOSPNPsNPNsDiodesInductorsResistorsCapacitorsVDD rangeVPP range
v1 (original)113011823.3V + 5V~8V5V~8V
v1 (fixed high-side)1330111023.3V + 5V~8V5V~8V
v2002222820V~8V5V~8V
The fixed v1 is just too complex due to the fixed high-side switches and doesn't really have any advantages at this point over having two completely independent DC-DC converters from the v2, so I'm kinda biased towards v2.

I've replaced NMOS with digital transistors, mostly because they are cheaper, we're dealing with very low current, and I can also avoid the external resistors connecting the gate to ground of the MOSFET, simplifying even further the board.

I think you still need a way to switch on and off VDD. If you rely only on the boost converter there will be very slow ramps. This could lead to malfunctioning of the reset circuit in the MCU. This could be a rare occurence, though.
I'm not sure that would affect any modern microcontrollers, specially if they have low-voltage resets and brown-out resets such as these. I guess there's just one way to be sure about it - trying  ;D

EDIT: Here's the EasyEDA schematic, in case anybody wants to improve or toy with it: https://easyeda.com/socram8888/padauk-programmer

EDIT2: Alternatively, we could use a SEPIC DC-DC converter, which shaves down two diodes and the PNP, in exchange for two inductors.
« Last Edit: January 18, 2019, 12:19:26 pm by socram »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 337
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #473 on: January 18, 2019, 01:21:17 pm »
*Just to clarify, I am not looking into creating a "competing" github repository to free-pdk. I'd be happy to put relevant information there. But I was honestly not aware who is running it due to a lack of identifiable members on the site. Also someone would need to grant write access to me.
Tim

Added you to free-pdk organization on github*.

*You just never asked to be added.

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

Offline tim_

  • Regular Contributor
  • *
  • Posts: 237
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #474 on: January 19, 2019, 08:12:25 am »
Added you to free-pdk organization on github*.

Thanks a lot! I will put the programming protocol information there.

Btw, in general:

It seems like every other padauk device is using a different programming algorithm. So far, only two are known: PFS154 ("5-wire", confirmed twice), PMS150C ("six-wire". The PMC150C algorithm also works on the PMS154C, when changing datalen.

I tried a couple of other device:
   - PMC251 uses six-wire physical interface, but was unresponsitve with the PMC150C algorithm
   - PMS131 uses an eight-wire physical interface and seven when in an 8-pin package

It could get quite tedious to also decode all devices. Hopefully all MTP devices will use the 5-wire protocol.
« Last Edit: January 19, 2019, 08:30:04 am by tim_ »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf