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

0 Members and 1 Guest are viewing this topic.

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #425 on: January 13, 2019, 04:02:03 pm »
Kind of both: One could use a linker file (or the --code-loc option), but the default for --code-loc needs to be changed, so it just works for the common case. However, there also are a few other linker / compiler-linker interface issues that need to be fixed.

Philipp

Is there any easy workaround?

Compiling with --code-loc 0x0011 or so might help. Worst case one could manually fix the jump targets in the binary. But I don't consider the sdcc-based toolchain ready yet. Work on linker integration has just started. There are probably bugs in the compiler and assembler, many of which will probably not be found before regression testing on the yet-to-be-written-and-ntegrated uCsim-based simulator is in place.

Philipp
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #426 on: January 13, 2019, 05:40:57 pm »
I'd prefer not to use the padauk tools right now for several reasons:
- The tools to decode pdk files from "freepdk" do not compile.
This is just not correct. The tools do compile fine for me.

(who is maintaining this, btw. I added an issue)
Read this thread and you know who are maintainers.
Also your question looks like you did understood open source development wrong. If something is not working for you it is not the time to cry for a maintainer to help and and fix your problems.
It is much better if you try at least a little bit to investigate yourself and then come up with possible solutions.
The issue is still open since a proper problem / bug report needs some good information which you did not include. Basically an "It is not working on my msys2 (windows)" or "also not working on recent Mint" without any version information, processor architecture, compiler version, ..." is not helpful. I gave you some examples in the issue on github what a good bug report should contain...

- I would like omit the oscillator calibration code for now as this only adds to complexity in the programmer.

Again, read this thread any you know how to do it.

- Out of principle, to avoid IP contamination.

This is the most funny thing you ever posted here. You want to avoid IP contamination?? How do you plan to "avoid" the IP-Core running in the PADAUK IC?
If this really is your concern then for sure you should go with RISC-V.


So dear "tim_" / "cpldcpu" please stop speaking bad about others work or things which you did not "create" yourself.

Isn't it enough that you suggest in your german super forum that most of the community work from this thread looks like you been the one who did it / who found it?

Do you really need to sabotage other projects now?


JS
« Last Edit: January 13, 2019, 05:48:35 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 #427 on: January 13, 2019, 06:00:53 pm »
Guys, this is getting too much for me. JS, you may need to think twice before writing angry responses on the internet.

Regarding the issue with compiling the toolchain: I put into the issue on github what I know. I tried two different toolchains on two operating systems and got the same issue. The root cause is not apparent to me now, that's why I opened an issue instead of a pull request. OSS is not about "do everything on your own", that's just very inefficient.

Regarding IP contamination, you may want to read the link about "clean room implementation" that I posted earlier. I agree that it is unlikely to run into issues with Padauk, but in the end it should be my own choice to follow clean processes.

Btw, got a blinky working now on the PFS154 with the OSS toolchain (SDASPDK), and an arduino based programmer. Still extremely hacky.
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #428 on: January 13, 2019, 06:03:13 pm »
- Out of principle, to avoid IP contamination.

This is the most funny thing you ever posted here. You want to avoid IP contamination?? How do you plan to "avoid" the IP-Core running in the PADAUK IC?
If this really is your concern then for sure you should go with RISC-V.
While I consider free hardware to be a good thing, there is still a difference. Richard Stallman draws the line between stuff that is supposed to be changed by the user (updateable programs, firmware, FPGA configuration) and and stuff that isn't (e.g. a ROM in a device), which seems to make sense to me.

So a position of not being willing to use non-free software can make sense.

And there is indeed some risk of "IP contamination": AFAIK, Mini-C adds some of its own code into the resulting program. Many compilers,like GCC or SDCC have a "linker exception" in the license for their library, so the resulting program is not affected by the library license. I din't notice something similar in Mini-C yet (but maybe I just didn't check closely enough). On the other hand, maybe whatever Mini-C adds is unsubstantial enough to not affect the license of the wholeprogram. But that might depend on jurisdiction.

Philipp
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #429 on: January 13, 2019, 06:08:39 pm »
Compiling with --code-loc 0x0011 or so might help. Worst case one could manually fix the jump targets in the binary. But I don't consider the sdcc-based toolchain ready yet. Work on linker integration has just started. There are probably bugs in the compiler and assembler, many of which will probably not be found before regression testing on the yet-to-be-written-and-ntegrated uCsim-based simulator is in place.

Philipp

There were still some remaining relocation conflicts. What I did in the end:

- I used the *.asm file as a basis for an assembler version to fix the relocation issues.
- For MOVs to the I/O region, the assembler generated the opcode for MOV to SRAM. I fixed it manually in the binary.

Everything works now and I got a flashing LED connected to a PFS154.  ;D

Code: [Select]
;--------------------------------------------------------
; Blinky for Padauk PFS154C
; Based on asm code generated from blinky.c by SDD
;
; File Created by SDCC : free open source ANSI-C Compiler
; Version 3.8.6 #10883 (Linux)
;--------------------------------------------------------
.module blinky
.optsdcc -mpdk14

;--------------------------------------------------------
; Public variables in this module
;--------------------------------------------------------
.globl _main
.globl _tm2b
.globl _tm2s
.globl _tm2c
.globl _pac
.globl _pa
.globl _intrq
.globl _inten
.globl _clkmd
.globl _counter
;--------------------------------------------------------
; special function registers
;--------------------------------------------------------
.area RSEG (ABS)
.org 0x0000
_clkmd = 0x0003
_inten = 0x0004
_intrq = 0x0005
_pa = 0x0010
_pac = 0x0011
_tm2c = 0x001c
_tm2s = 0x0017
_tm2b = 0x0009
;--------------------------------------------------------
; ram data
;--------------------------------------------------------
.area DATA
_counter::
.ds 2
;--------------------------------------------------------
; overlayable items in ram
;--------------------------------------------------------
;--------------------------------------------------------
; Stack segment in internal ram
;--------------------------------------------------------
.area SSEG
__start__stack:
.ds 1

;--------------------------------------------------------
; absolute external ram data
;--------------------------------------------------------
.area DABS (ABS)
;--------------------------------------------------------
; interrupt vector
;--------------------------------------------------------
.area HOME
__interrupt_vect:
;--------------------------------------------------------
; global & static initialisations
;--------------------------------------------------------
.area HOME
.area GSINIT
.area GSFINAL
.area GSINIT
.area PREG (ABS)
; .area CODE
.org 0x00
__sdcc_program_startup:
goto _main
; return from main will return to caller
;--------------------------------------------------------
; code
;--------------------------------------------------------
.org 0x10
; -----------------------------------------
; function main
; -----------------------------------------
_main:
mov a, #0x78
mov _clkmd, a
mov a, #0x01
mov _pac, a
00108$:
mov a, #0x30
mov _counter+0, a
mov a, #0x75
mov _counter+1, a
; blinky.c: 35: while (--counter);
00101$:
dec _counter+0
subc _counter+1
mov a, _counter+0
or a, _counter+1
ceqsn a, #0x00
goto 00101$
; blinky.c: 36: pa=0x00;
mov a, #0x00
mov _pa, a
; blinky.c: 38: counter=30000;
mov a, #0x30
mov _counter+0, a
mov a, #0x75
mov _counter+1, a
; blinky.c: 39: while (--counter);
00104$:
dec _counter+0
subc _counter+1
mov a, _counter+0
or a, _counter+1
ceqsn a, #0x00
goto 00104$
; blinky.c: 40: pa=0x01;
mov a, #0x01
mov _pa, a
goto 00108$
00110$:
; blinky.c: 42: }
ret




 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #430 on: January 13, 2019, 06:14:27 pm »
Guys, this is getting too much for me. JS, you may need to think twice before writing angry responses on the internet.

Regarding the issue with compiling the toolchain: I put into the issue on github what I know. I tried two different toolchains on two operating systems and got the same issue. The root cause is not apparent to me now, that's why I opened an issue instead of a pull request. OSS is not about "do everything on your own", that's just very inefficient.

Regarding IP contamination, you may want to read the link about "clean room implementation" that I posted earlier. I agree that it is unlikely to run into issues with Padauk, but in the end it should be my own choice to follow clean processes.

Btw, got a blinky working now on the PFS154 with the OSS toolchain (SDASPDK), and an arduino based programmer. Still extremely hacky.

So why do you think I get angry?

>Regarding the issue with compiling the toolchain: I put into the issue on github what I know. I tried two different toolchains on two operating systems and got the same issue.
=> Exact like I wrote, without proper version information of your problem it is not helpful at all. It's like saying I tried to kick the ball in the goal 2 times but it did not work, so the ball must be broken.

>The root cause is not apparent to me now, that's why I opened an issue instead of a pull request.

>OSS is not about "do everything on your own", that's just very inefficient.
=> I said you should a least TRY to solve the problem. I did NOT say you should "do everything on your own".

>Btw, got a blinky working now on the PFS154 with the OSS toolchain (SDASPDK), and an arduino based programmer. Still extremely hacky.
=> Aha... ""you"" got "a" blinky working (again you comfortably forgot to mention that the blinky was based on spth's port of the blinky was based on the free-pdk sample, spth cleary mentioned it.

JS

EDIT: Just saw that you posted "YOUR" blinky... just as expected. Waiting for your posting in german forum claiming YOU just did the first blinky for PFS154 only using open source for compilation and flashing based on your hard work.
« Last Edit: January 13, 2019, 06:17:15 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 #431 on: January 13, 2019, 06:18:33 pm »
And there is indeed some risk of "IP contamination": AFAIK, Mini-C adds some of its own code into the resulting program. Many compilers,like GCC or SDCC have a "linker exception" in the license for their library, so the resulting program is not affected by the library license. I din't notice something similar in Mini-C yet (but maybe I just didn't check closely enough). On the other hand, maybe whatever Mini-C adds is unsubstantial enough to not affect the license of the wholeprogram. But that might depend on jurisdiction.

Philipp

Indeed. It is possible that Padauk sees the process of adjusting the clock in the programmer as their IP or maybe even has patented it. In that case it would be better to completey omit this process or come up with a clean room implementation that is not based on reverse engineering code.
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #432 on: January 13, 2019, 06:24:16 pm »
JS, you need to chill out.

I will take a break from this forum for now.

And you should at least try to FULLY read and understand what I said.

Just an example:

I'd prefer not to use the bilnky from tim_ right now for several reasons:
- The source from "tim_" do not compile. (who is maintaining this, btw. I should add an issue)
- I would like to omit the source parts from blinky taken from others without giving notice
- Out of principle, to avoid LICENSE contamination.

Would this kind of words make you happy?

JS

EDIT:

Some more examples?:

here you mention that the binary format was deciphered: https://www.mikrocontroller.net/topic/461002#5616184
one post later(10. Nov) it looks like YOU found some valuable information / links (and as usual, you comfortably "forgot" where you found the information) => (07. Nov): https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg1946455/#msg1946455

(7 Jan.) you created a posting on your german forum announcing that there was progress deciphering the programing protocol by linking just to the data capture and your analysis (and as usual you comfortably "forgot" to mention the work of all people from this thread here): https://www.mikrocontroller.net/topic/461002#5685419

...

Do you see the pattern? So maybe some people might get angry?
« Last Edit: January 13, 2019, 09:06:11 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 #433 on: January 13, 2019, 06:41:30 pm »
I'd prefer not to use the bilnky from tim_ right now for several reasons:

Oh I see the misunderstanding: With "Padauk-tools" I referred to the tools by the company Padauk. I was only referencing the "Free-pdk" tools, because I would need them to decode the PDK file.


 

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #434 on: January 15, 2019, 10:23:44 pm »
A general issue with SDASPDK: It seems all adress calculation for the instruction memory are based on bytes, not words. Therefore branch targets are off by a factor of two. Or am I missing something?

The assembler was contributed by Nicolas Lesser. I just merged a patch by him that fixes this issue.

There are a few additional examples at https://github.com/free-pdk/sdcc-pdk-code-examples now; they seem to compile and assemble fine, but I didn't try them on simulator / hardware yet (I've just designed some minimal evaluation boards).

Philipp
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #435 on: January 16, 2019, 03:08:40 pm »
I was thinking of creating calibration code for Internal Highspeed RC (IHRC) and came up with the following minimal code:


_STARTUP:
      GOTO _CALIBRATION          ;jump to calibration code, will be overwritten with NOP after calibration
      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
      MOV IHRCR, A                    ;set the calibration value

      ;set SP, init .BSS, init .DATA, ...

      ;user code here

;----------------------------------------------------------------

.RAMADR 0
      BYTE TMP

.ROMADR   0x7D0

_CALIBRATION:
      CLEAR TMP                  ;set TMP to 0
_CAL_NEXT_STEP:
      MOV A,0x10                 ;PA.5 as output, rest as input  => this pin should exist on all devices, same as RESET/ICVPP pin
      MOV PAC,A
_CAL_WAIT_HOST:
      T1SN PA.6                  ;read bit from PA.6 (measurement start?) => this pin should exist on all devices, same as ICPDA pin
      GOTO _CAL_WAIT_HOST
_CAL_TOGGLE_LOOP:
      XOR PA,A                   ;invert output of PA.5
      T0SN PA.6                  ;read bit from PA.6 (measurment done?)
      GOTO _CAL_TOGGLE_LOOP
      INC TMP                    ;increment TMP value (will run from 0 - 255, increment by 1 with each measurement done single)
      MOV A,TMP                  ;read the current TMP value
      MOV IHRCR, A               ;write current TMP value to IHRCR tuning register
      GOTO _CAL_NEXT_STEP        ;jump to next calibration step

;------------------------------------------------------------------------
;assembly output (14 bit) of the calibration (12 instructions)

0x07d0:   0x1300    CLEAR [0x00]
0x07d1:   0x2f10    MOV A, 0x10
0x07d2:   0x0191    MOV IO(0x11), A  ;PAC
0x07d3:   0x1b90    T1SN IO(0x10).6  ;PA.6
0x07d4:   0x37d3    GOTO 0x7D3
0x07d5:   0x00d0    XOR IO(0x10), A  ;PA
0x07d6:   0x1990    T0SN IO(0x10).6  ;PA.6
0x07d7:   0x37d5    GOTO 0x7D5
0x07d8:   0x1200    INCM [0x00]
0x07d9:   0x0f80    MOV A, [0x00]
0x07da:   0x018b    MOV IO(0x0B), A  ;IHRCR
0x07db:   0x37d1    GOTO 0x7D1


STARTUP CODE:
1st instrucrtion is a GOTO to the calibration code, this GOTO will be changed to a NOP after calibration was done
-> this is faster and more compact than PADAUK code since no stack setup is required for the CALL and CALL+RET wastes more cycles than overwrite GOTO with NOP (actually the calibration never need to return since we can reset/unpower the IC to leave this mode)
2nd instruction is a MOV A,0xFF which can be overwritten to anything like MOV A,0x.. later (this will receive the calibration value)
-> again faster
3rd instructions sets the IHRCR tuning register value
...

CALIBRATION CODE:
PA.5 is used as output from IC which toggles on/off in a tight loop => output max is up to 9 MHz which can be captured and counted in hardware on host MCU easily (e.g. TIM on STM32); measurement of how many toggle in specific time period
PA.6 is used as input to IC to signal measurement start and measurement done, after each measurement done the value of IHRCR is incremented and the next measurement can start
-> this is slower than PADAUK since we can not go up/down (+1/-1) we have to cycle over all 256 values of the byte instead, but it is a lot more compact, and calibration does not need to be so fast...


So now asking you for creative ideas to make it even more compact ( < 3 + 12 instructions )

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

Offline j7b

  • Newbie
  • Posts: 4
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #436 on: January 16, 2019, 04:11:11 pm »
      GOTO _CALIBRATION          ;jump to calibration code, will be overwritten with NOP after calibration

How would one overwrite or otherwise change instructions?
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #437 on: January 16, 2019, 04:13:04 pm »
XOR PA,A is only supported by few devices.

Philipp
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #438 on: January 16, 2019, 04:14:54 pm »
      GOTO _CALIBRATION          ;jump to calibration code, will be overwritten with NOP after calibration

How would one overwrite or otherwise change instructions?

A nop is all-zero. When writing PROM, a 1 can be changed to 0 any time (a few years ago, in a different device, a bug was discovered after PROMs had been programmed - so I had to come up with a patch that only flips 1 bits to 0).

Philipp
 

Offline j7b

  • Newbie
  • Posts: 4
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #439 on: January 16, 2019, 04:58:51 pm »
A nop is all-zero. When writing PROM, a 1 can be changed to 0 any time (a few years ago, in a different device, a bug was discovered after PROMs had been programmed - so I had to come up with a patch that only flips 1 bits to 0).

You're changing an OTP device's ROM via software after calibration?
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 78
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #440 on: January 16, 2019, 05:49:42 pm »
A nop is all-zero. When writing PROM, a 1 can be changed to 0 any time (a few years ago, in a different device, a bug was discovered after PROMs had been programmed - so I had to come up with a patch that only flips 1 bits to 0).

You're changing an OTP device's ROM via software after calibration?

The calibration routine runs on the device. The programmer calculates the correct calculation value while it is executed. Then the programmer writes final program and calibration value onto the device.
So the initial jump to the calibration routine gets overwritten by a nop. The final user program follows the nop. The calibration routine is somewhere near the end of the ROM space.

AFAIK, some devices even come with a factory-self-test routine (in the manual, there is a note about a part of the ROM being reserved for "system use", for details see earlier posts in this thread).

Philipp
 

Offline lucas.hartmann

  • Contributor
  • Posts: 16
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #441 on: January 16, 2019, 06:06:43 pm »
OTP is like fuses, 0=blown, 1=intact. You can blow them anytime, but never restore them back.

You may also blow some fuses now and some at a later time.

Enviado de meu SM-N910C usando o Tapatalk

 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #442 on: January 16, 2019, 07:14:15 pm »
XOR PA,A is only supported by few devices.

Philipp

Yes this is true. I think we will have different calibration routines for 13,14,15,16 bit devices.
For example on 16 bit devices we have the toggle instruction, so A register could be free completely, no memory needed some instructions saved...

hmmm... let's me think:

_CALIBRATION:
      MOV A,0                    ;maybe not needed since A might be 0 after reset?
      SET1 PAC.5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, it is same as RESET pin
_CAL_NEXT_STEP:
      MOV IHRCR, A               ;write current A value to IHRCR tuning register
_CAL_WAIT_HOST:
      T1SN PA.6                  ;read bit from PA.6 (measurement start?)
      GOTO _CAL_WAIT_HOST
_CAL_TOGGLE_LOOP:
      SET1 PA.5                  ;set output of PA.5 to 1
      SET0 PA.5                  ;set output of PA.5 to 0
      T0SN PA.6                  ;read bit from PA.6 (measurment done?)
      GOTO _CAL_TOGGLE_LOOP
      ADD A,1                    ;increment A (will run from 0 - 255, increment by 1 with each measurement done single)
      GOTO _CAL_NEXT_STEP        ;jump to next calibration step


1 instruction saved, not using the XOR IO anymore :)

JS
« Last Edit: January 16, 2019, 07:17:30 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 #443 on: January 16, 2019, 07:31:48 pm »
Maybe one could use SET1 and SET0 to toggle the clock? Then no memory write is needed. V1 needs the host to be really fast and issue a timed signal on PA6 to increment TMP. V2 will wait until PA6 is released again.

Edit: I see you were faster and already posted a version with SET0 and SET1 :)

Code: [Select]
_CALIBRATION_V1:
      SET1 PAC,5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, same as RESET/ICVPP pin
      MOV A,0
_CAL_MAIN_LOOP:
      T1SN PA.6                  ;read bit from PA.6, increment IHRCR when low. Needs to be low for only one clock cycle!
      ADD  A,1
      SET1 PA,5                  ;output one clock cycle
      SET0 PA,5
      MOV IHRCR, A               ;write current A value to IHRCR tuning register
      GOTO _CAL_MAIN_LOOP     
     

_CALIBRATION_V2:
      SET1 PAC,5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, same as RESET/ICVPP pin
      MOV A,0
_CAL_MAIN_LOOP:
      T1SN PA.6                  ;read bit from PA.6, increment IHRCR when low. Needs to be low for only one clock cycle!
      ADD  A,1
      SET1 PA,5                  ;output one clock cycle
      SET0 PA,5
      MOV IHRCR, A               ;write current A value to IHRCR tuning register
_CAL_WAIT
      T0SN PA.6                  ;read bit from PA.6, increment IHRCR when low. Needs to be low for only one clock cycle!
      GOTO _CAL_MAIN_LOOP     
      GOTO _CAL_WAIT
« Last Edit: January 16, 2019, 07:33:56 pm by tim_ »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #444 on: January 16, 2019, 08:59:11 pm »
Maybe one could use SET1 and SET0 to toggle the clock? Then no memory write is needed. V1 needs the host to be really fast and issue a timed signal on PA6 to increment TMP. V2 will wait until PA6 is released again.

Edit: I see you were faster and already posted a version with SET0 and SET1 :)

Code: [Select]
_CALIBRATION_V1:
      SET1 PAC,5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, same as RESET/ICVPP pin
      MOV A,0
_CAL_MAIN_LOOP:
      T1SN PA.6                  ;read bit from PA.6, increment IHRCR when low. Needs to be low for only one clock cycle!
      ADD  A,1
      SET1 PA,5                  ;output one clock cycle
      SET0 PA,5
      MOV IHRCR, A               ;write current A value to IHRCR tuning register
      GOTO _CAL_MAIN_LOOP     
     

_CALIBRATION_V2:
      SET1 PAC,5                 ;PA.5 as output, rest as input  => this pin should exist on all devices, same as RESET/ICVPP pin
      MOV A,0
_CAL_MAIN_LOOP:
      T1SN PA.6                  ;read bit from PA.6, increment IHRCR when low. Needs to be low for only one clock cycle!
      ADD  A,1
      SET1 PA,5                  ;output one clock cycle
      SET0 PA,5
      MOV IHRCR, A               ;write current A value to IHRCR tuning register
_CAL_WAIT
      T0SN PA.6                  ;read bit from PA.6, increment IHRCR when low. Needs to be low for only one clock cycle!
      GOTO _CAL_MAIN_LOOP     
      GOTO _CAL_WAIT

In your version you increment the tuning register with each clock output. This is way to fast to measure. The original version toggles the bit in a loop with same IHRCR value until host signals to change it.
EDIT: never mind, didn't see the SN instruction before the ADD  |O


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

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #445 on: January 16, 2019, 09:27:09 pm »
New idea:


_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
      SL A                       ;shit left A, set carry if msb was 1 before shift
      T1SN PA.6                  ;read bit from PA.6
      OR A,1                     ;set lowest bit (skipped when PA.6 is 0)
      SET0 PA.5                  ;set output of PA.5 to 0
      T0SN CF                    ;CF not set?
      GOTO _CAL_TOGGLE_LOOP
      GOTO _STARTUP_IHRCR


new tricks:
- we can jump around and reuse MOV IHRCR,A from startup code
- setup of A is now done via SPI like communication where IC is master and WRITER is slave:
   * PA.5 is clock (from IC)
   * PA.6 is MISO (data coming into IC)
   * whenever WRITER wants to setup a new IHRCR value it needs to send 9 bits with MSB set to 1, e.g. 0x153 => IHRCR will be set to 0x53
     (the 9th bit is detected by detecting an overflow in SL A (shift left instruction))
   * when WRITER wants to run the calibration loops it sends 0 all the time (SL A will never produce a carry)

=> 3 + 10 instructions now and we can set specific IHRCR value from host directly


JS
« Last Edit: January 16, 2019, 09:34:57 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 #446 on: January 16, 2019, 10:03:21 pm »
In your version you increment the tuning register with each clock output. This is way to fast to measure. The original version toggles the bit in a loop with same IHRCR value until host signals to change it.

Well, there are two versions in the code, V1 and V2. For the first version, a timed signal is needed on the input. This could be done by using a D-flipflop or SPI slave. Maybe a bit too much effort to save two words of memory...

The second version is two more words and will wait for the external input to change again.
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 80
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #447 on: January 16, 2019, 10:05:52 pm »
New idea:


Looks great! I love the trick of starting at 0xff to reuse the initialization value. Also much better to control the calibration value from the outside. This would allow to verify the setting. Otherwise there is a risk of bricking the device if there is a glitch during programming.

If you use CF=0 instead of CF=1 to signify a transmission you may be able to remove the MOV A,0?
« Last Edit: January 16, 2019, 10:07:38 pm by tim_ »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 177
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #448 on: January 16, 2019, 10:20:16 pm »
Looks great! I love the trick of starting at 0xff to reuse the initialization value. Also much better to control the calibration value from the outside. This would allow to verify the setting. Otherwise there is a risk of bricking the device if there is a glitch during programming.

If you use CF=0 instead of CF=1 to signify a transmission you may be able to remove the MOV A,0?

Hmm, I cant not see what you mean. I only see that the MOV A,0xFF is before the MOV IHRCR,A and can not be used to reset A. The reset is required after a byte was clocked in since A could still have 1/0 bits which could produce more carry flags at next shifts.

JS
« Last Edit: January 16, 2019, 10:21:49 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 #449 on: January 16, 2019, 10:28:08 pm »
Hmm, I cant not see what you mean. I only see that the MOV A,0xFF is before the MOV IHRCR,A and can not be used to reset A. The reset is required after a byte was clocked in since A could still have 1/0 bits which could produce more carry flags at next shifts.

Ah indeed, it's better to reset A. It would also be possible to shift out the current word, but that would result in a lot of intermediate clock setttings - probably too risky.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf