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

serisman and 2 Guests are viewing this topic.

Offline NickE

  • Contributor
  • Posts: 18
  • Country: hu
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1050 on: July 10, 2020, 11:27:49 am »
I wrote a very simple code again, after reset I put the clkmd register value to port B.

Code: [Select]
.rom
wdreset
mov a,#ffh
mov pbc,a
mov a,clkmd
mov pb,a
label1:
wdreset
nop
nop
nop
        goto label1

According to PFS154 datasheet clkmd value after reset should be: 0xF6
I read 0x9E

This means clock select type is 1, and clock mode is IHRC/64 = so 16MHz / 64 = 250kHz
If one instruction is executed in 2 cycles, and I did not calibrated the IHRC, that could answer the question why my PFS154 running at 143kHz

It's very annoying if we can not trust in the data sheet.
« Last Edit: July 10, 2020, 11:30:02 am by NickE »
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 235
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1051 on: July 10, 2020, 11:49:18 am »
I wrote a very simple code again, after reset I put the clkmd register value to port B.

Code: [Select]
.rom
wdreset
mov a,#ffh
mov pbc,a
mov a,clkmd
mov pb,a
label1:
wdreset
nop
nop
nop
        goto label1

According to PFS154 datasheet clkmd value after reset should be: 0xF6
I read 0x9E

This means clock select type is 1, and clock mode is IHRC/64 = so 16MHz / 64 = 250kHz
If one instruction is executed in 2 cycles, and I did not calibrated the IHRC, that could answer the question why my PFS154 running at 143kHz

It's very annoying if we can not trust in the data sheet.

The data sheet is also right... Usually PADAUK initializes the default values inside of the startup code they insert when you use the PADAUK IDE.
Since you use your own assembler / compiler you have to re-create the startup code and initializations.
BTW: PADAUK startup code wastes up to 10% of the valuable code memory.

Anyway, a good practice is to always set the complete value yourself.

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

Offline NickE

  • Contributor
  • Posts: 18
  • Country: hu
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1052 on: July 10, 2020, 12:14:47 pm »
Yeah, but this is very misleading even if Padauk IDE users won't experience this problem.
 

Offline kaweksl

  • Contributor
  • Posts: 14
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1053 on: July 10, 2020, 01:11:55 pm »
They expect that you use their IDE only, at least for now. Also in datasheet there is no information about some registers, like MISC_LVR, ROP, they are indirectly mentioned in "Code Options" chapter but without any address or 'how to'. I just wonder why ? Because this options shouldn't be changed after initialization ?, or maybe because this options differ to much between uC and they want maximum code compatibility.

Also anyone know how PADAUK see that whole open-source toolchain ? They gonna try support/kill it or maybe do nothing about it ?
 

Offline LovelyA72

  • Contributor
  • Posts: 21
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1054 on: July 10, 2020, 05:14:05 pm »
Also anyone know how PADAUK see that whole open-source toolchain ? They gonna try support/kill it or maybe do nothing about it ?

I don't think they'll kill this project. Larger companies that uses padauk product have to use their own "toolchain" because that's the only toolchain with official support.
Kashikoma!
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1169
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1055 on: July 11, 2020, 07:28:47 am »
Quote
What kind of video demo? A video from my hackintosh (intel NUC) starting up?
That would be nice, also other cool projects that you do, like the polysound demo >:D
I'm a Digital Expert from 8-bits to 64-bits
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 133
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1056 on: July 11, 2020, 09:22:59 am »
Also anyone know how PADAUK see that whole open-source toolchain ? They gonna try support/kill it or maybe do nothing about it ?

I don't know if they have any plans for it.
But they have been helping so far (answering techical questions, even on undocumented features, providing some free samples of devices that were at the time not yet available via the normal supply chains).
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1057 on: July 11, 2020, 11:23:14 am »
Just made one of Tim's lite programmers.
My first STM32 SMD soldering job, have only tried AVR SMD before  :phew:

Tim sent me two , and i totally screwed up the first one ... Tacked down 2 sides but began drag soldering on the tacked side  |O
MCU badly misaligned , and when trying to correct i badly bent 4 pins.

Well the 2'nd went ok i think , i can DFU program it w. the programer sw.

Now off to solder a PADA to a SMD-DIP board.

Edit: It's alive
Code: [Select]
./easypdkprog -v probe
Searching programmer... found: /dev/ttyACM3
FREE-PDK EASY PROG - Hardware:1.2 Firmware:1.2 Protocol:1.2
Probing IC... found.
TYPE:FLASH RSP:0xAA1 VPP=4.50 VDD=2.00
IC is supported: PFS154 ICID:0xAA1

/Bingo
« Last Edit: July 11, 2020, 01:14:31 pm by bingo600 »
 

Offline NickE

  • Contributor
  • Posts: 18
  • Country: hu
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1058 on: July 11, 2020, 12:46:14 pm »
I played with LVR settings yesterday, it works pretty well.

I know I have to load these values to misclvr register (0x1B)
0x00 - 4V
0x20 - 3.5V
0x40 - 3V
0x60 - 2.75V
0x80 - 2.5V
0xA0 - 1.8V
0xC0 - 2.2V
0xE0 - 2V

But I did not find info how security (MTP code protection), boot-up time, drive (IO low/normal driving) works, so the rest of Code Options chapter is unclear for me.
misc.5 controls the wake-up time but I am not sure it is the same thing what mentioned in Code Options chapter.
 

Offline kaweksl

  • Contributor
  • Posts: 14
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1059 on: July 11, 2020, 01:54:09 pm »
But I did not find info how security (MTP code protection), boot-up time, drive (IO low/normal driving) works, so the rest of Code Options chapter is unclear for me.
misc.5 controls the wake-up time but I am not sure it is the same thing what mentioned in Code Options chapter.

This might help you: https://github.com/free-pdk/easy-pdk-programmer-software/pull/30#issuecomment-650870921

Just made one of Tim's lite programmers.
My first STM32 SMD soldering job, have only tried AVR SMD before  :phew:

Tim sent me two , and i totally screwed up the first one ... Tacked down 2 sides but began drag soldering on the tacked side  |O
MCU badly misaligned , and when trying to correct i badly bent 4 pins.

Well the 2'nd went ok i think , i can DFU program it w. the programer sw.

Now off to solder a PADA to a SMD-DIP board.

Buy yourself good flux (paste/gel), it's unbelievable  what difference it can make, it's magic. I build 2 original programmers and i was struggling with first one, for 2nd i used better flux and it was smooth, soldered tqfp48 without using copper wick , joints nicely shine. Now i have programmer for stable and dev easy-pdk branch.
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1060 on: July 11, 2020, 05:22:52 pm »

Just made one of Tim's lite programmers.
My first STM32 SMD soldering job, have only tried AVR SMD before  :phew:

Tim sent me two , and i totally screwed up the first one ... Tacked down 2 sides but began drag soldering on the tacked side  |O
MCU badly misaligned , and when trying to correct i badly bent 4 pins.

Well the 2'nd went ok i think , i can DFU program it w. the programer sw.

Now off to solder a PADA to a SMD-DIP board.

Buy yourself good flux (paste/gel), it's unbelievable  what difference it can make, it's magic. I build 2 original programmers and i was struggling with first one, for 2nd i used better flux and it was smooth, soldered tqfp48 without using copper wick , joints nicely shine. Now i have programmer for stable and dev easy-pdk branch.

I did use good flux , and a Metcal Hoof.

But when you are foolish enough to dragsolder first "drag" on one of the sides tacked down , the package will move.
I did not make that mistake on the 2'nd board.

I might find my hot-air and remove the MCU. I doubt i'll spend time trying to save those bent pins. But i might get another MCU, when i have an order at LCSC.

/Bingo
 

Offline js_12345678_55AA

  • Regular Contributor
  • *
  • Posts: 235
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1061 on: July 11, 2020, 08:50:07 pm »
But I did not find info how security (MTP code protection), boot-up time, drive (IO low/normal driving) works, so the rest of Code Options chapter is unclear for me.
misc.5 controls the wake-up time but I am not sure it is the same thing what mentioned in Code Options chapter.

Some of those bits are encoded in "fuse bits" in last word of memory.

Here is example from PFS173 like I defined in PFS173.h in examples folder in programmer software:
#define FUSE_SECURITY_OFF  0x0001 //(S)
#define FUSE_SECURITY_ON   0x0000
#define FUSE_PB4PB5_NORMAL 0x0000 //(D)
#define FUSE_PB4PB5_STRONG 0x0100
#define FUSE_BOOTUP_SLOW   0x0000 //(B)
#define FUSE_BOOTUP_FAST   0x1800
#define FUSE_RES_BITS_HIGH 0x62FC // - 1 1 B   B 0 1 D   1 1 1 1   1 1 0 S => 0x62FC

All this can be learned from PFS173.INC from PADAUK IDE "INC_PDK" folder.


After you managed the fuses you also will need to find out how to tune the internal oscillator. Otherwise you will experience something like 6.5 MHz instead of 8MHz SYSCLOCK...

EASY PDK programmer defines placeholder macros (in assembly) for tuning which will be dynamically inserted and altered during programing.

Have a look at development branch for the macro definition: https://github.com/free-pdk/easy-pdk-programmer-software/blob/development/Examples/src/easypdk/pdkcommon.h 
and at https://github.com/free-pdk/easy-pdk-programmer-software/blob/development/Examples/src/easypdk/pfs173.h to see how they are used.


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

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1062 on: July 12, 2020, 07:28:36 am »
I just tried the two blinky's from here wo. IRQ & w. irq
https://github.com/free-pdk/free-pdk-examples

Edit: MCU type - PFS154-S16

My led blinks at a rate of approx 2 sec , it should be approx 1 sec.

I run @4.0v
Code: [Select]
Assumption (DS) IHRC  = 16MHz
SysClock = IHRC/16

Timer16 irq (bit8) - every  512 cycles

ticks every 16000000/512 = 31250 clock cycles    should be ~32uS


I'm toggling PB3 in the timer ISR , just to be able to put a scope on
Scope - PB3 toggle


Tick IHRC = 58,4uS
Tick sysclock = 888uS



Seems like Sysclock is set correct
Code: [Select]
                                    483 ; main.c: 64: AUTO_INIT_SYSCLOCK();
                                    484 ; genAssign
      00010A 1C 2F                  485 mov a, #0x1c
      00010C 83 01                  486 mov __clkmd, a

So is t16

Code: [Select]
      000000                        232 _millis_setup:
                                    233 ; ../include/millis.h: 29: T16M = (uint8_t)(T16M_CLK_IHRC | T16M_CLK_DIV1 | T16M_INTSRC_8BIT);
                                    234 ; genAssign
      000000 80 2F                  235 mov a, #0x80
      000002 86 01                  236 mov __t16m, a

I'm new @this MCU , and if i didn't know better , i'd say the MCU runs 8MHz or the divider is ???


Any tips

/Bingo
« Last Edit: July 12, 2020, 07:37:56 am by bingo600 »
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1063 on: July 12, 2020, 08:24:15 am »
Hmm

Replacing
AUTO_CALIBRATE_SYSCLOCK(TARGET_VDD_MV);

with

PDK_USE_FACTORY_IHRCR_16MHZ();           //use factory calibration value


Makes the tick's (timer irq)  34.40 uS wide

That's a lot closer to the 31.25 (Calculated value)

Is the AutoCalibrate always that "full" of surprises , and what if this wasn't a 154 or 173 (that has Factory IHCR value)

Using
//EASY_PDK_USE_FACTORY_IHRCR_16MHZ();           //use factory calibration value
Gives a compile error ... unknown



/Bingo
« Last Edit: July 12, 2020, 08:48:03 am by bingo600 »
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1064 on: July 12, 2020, 08:53:22 am »
What does this

487 ;   main.c: 70: AUTO_CALIBRATE_SYSCLOCK(TARGET_VDD_MV);
And forward do ??

It does a lot of magic w. accumulator a , but never saves it anywhere  - It just does that stuff , and then returns 0x00 in a.


Code: [Select]
                                    478 ; -----------------------------------------
                                    479 ; function _sdcc_external_startup
                                    480 ; -----------------------------------------
                                    481 ; Register assignment is optimal.
      00010A                        482 __sdcc_external_startup:
                                    483 ; main.c: 65: AUTO_INIT_SYSCLOCK();
                                    484 ; genAssign
      00010A 1C 2F                  485 mov a, #0x1c
      00010C 83 01                  486 mov __clkmd, a
                                    487 ; main.c: 70: AUTO_CALIBRATE_SYSCLOCK(TARGET_VDD_MV);
                                    488 ; genInline
      00010E 52 2C                  489 and a, #'R'                       
      000110 43 2C                  490 and a, #'C'                       
      000112 01 2C                  491 and a, #(1)           
      000114 40 2C                  492 and a, #((1000000))     
      000116 42 2C                  493 and a, #((1000000)>>8) 
      000118 0F 2C                  494 and a, #((1000000)>>16)
      00011A 00 2C                  495 and a, #((1000000)>>24)
      00011C A0 2C                  496 and a, #((4000))     
      00011E 0F 2C                  497 and a, #((4000)>>8) 
      000120 0B 2C                  498 and a, #(0x0b)             
                                    499 ; main.c: 82: return 0;   // Return 0 to inform SDCC to continue with normal initialization.
                                    500 ; genReturn
                                    501 ; genLabel
                                    502 ; peephole j0 removed unused label 00101$.
                                    503 ; main.c: 83: }
                                    504 ; genEndFunction
      000122 00 02                  505 ret #0x00


The :   483 ;   main.c: 65: AUTO_INIT_SYSCLOCK(); - is just as DS says for IHRC + sysclock 1MHz

 

Offline kaweksl

  • Contributor
  • Posts: 14
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1065 on: July 12, 2020, 10:45:41 am »
which programmer version you use ? (firmware and software)

What does this

487 ;   main.c: 70: AUTO_CALIBRATE_SYSCLOCK(TARGET_VDD_MV);
And forward do ??

(...)

It does a lot of magic w. accumulator a , but never saves it anywhere  - It just does that stuff , and then returns 0x00 in a.


It is placeholder for programmer. Before flashing, it search for that code, reads desired MHz, and voltage, and replace that code with calibration routine. After flashing programmer use that routine to calibrate clock (by measuring pin change frequency, and switching pin), after that, calibration value is written and most of calibration routine is overwritten with nop (with OTP you can clear bit but can't set bit)
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1066 on: July 12, 2020, 11:02:18 am »

I just found the "Magic sequence explanation"
https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2184683/#msg2184683

I'm using Tim's Lite Programmer

And  easypdkprog from git
Code: [Select]
easypdkprog -V
easypdkprog 1.2



So my programmer is supposed to do something magic wrt. calibration , i didn't know that before now (that i'm digging through the 40+ pages)

/Bingo
 

Offline kaweksl

  • Contributor
  • Posts: 14
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1067 on: July 12, 2020, 11:09:00 am »
I have tested blink example and for me it's working.

Led turn on for 1sec then turn off for 1sec giving period of 2 sec.
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1068 on: July 12, 2020, 11:29:06 am »
That is strange...

I'm getting a bit more than 2 secs in blink time.


I used this command for dfu loading the programmer :
Code: [Select]
$ dfu-util -d 0483:df11 -a "@Internal Flash  /0x08000000/064*0002Kg" --dfuse-address 0x08000000 -D EASYPDKPROG.bin
I have no idea what the -a parm does.



I soldered the Programer MCU my self , i can't say that i didn't make an error - Still SMD beginner.
Any hints on what MCU legs the calibrate uses , i could trace them to the "socket"

https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg3084420/#msg3084420

It might be an idea for the programmer sw. to write what calibration timing values it measured , and what calibration byte it wrote to the MCU.

/Bingo
« Last Edit: July 12, 2020, 11:37:22 am by bingo600 »
 

Offline kaweksl

  • Contributor
  • Posts: 14
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1069 on: July 12, 2020, 11:48:17 am »
From where did you get easy-pdk-programmer-software ?

Get latest development branch, compile it and flash programmer.
note that there is EASYPDKPROG.dfu not EASYPDKPROG.bin
 

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1070 on: July 12, 2020, 12:06:41 pm »
I'll give the DFU version a go

It's this one correct ?
https://github.com/free-pdk/easy-pdk-programmer-software/tree/development/Firmware
git clone https://github.com/free-pdk/easy-pdk-programmer-software.git


But i just noted this

https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2660004/#msg2660004
https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg2660682/#msg2660682

I have 100nF across VDD+GND like Ali , seems like it could be a bad thing , during programming.

Did program the programmer w. the dfu

Code: [Select]
$ dfu-util -d 0483:df11 -a "@Internal Flash  /0x08000000/064*0002Kg" --dfuse-address 0x08000000 -D EASYPDKPROG.dfu
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 29068
Download [=========================] 100%        29068 bytes
Download done.
File downloaded successfully

Still getting 2 sec between blinks.

Might try to remove the 100nF   

Removed the 100nF across the suppply lines on the PADA , didn't help.

Still ticks w 2 sec intervals.


I have just resoldered the SPI side of the Programmer MCU , all looks ok.

Still 2 Sec intervals

/Bingo
« Last Edit: July 12, 2020, 01:27:15 pm by bingo600 »
 

Offline cmfcmf

  • Contributor
  • Posts: 5
  • Country: de
    • github.com/cmfcmf
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1071 on: July 12, 2020, 07:06:19 pm »
I have written a "Digital I/O" and "Interrupts" section for the tutorial at https://free-pdk.github.io/tutorial.

I currently envision the tutorial page as the knowledge database for both the Easy PDK Programmer and using SDCC to program the µCs.

Since I have only started using Padauk µCs a couple of days ago, I obviously don't have as much experience and knowledge when it comes to all of the little details.
If some of you have some time, it would be super cool if you could also help by extending the tutorial.
Adding new content to the tutorial is as easy as clicking "Edit this page on GitHub" at the bottom of the page then editing the markdown file.

I think that currently "any content is better than no content": Even if you don't have used all the, for example, ADC functionality, writing a section about the basic ADC functionality and caveats you experienced already is a great start.

Below are two examples of behavior that I personally didn't know about up until now. This is exactly the kind of stuff that is great for the tutorial IMHO.


The data sheet is also right... Usually PADAUK initializes the default values inside of the startup code they insert when you use the PADAUK IDE.
Since you use your own assembler / compiler you have to re-create the startup code and initializations.
BTW: PADAUK startup code wastes up to 10% of the valuable code memory.

Anyway, a good practice is to always set the complete value yourself.

JS

which programmer version you use ? (firmware and software)

What does this

487 ;   main.c: 70: AUTO_CALIBRATE_SYSCLOCK(TARGET_VDD_MV);
And forward do ??

(...)

It does a lot of magic w. accumulator a , but never saves it anywhere  - It just does that stuff , and then returns 0x00 in a.


It is placeholder for programmer. Before flashing, it search for that code, reads desired MHz, and voltage, and replace that code with calibration routine. After flashing programmer use that routine to calibrate clock (by measuring pin change frequency, and switching pin), after that, calibration value is written and most of calibration routine is overwritten with nop (with OTP you can clear bit but can't set bit)
 

Online serisman

  • Regular Contributor
  • *
  • Posts: 90
  • Country: us
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1072 on: July 12, 2020, 10:55:40 pm »
I'll give the DFU version a go

It's this one correct ?
https://github.com/free-pdk/easy-pdk-programmer-software/tree/development/Firmware
git clone https://github.com/free-pdk/easy-pdk-programmer-software.git

...

Did program the programmer w. the dfu

Code: [Select]
$ dfu-util -d 0483:df11 -a "@Internal Flash  /0x08000000/064*0002Kg" --dfuse-address 0x08000000 -D EASYPDKPROG.dfu
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 29068
Download [=========================] 100%        29068 bytes
Download done.
File downloaded successfully

Still getting 2 sec between blinks.

...

I have just resoldered the SPI side of the Programmer MCU , all looks ok.

Still 2 Sec intervals

bingo600, it definitely sounds like you are not getting a successful calibration, and that is most likely why the timing is off.

As kaweksl has already indicated, this is most likely because the free-pdk-examples currently require the 'development' branch of the easy-pdk-programmer-software for successful calibration.  The calibration routines were changed compared to the previously released version (i.e. master).

You seem to have found the correct development branch, but it is unclear if you have actually re-complied the firmware and software.  Both are needed.  You can't just use the .dfu firmware from the development branch, as it hasn't been updated yet.  And, the easypdkprog software needs to be re-compiled as well.  You can't just use the previous 1.2 release.

When using the re-compiled .dfu firmware and the re-compiled easypdkprog you should get output like this (after running make program):
Code: [Select]
easypdkprog -n PFS154 write .output/BlinkLED_WithIRQ_PFS154.ihx
Erasing IC... done.
Writing IC (170 words)... done.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 4.00V ... calibration result: 997283Hz (0x84)  done.

If you are not seeing those last two lines, something is off, and the IC is not properly calibrated.

If it still isn't working after making sure you are using re-compiled firmware and software, can you post the results of running make program so we can troubleshoot further?
 

Offline NickE

  • Contributor
  • Posts: 18
  • Country: hu
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1073 on: July 13, 2020, 12:16:12 pm »
You may download my assembler and I wrote a small tutorial for it.
http://www.endresz.eu/padauk/padauk.html

Hope you will find it usefull!
 
The following users thanked this post: tim_

Online bingo600

  • Super Contributor
  • ***
  • Posts: 1478
  • Country: dk
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1074 on: July 13, 2020, 02:44:53 pm »
bingo600, it definitely sounds like you are not getting a successful calibration, and that is most likely why the timing is off.

As kaweksl has already indicated, this is most likely because the free-pdk-examples currently require the 'development' branch of the easy-pdk-programmer-software for successful calibration.  The calibration routines were changed compared to the previously released version (i.e. master).

You seem to have found the correct development branch, but it is unclear if you have actually re-complied the firmware and software.  Both are needed.  You can't just use the .dfu firmware from the development branch, as it hasn't been updated yet.  And, the easypdkprog software needs to be re-compiled as well.  You can't just use the previous 1.2 release.

When using the re-compiled .dfu firmware and the re-compiled easypdkprog you should get output like this (after running make program):
Code: [Select]
easypdkprog -n PFS154 write .output/BlinkLED_WithIRQ_PFS154.ihx
Erasing IC... done.
Writing IC (170 words)... done.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 4.00V ... calibration result: 997283Hz (0x84)  done.

If you are not seeing those last two lines, something is off, and the IC is not properly calibrated.

If it still isn't working after making sure you are using re-compiled firmware and software, can you post the results of running make program so we can troubleshoot further?


Yesssss

Did a new Pull
Seems like Devel & Master has been "alligned"

I'm not a GIT Guru - is the below url correct for a "Git clone" , or should i have used some kind of tag to get devel ??
This devel
https://github.com/free-pdk/easy-pdk-programmer-software/tree/development

Has this as git chekout (no devel in the name)
https://github.com/free-pdk/easy-pdk-programmer-software.git

Well

My git pull as of today @16:15
Code: [Select]
git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 5 (delta 2), reused 5 (delta 2), pack-reused 0
Unpacking objects: 100% (5/5), done.
From https://github.com/free-pdk/easy-pdk-programmer-software
   3a557cc..78983e5  master      -> origin/master
   be5ea01..78983e5  development -> origin/development
 * [new tag]         1.3         -> 1.3
Updating 3a557cc..78983e5
Checking out files: 100% (153/153), done.

My Firmware make
Code: [Select]
arm-none-eabi-size build/EASYPDKPROG.elf
   text    data     bss     dec     hex filename
  33176     488   13088   46752    b6a0 build/EASYPDKPROG.elf
arm-none-eabi-objcopy -O binary -S build/EASYPDKPROG.elf build/EASYPDKPROG.bin
cp build/EASYPDKPROG.bin build/EASYPDKPROG.dfu
dfu-suffix -v 0483 -p df11 -a build/EASYPDKPROG.dfu
dfu-suffix (dfu-util) 0.9

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Suffix successfully added to file

My dfu programming
Code: [Select]
$ dfu-util -d 0483:df11 -a "@Internal Flash  /0x08000000/064*0002Kg" --dfuse-address 0x08000000 -D EASYPDKPROG.dfudfu-util -d 0483:df11 -a "@Internal Flash  /0x08000000/064*0002Kg" --dfuse-address 0x08000000 -D EASYPDKPROG.dfu
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Downloading to address = 0x08000000, size = 33664
Download [=========================] 100%        33664 bytes
Download done.
File downloaded successfully


And Yipieee ..... Calibrating  ;D ;D ;D
Code: [Select]
$ make clean program
rm -r -f .build .output
sdcc -mpdk14 -c --std-sdcc11 --fverbose-asm --opt-code-size -DPFS154 -DF_CPU=1000000 -DTARGET_VDD_MV=4000 -I. -I../include -o .build/main.rel main.c
sdar -rc .build/lib.lib
sdcc -mpdk14 --out-fmt-ihx -o .output/BlinkLED_WithIRQ_PFS154.ihx .build/main.rel .build/lib.lib
makebin -p .output/BlinkLED_WithIRQ_PFS154.ihx .output/BlinkLED_WithIRQ_PFS154.bin
---------- Segments ----------
.  .ABS.                            00000000    00000000 =           0. bytes (ABS,CON)
.  .ABS.                            00000000    00000000 =           0. bytes (ABS,CON)
HEADER1                             00000000    00000002 =           2. bytes (ABS,CON)
HEADER3                             00000000    00000010 =          16. bytes (ABS,CON)
PREG2                               00000000    00000002 =           2. bytes (ABS,CON)
RSEG0                               00000000    00000002 =           2. bytes (ABS,CON)
DATA                                00000002    00000015 =          21. bytes (REL,CON)
HOME                                00000022    00000002 =           2. bytes (REL,CON)
GSINIT                              00000024    00000014 =          20. bytes (REL,CON)
GSFINAL                             00000038    00000002 =           2. bytes (REL,CON)
CODE                                0000003A    00000124 =         292. bytes (REL,CON)
SSEG                                FFFFFFFF    00000001 =           1. bytes (REL,CON)
------------------------------
Size of BlinkLED_WithIRQ_PFS154.bin: 350 bytes
easypdkprog -n PFS154 write .output/BlinkLED_WithIRQ_PFS154.ihx
Erasing IC... done.
Writing IC (175 words)... done.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 4.00V ... calibration result: 997066Hz (0x84)  done.


First time i ever saw Calibrating , when programming.

I have no idea what i did wrong , besides not specifying some magic git command on checkout.
And prob. being saved by master now updated to development.

A big thanx to @kaweksi and especially to @serisman for posting something usefull as the : Calibrating lines in the  output.
And thanx Tim for sending me to "Lite programmers" , and to JS... for making the website & examples.
And to all the others contributing to this , and SDCC.

But what did i do wrong ???
I never used the precompiled dfu , and made everything from source , even SDCC (That i in desparation now have installed in 3 versions , the 4.0 prebuilt , a Snapshot , and my own build from July-11) easy to switch if you use a symlink as the "Base dir".


Edit: easypdkprog still shows 1.2
Code: [Select]
$ easypdkprog -V
easypdkprog 1.2

/Bingo
« Last Edit: July 13, 2020, 02:52:22 pm by bingo600 »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf