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

spth and 2 Guests are viewing this topic.

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1300 on: March 20, 2021, 09:59:08 am »
Thank JS.
Attached file, it 's Padaud calibration procoess Waveform.

where find it's asm at easy-pdk-programmer-software?

Hong
 

Offline LovelyA72

  • Contributor
  • Posts: 41
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1301 on: March 20, 2021, 10:31:17 am »
One more update regarding Padauk's IDE.
If you don't allow Padauk IDE to access the internet or use an old version after a specific date, the IDE will throw all sorts of artificial(fake) errors to prevent you from using it.

That's not really nice I'll say...

Also, Kent should really review his English in Padauk's IDE...
« Last Edit: March 20, 2021, 10:39:59 am by LovelyA72 »
Kashikoma!
 

Offline vitohong

  • Newbie
  • Posts: 2
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1302 on: March 20, 2021, 12:15:03 pm »
I use  ide 0.89 vs 0.91 .
0.84 didn't  internet.
0.91 have to use internet.
Then I want to know free PDK how to calibrate ihrc
« Last Edit: March 20, 2021, 01:45:59 pm by vitohong »
 

Offline LovelyA72

  • Contributor
  • Posts: 41
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1303 on: March 20, 2021, 02:24:30 pm »
Then I want to know free PDK how to calibrate ihrc
I think these are all you'll need. Not as simple as ".ADJUST_IC SYSCLK=IHRC/2;" but you get more control over the calibration process.
If you check sysclock.h and auto_sysclock.h you'll get more information.
Code: [Select]
unsigned char _sdcc_external_startup(void)
{
    // example, edit to suit
    AUTO_INIT_SYSCLOCK();
    AUTO_CALIBRATE_SYSCLOCK(TARGET_VDD_MV);
    return 0;                                 //perform normal initialization
}
« Last Edit: March 20, 2021, 02:26:06 pm by LovelyA72 »
Kashikoma!
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1304 on: March 20, 2021, 02:58:17 pm »
thanks,
I find "fpdkiccalib.c"

  { .sopc=0x1442, .smsk=0xFFFF, .copc=0x1709, .cocf=CO_AC_NOP},                                //search: AND A, 'B'            /   calib: MOV A, 0x09                /   after-calib: NOP
    { .sopc=0x1447, .smsk=0xFFFF, .copc=0x0091, .cocf=CO_AC_NOP},                                //search: AND A, 'G'            /   calib: MOV IO(0x11), A  (PAC)     /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x0F8D, .cocf=CO_AC_NOP|CO_VAL_CAL_TYP},                 //search: AND A, *   (CAL_TYP)  /   calib: SET1 IO(0x0D).4  (PADIER.4)/   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x1784, .cocf=CO_AC_NOP|CO_VAL_MVOL_00},                 //search: AND A, *   (MVOL_00)  /   calib: MOV A, 0x84                /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x0080, .cocf=CO_BC_SETREG1|CO_AC_NOP|CO_VAL_MVOL_08},   //search: AND A, *   (MVOL_08)  /   calib: MOV IO(0x00), A  (SETREG1) /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x17A3, .cocf=CO_AC_NOP|CO_VAL_CAL_REG0},                //search: AND A, *   (CALREG0)  /   calib: MOV A, 0xA3                /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x0080, .cocf=CO_BC_SETREG2|CO_AC_NOP|CO_VAL_CAL_REG1},  //search: AND A, *   (CALREG1)  /   calib: MOV IO(0x1E), A  (SETREG2) /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFF00, .copc=0x17FF, .cocf=CO_AC_SETIMM|CO_VAL_CAL_REG2},             //search: AND A, *   (CALREG2)  /   calib: MOV A, 0xFF                /   after-calib: MOV A, <val>
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x0F70, .cocf=CO_AC_NOP},                                //search: AND A, 0              /   calib: SET1 IO(0x10).3  (PA.3)    /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x0080, .cocf=CO_BC_SETREG0},                            //search: AND A, 0              /   calib: MOV IO(0x00), A  (SETREG0) /   after-calib: stay
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x0C90, .cocf=CO_AC_NOP},                                //search: AND A, 0              /   calib: T0SN IO(0x10).4  (PA.4)    /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x1001, .cocf=CO_AC_NOP},                                //search: AND A, 0              /   calib: ADD A, 0x01                /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x0E70, .cocf=CO_AC_NOP},                                //search: AND A, 0              /   calib: SET0 IO(0x10).3  (PA.3)    /   after-calib: NOP
    { .sopc=0x1400, .smsk=0xFFFF, .copc=0x1808, .cocf=CO_BC_FIXUP|CO_AC_NOP},                    //search: AND A, 0              /   calib: GOTO 0x008       <FIXUP>   /   after-calib: NOP


Yes, It 's magic code than Padauk.  :-DD

Hong

 

Offline gir

  • Contributor
  • Posts: 16
  • Country: at
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1305 on: March 20, 2021, 09:16:14 pm »
Calibration worked perfectly, thanks for the explanation.

Next, and hopefully last 2 issues: my Timer16 interrupt is triggered twice in a row, and sometimes is offset. I attached a screenshot; the blue channel goes high whenever the IVR is active. And there are always two peaks next to each other. Also, it looks like it is "jittering" a lot: the interrupt is triggered early/late by the exact duration of a double-trigger (the double-double-peak on the left is "persistent phosphor" from two runs in a row...if that makes sense).

I am wondering what those two issues could be caused by and how to prevent them. The datasheet mentions that the T16 interrupt happens whenever the bit _changes_, but that should also be at regular intervals, not directly after the IVR was exited.


PS:
  and a, #( 4194304 )      ;4MHz = 4194304Hz
AFAIK, MHz is defined as 10^6, not as 2^20. so 4MHz should be 4000000Hz.
« Last Edit: March 21, 2021, 09:14:14 am by gir »
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1306 on: March 21, 2021, 05:41:20 am »
Hi gir:
I run your test file.
It's fine

Hong
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1307 on: March 21, 2021, 04:00:45 pm »
Calibration worked perfectly, thanks for the explanation.
  and a, #( 4194304 )      ;4MHz = 4194304Hz
AFAIK, MHz is defined as 10^6, not as 2^20. so 4MHz should be 4000000Hz.
I know that... I gave this example since you asked for fractional MHz frequency value like 4.096MHz. I just forgot to update the comment ;-)

Next, and hopefully last 2 issues: my Timer16 interrupt is triggered twice in a row, and sometimes is offset. I attached a screenshot; the blue channel goes high whenever the IVR is active. And there are always two peaks next to each other. Also, it looks like it is "jittering" a lot: the interrupt is triggered early/late by the exact duration of a double-trigger (the double-double-peak on the left is "persistent phosphor" from two runs in a row...if that makes sense).

I am wondering what those two issues could be caused by and how to prevent them. The datasheet mentions that the T16 interrupt happens whenever the bit _changes_, but that should also be at regular intervals, not directly after the IVR was exited.

I observed a similiar behaviour some time ago and it all came down to the "stopexe" instruction.

I never had the time to fully investigate on this. I never got rid of the jitter.
My solution back then was to set SYSCLK to ILRC and not using stopexe at all.

I guess another interrupt might be triggered when the IC wakes up again. Maybe your "lazy" interrupt which does not check for the interrupt source causes the double execution.


JS

PS: Since stopexe makes use of ILRC (32 ILRC clocks when using faste wakeup) you should tune IHRC and ILRC (have a look in calib-and-fuse-demo.c inside of the examples folder from easypdk programmer). In general, if you want to tune ILRC you have to setup CLKMD for ILRC and add another tuning sequence (this time type=2). So if you want to tune ILRC and IHRC then you set ILRC as sysclk, add ILRC tuning sequence then directly afterwards set IHRC as sysclk and add IHRC tuning sequence.

Edit2: Just found in the manual:
http://www.padauk.com.tw/upload/doc/PMS15A,PMS150C%20datasheet%20V108_EN_20200724.pdf
chapter 9.2.2 Interrupt:
(1)  When using the interrupt function, the procedure should be:
Step1: Set INTEN register, enable the interrupt control bit
Step2: Clear INTRQ register
Step3: In the main program, using ENGINT to enable CPU interrupt function
Step4: Wait for interrupt. When interrupt occurs, enter to Interrupt Service Routine
Step5: After the Interrupt Service Routine being executed, return to the main program
(2)  INTEN and INTRQ have no initial values. Please set required value before enabling interrupt function.


Edit: @homeworkboy / vitohong
Hi gir:
I run your test file.
It's fine
Hong
The problem is related to PMS150C. Do you say you can run it on PMS150C with stopexe and without jitter? Maybe your resolution of the logic analyzer is not high enough.
« Last Edit: March 21, 2021, 06:43:18 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1308 on: March 21, 2021, 04:55:52 pm »
thanks,
I find "fpdkiccalib.c"
...
Yes, It 's magic code than Padauk.  :-DD

Thanks. But you can not compare full source code with comments ("fpdkiccalib.c") to NO-CODE-AT-ALL (Padauk).

The code in fpdkiccalib.c is not very difficult to understand you just need to spend some minutes in the file. In case you have specific questions feel free to ask.
Unlike some other "magicians" I will fully reveal what other would call "magic".  8)

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

Offline gir

  • Contributor
  • Posts: 16
  • Country: at
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1309 on: March 24, 2021, 06:10:15 pm »
Just a status update: I'm still working on my interrupt routine. removing stopexe from the main loop made the ISR trigger constantly (reducing the delay loop variable increases the interrupt frequency), so there's definitely something wrong with my understanding of how the ISR triggers. I tried to add the following check whether the right interrupt was triggered, but that prevented the routine from running at all.

        t1sn    intrq, #(1<<2)  ; if intrq.t16 is triggered, skip next
        reti  ; or alternatively, 'goto isr_end'


Using the ISR below, I checked which bits are set in intrq (it's 68 pulses, so bit 6 (timer2) and bit 4 (timer16)):

interrupt:
        push    af
        mov a, intrq
isr_number_loop:
        set1 pa, #6
        nop
        nop
        nop
        nop
        nop
        nop
        set0 pa, #6
        nop
        nop
        nop
        nop
        nop
        nop
        dzsn a
        goto isr_number_loop

        mov a, #0x3f
delayloop:
        dzsn a
        goto delayloop

isr_end:
        mov a, #0       ; clear all interrupts
        mov intrq, a    ; clear all interrupts
        pop     af
        reti



I don't expect you to fix that for me, js, just writing down my thoughts here.

Bonus link: a small software startup from Redmond has started using the pms150c: https://github.com/microsoft/jacdac-padauk (uses the proprietary IDE, though :/ )
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1310 on: March 24, 2021, 08:46:42 pm »
Hi,

The IRQ logic is outlined in detail in the data sheet.

TM2 sets INTRQ regardless of enabling or disabling TM2 interrupt.

However the interrupt is only triggered when INTEN is enabled for TM2.


I try to explain it in short:

All the specific "peripherals" (TM16, TM2, ...) will do their stuff and set their INTRQ.

Then there is an AND logic with INTEN  and in case INTRQ.TM2 AND INTEN.TM2 is both 1 then interrupt will be triggered.

When you leave the interrupt and it happens that  INTRQ.TM2 AND INTEN.TM2 are still both 1 then the interrupt is triggered immediately again (the normal program will get no chance to execute anything).

In case you spend to much time in interrupt this also could cause the next INTRQ to be set already which could lead to constant interrupt triggering (when you clear INTRQ at begin of IRQ) or missed interrupt (when you clear INTRQ at end of interrupt).


So let's check the effective frequency and timing of your TM16:

   ;timer16 setup
   mov   a, #(( 0<<0 | 1<<3 | 4<<5 ))   ; ovf@bit8, clk/4, ihrc
   mov   t16m, a


* IHRC/4 = 4 MHz   =>  4 MHz / 512 = 7812 Hz
* SYSCLK = 4 MHz

=> The interrupt has max 512 cycles to execute.

Calculation of cycles consumed from your interrupt:
- int vector @0x10 contains a jump (2 cycles) to your interrupt code
- pushaf (2 cycles)
- mov a, intrq (1 cycle)

LOOP (in your case executed 68 times)
- set1,nop,nop,...,set0,nop,nop (14 cycles)
- dzsn (1 cycle)
- goto (2 cycles)

- mov (1 cycle)
- mov (1 cycle)
- popaf (1 cycle)
- reti (2 cycles)

= 2+2+1+68*(14+1+2)+1+1+1+2 = 1166 cycles   <== this is way more than the 512 cycles you have, means that 2  TM16 interrupts been missed already

This might be the reason that you observe the strange looking interrupt behavior.

JS

EDIT: In case you share a bit more of your final requirement then there might be even better / easier ways to achieve this. For the purpose shown in your example you just could use TM2 alone, generating an IRQ whenever one PWM cycle is over, in IRQ count a variable up to 4 and then change the PWM output value.
« Last Edit: March 25, 2021, 08:23:08 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline KaeTo

  • Contributor
  • Posts: 20
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1311 on: March 30, 2021, 04:10:03 pm »
Hello,

I build the pdk programmer a few times, but 2 of the programmer do not work. I can interface the STMs but cant programm or probe the padauk uCs. I run the easypdkprogtest from github and got as an result
vdd: 13.65   vpp: 13.55    (vref= 3.29)

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


I found this post here so I assume that something is wrong with my programmer. What can I do or check next? (As Tools I have an lab bench power supply, an oscilloscop and a multimeter)
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1312 on: March 30, 2021, 10:40:18 pm »
Hello,

I build the pdk programmer a few times, but 2 of the programmer do not work. I can interface the STMs but cant programm or probe the padauk uCs. I run the easypdkprogtest from github and got as an result
vdd: 13.65   vpp: 13.55    (vref= 3.29)

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


I found this post here so I assume that something is wrong with my programmer. What can I do or check next? (As Tools I have an lab bench power supply, an oscilloscop and a multimeter)

Your VDD is much to high (Should be 5V). Check the resistor R6, most likely you used the wrong value there.

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

Offline KaeTo

  • Contributor
  • Posts: 20
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1313 on: March 31, 2021, 03:38:14 am »
I already checked R6. It has the correct value and is also solderd correctly.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1314 on: March 31, 2021, 07:22:03 am »
I already checked R6. It has the correct value and is also solderd correctly.

In this case most likely the opamp U3 is damaged.

While running easypdkprogtest measure with your multimeter in DC voltage mode (one lead connected to GND):

U3:

pin8: 14.9V
pin4: -2.6V

pin3: 2.5V
pin2: 2.5V
pin1: 5V

pin5: 1.18V
pin6: 1.18V
pin7: 5V


What are your values?

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

Offline KaeTo

  • Contributor
  • Posts: 20
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1315 on: March 31, 2021, 07:52:24 am »
I already checked R6. It has the correct value and is also solderd correctly.

In this case most likely the opamp U3 is damaged.

While running easypdkprogtest measure with your multimeter in DC voltage mode (one lead connected to GND):

U3:

pin8: 14.9V
pin4: -2.6V

pin3: 2.5V
pin2: 2.5V
pin1: 5V

pin5: 1.18V
pin6: 1.18V
pin7: 5V


What are your values?

JS

My values are:

U3:

pin8: 15.0V
pin4: 4.5V

pin3: 3.8V
pin2: 6.2V
pin1: 13.7V

pin5: 3.8V
pin6: 3.82V
pin7: 13.6V
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1316 on: March 31, 2021, 05:35:06 pm »
I already checked R6. It has the correct value and is also solderd correctly.

In this case most likely the opamp U3 is damaged.

While running easypdkprogtest measure with your multimeter in DC voltage mode (one lead connected to GND):

U3:

pin8: 14.9V
pin4: -2.6V

pin3: 2.5V
pin2: 2.5V
pin1: 5V

pin5: 1.18V
pin6: 1.18V
pin7: 5V


What are your values?

JS

My values are:

U3:

pin8: 15.0V
pin4: 4.5V

pin3: 3.8V
pin2: 6.2V
pin1: 13.7V

pin5: 3.8V
pin6: 3.82V
pin7: 13.6V

pin4: 4.5V <=== this should be a negative voltage !

==> check C14 / D2 / D3 / C3   - most likely the diodes are not soldered properly or in wrong orientation.

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

Offline KaeTo

  • Contributor
  • Posts: 20
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1317 on: April 01, 2021, 03:39:21 am »

pin4: 4.5V <=== this should be a negative voltage !

==> check C14 / D2 / D3 / C3   - most likely the diodes are not soldered properly or in wrong orientation.

JS

Than kyou verry, very much. I found the problem only with your help. On one PCB I placed one diode in the wrong direction and on the other PCB there was a bad solder joint with the diode. Now both PCB are working fine :)
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1318 on: April 11, 2021, 09:33:35 am »
Hi:
I compile pdk13 asm at PMS150

flow:
sdaspdk13 -losx sram.asm
sdldpdk  -i -m -x -u  sram
packihx sram.ihx > sram.hex

at sram.lst

      00004E 50 1C                   73   call push0
      000050 2A 18                   74    goto loop
It's correct.

but ihex
call  push0 -> call 0x28
goto loop   -> call 0x30

"sdlpdk -i -m -x -u sram"
Is the parameter setting wrong?

 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1319 on: April 11, 2021, 03:15:04 pm »
Hi:
I compile pdk13 asm at PMS150

flow:
sdaspdk13 -losx sram.asm
sdldpdk  -i -m -x -u  sram
packihx sram.ihx > sram.hex

at sram.lst

      00004E 50 1C                   73   call push0
      000050 2A 18                   74    goto loop
It's correct.

but ihex
call  push0 -> call 0x28
goto loop   -> call 0x30

"sdlpdk -i -m -x -u sram"
Is the parameter setting wrong?

Looks like you get confused by the SDCC assembler .LST format. SDCC uses/shows byte positions as addresses. When you disassemble the .IHX file with dispdk it shows the real code word positions like they are encoded in PDK opcodes.

1 PDK codeword (13-16 bit) = 2 bytes (2x 8 bit)

This means

SDCC .LST file : "00004E 50 1C                   73   call push0"

==> 0x50 / 2 = 0x28

REAL OPCODE / Disassembly: "call 0x28"

So everything is good.

JS


EDIT: I just spotted that your ".org 0x050" overwrites the already placed opcode for "goto loop" at 0x050 and your interrupt at 0x052. Maybe that's why your program is not working and you suspect the assembler for doing wrong things.

Please keep in mind SDCC .org directive is also BYTE based which means you have to multiply your real opcode positions by 2. In fact org 0x001, 0x003, 0x005, ... are INAVLID and can not be used at all.
« Last Edit: April 11, 2021, 03:20:27 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1320 on: April 12, 2021, 01:47:29 am »
Hi JS:
I got it ;D, thank you.

Hong
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1321 on: April 21, 2021, 08:05:54 pm »
Some interesting development.

I added support for PMS150G (in development branch).

Looks like PMS150G / PMS15B has now an additional security feature: "instruction word scrambling".
This scrambling will shuffle the bits of an instruction word around (like a substitution cipher).

First I thought somebody made a mistake and wired the codemem data bus incorrectly and this is what is needed to fix the issue.
But later I found that only 32 instructions are scrambled, followed by 32 clear instructions, followed by 32 scrambled instructions, followed by 32 clear instructions, ...
So this was done on purpose.
This 1/2 security perfectly matches the already established 7/8 security.   :-DD
Also the bit pattern for bits without shifting is 55AA  (PADAUK must be really in love with that number). :-DD

@PADAUK: Thanks for this hardware challenge, but you can increase difficulty a bit...

The scramble pattern for PMS150G is: "0123f5b78da6c9e4"

(The pattern uses the hex digit to specify the bit pos where to get it from. e.g. "01234567890ABCDEF" will produce the same output as the input; "FEDCBA9876543210" will reverse a 16 bit value)

The implementation of the scrambler / descrambler is part of easypdkprog (development branch). Any read or write operation will transparently handle scrambling / descrambling. It's like there is no scrambling ;-)

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

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1322 on: April 22, 2021, 03:13:24 am »
HI JS:
how to find ""0123f5b78da6c9e4".
It look random data.


 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 296
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1323 on: April 22, 2021, 07:24:48 am »
HI JS:
how to find ""0123f5b78da6c9e4".
It look random data.

Just like you reverse any substitution cipher: https://en.wikipedia.org/wiki/Substitution_cipher
via a known plaintext attack: https://en.wikipedia.org/wiki/Known-plaintext_attack

1. you use WRITER to write a program which contains values with only one bit set: 0x0001 0x0002 0x0004 0x0008 ... 0x0800 0x1000
2. you read back the data using easypdkprog
3. you see the mapping of every bit:

scrambled(read via easypdkprog) => original (in PDK file)

*not part of 13 bit command*
0x8000 => 0x8000  (0b1000000000000000 => 0b1000000000000000) => "0"  (numeric value of bit position in original)
0x4000 => 0x4000  (0b0100000000000000 => 0b0100000000000000) => "1"
0x2000 => 0x2000  (0b0010000000000000 => 0b0010000000000000) => "2"
*13 bit command*
0x1000 => 0x1000  (0b0001000000000000 => 0b0001000000000000) => "3"
0x0800 => 0x0001  (0b0000100000000000 => 0b0000000000000001) => "f"
0x0400 => 0x0020  (0b0000010000000000 => 0b0000000000100000) => "5"
...
0x0002 => 0x0002  (0b0000000000000010 => 0b0000000000000010) => "e"
0x0001 => 0x0800  (0b0000000000000001 => 0b0000100000000000) => "4"
 
==> "0123f5...e4"

It's like SUDOKU for advanced  8).

JS
« Last Edit: April 22, 2021, 07:31:47 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1324 on: April 22, 2021, 09:15:43 am »
HI JS:
I feel what Padauk is doing is a wild-goose chase
 ;D
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf