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

0 Members and 2 Guests are viewing this topic.

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1200 on: September 30, 2020, 07:27:56 am »
Thanks JS, I have done it, But I have a problem, the MCU some times would not boot after applying voltage to it, I thought maybe adding LVR would solve it, But the problem still remains, Do you have any other  suggestion?

The PFS173 is powered from a DC/DC convertor, (the convertor has a slow startup voltage).
I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1201 on: October 01, 2020, 06:46:02 pm »
Thanks JS, I have done it, But I have a problem, the MCU some times would not boot after applying voltage to it, I thought maybe adding LVR would solve it, But the problem still remains, Do you have any other  suggestion?

The PFS173 is powered from a DC/DC convertor, (the convertor has a slow startup voltage).

Hard to diagnose this without more info. If I remember correctly similar problem was reported from tim? some posts ago.

Some things to try come to my mind:
- try to add a WDRESET instruction as early as possible in your code (I saw this in the standard PADAUK IDE startup code. For some reason they place WDRESET very early)
- disconnect PA.5 for testing (maybe you somehow trigger the programing sequence in case PA.5 gets a small voltage early - e.g. 2.5V on PA.5 and shortly after >4.5V on VDD could cause this).

For further assistance:
- could you create a minimal SDCC C program which has this behavior and share the source
- could you capture the voltage input to VDD pin of the MCU when your DC/DC starts up (oscilloscope trace)?
- could you capture the voltage input to PA.5 pin of the MCU when your DC/DC starts up (oscilloscope trace)?
- could you share the hardware setup / schematic which causes this behavior?


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

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1202 on: October 03, 2020, 08:18:13 am »
Dear JS
Thanks for your help, Unfortunately I have an analog oscilloscope, So I can not capture the wave form,

But I can share my code

Also This is the schematic, Note that Vin is coming from a secondary isolated winding from a flyback convertor.

I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1203 on: October 03, 2020, 11:48:07 am »
Dear JS
Thanks for your help, Unfortunately I have an analog oscilloscope, So I can not capture the wave form,
But I can share my code
Also This is the schematic, Note that Vin is coming from a secondary isolated winding from a flyback convertor.

I can't see anything wrong here.

But I just got an idea what could be the problem:

In case VDD slowly ramps up, the IC will start execution when VDD >= 1.8V. The IC itself can run with very low voltage BUT the max clock speed can not be 8MHz for SYSCLK then (check datasheet).

As a small test just add a delay right at the start of _sdcc_external_startup()   (before using EASYPDK init sysclock):

unsigned char _sdcc_external_startup(void)
{
  for(uint32 delay=10000;delay>0;delay--); //delay before switching to high clock, use higher / lower numbers to check different delays
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,4000);        //tune SYSCLK to 8MHz @ 4.000V
  return 0;
}

If this works you also might use ADC or internal COMP to measure VDD and wait before you switch to high sysclock (wait for VDD>=4.0 V)

If it still does not work, you should try to set the FUSE for SLOW IC startup (which I think uses even slower clock... until you reach the point where you setup sysclock yourself):

unsigned char _sdcc_external_startup(void)
{
  EASY_PDK_FUSE(FUSE_SECURITY_OFF|FUSE_BOOTUP_SLOW);
  for(uint32 delay=10000;delay>0;delay--); //delay before switching to high clock, use higher / lower numbers to check different delays
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,4000);        //tune SYSCLK to 8MHz @ 4.000V
  return 0;
}



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

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1204 on: October 03, 2020, 01:03:58 pm »
Thanks JS, But there is a wired error at compile time!

what's going on wrong?
I'm a Digital Expert from 8-bits to 64-bits
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1205 on: October 03, 2020, 01:07:26 pm »
I have changed the delay  variable name, Now it would compile, But It can not calibrate the chip!


I'm a Digital Expert from 8-bits to 64-bits
 

Offline kaweksl

  • Contributor
  • Posts: 17
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1206 on: October 03, 2020, 01:12:38 pm »
Probably calibration is timing out. Put calibrate function call before delay loop
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1207 on: October 03, 2020, 01:19:12 pm »
Probably calibration is timing out. Put calibrate function call before delay loop

NO, Please do NOT put calibration function before the delay. The purpose of the delay is to wait before setting up the higher sysclock which is needed to be done before calibration code.

Instead you can use the factory calibration for testing:

unsigned char _sdcc_external_startup(void)
{
  EASY_PDK_FUSE(FUSE_SECURITY_OFF|FUSE_BOOTUP_SLOW);
  for(uint32_t delay=10000;delay>0;delay--); //delay before switching to high clock, use higher / lower numbers to check different delays
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_USE_FACTORY_IHRCR_16MHZ();           //use factory calibration value
  return 0;
}


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

Offline kaweksl

  • Contributor
  • Posts: 17
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1208 on: October 03, 2020, 01:20:13 pm »
Maybe take a look at application note below. It clearly says that it's for PMC150/PMC153/  PMC156/PMC166 but who knows, maybe its 'bug' 'fixed' in orginal IDE .

http://www.padauk.com.tw//upload/ApplicationNote/PMC-APN006-PMC150_153_156_166_against_rapid_change_in_power_v003_EN_.pdf

Maybe create some minimal code that changes pin state (something like from above Application note oscilloscope plot) and make some tests.
« Last Edit: October 03, 2020, 01:24:33 pm by kaweksl »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1209 on: October 03, 2020, 01:25:54 pm »
Maybe take a look at application note below. It clearly says that it's for PMC150/PMC153/  PMC156/PMC166 but who knows, maybe its 'bug' 'fixed' in orginal IDE .

http://www.padauk.com.tw//upload/ApplicationNote/PMC-APN006-PMC150_153_156_166_against_rapid_change_in_power_v003_EN_.pdf

Maybe create some minimal code that changes pin state (something like from AN oscilloscope plot) and make some tests.

Not exactly matching the problem, but the suggestion to set INTRQ to 0 is a good one.

Looks like in case IC (auto) resets some bits of INTRQ might be / get set and in case the interrupt handler does not process (clear all INTRQ bits) interrupt will run for ever (after exit of interrupt, IC sees at least one INTRQ bit is (still) set and interrupt is executed again, ...)

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

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1210 on: October 03, 2020, 01:33:48 pm »
JS, The new changes would not do any calibration!



Can you confirm that the UART TX  can be put on PA6 pin, I'm using PFS173 8pin version

Regards
I'm a Digital Expert from 8-bits to 64-bits
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1211 on: October 03, 2020, 01:34:58 pm »
Quote
Not exactly matching the problem, but the suggestion to set INTRQ to 0 is a good one.

Looks like in case IC (auto) resets some bits of INTRQ might be / get set and in case the interrupt handler does not process (clear all INTRQ bits) interrupt will run for ever (after exit of interrupt, IC sees at least one INTRQ bit is (still) set and interrupt is executed again, ..
Where the INTRQ  should be 0?
I'm a Digital Expert from 8-bits to 64-bits
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1212 on: October 03, 2020, 01:49:56 pm »
JS, I'm testing in Breadboard, when I add anything more than these lines to _sdcc_external_startup, it would not boot


Code: [Select]
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,4000);        //tune SYSCLK to 8MHz @ 4.000V

But If I comment out the
Code: [Select]
  //EASY_PDK_FUSE(FUSE_SECURITY_OFF|FUSE_BOOTUP_SLOW);
  //for(int cnt=0;cnt<10000;cnt++);

It would work normally in breadboard!


The UART TX signal on PA6 when I have only  these codes in the startup

Code: [Select]
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,4000);        //tune SYSCLK to 8MHz @ 4.000V

I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1213 on: October 03, 2020, 01:59:41 pm »
JS, The new changes would not do any calibration!
This is correct. It uses FACTORY CALIBRATION VALUE so the programmer does not need to do calibration. This was what I wanted to do. Now you can put the delay inside and program the IC without problems.

==> Please test the IC with this setup. It should work perfectly.

======> Maybe the value in delay loop is much to high and you simply do not wait enough (remember IC startup speed is on ILRC which is some kHz instead of MHz!)

Can you confirm that the UART TX  can be put on PA6 pin, I'm using PFS173 8pin version
Regards

Sure, you can use any pin as output for serial TX (except PA.5 which is not a PUSH-PULL type, would need to add a pull up resistor for PA.5 as output).


Where the INTRQ  should be 0?

Just put a INTRQ = 0; anywhere in your code, just BEFORE you call __engint();  to enable interrupts.

JS
« Last Edit: October 03, 2020, 02:01:34 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1214 on: October 03, 2020, 02:14:26 pm »
JS, The old code would not do calibration either! it was doing it before


I have done one time this code
Code: [Select]
EASY_PDK_FUSE(FUSE_SECURITY_OFF|FUSE_BOOTUP_SLOW);Now I just have commented out
I'm a Digital Expert from 8-bits to 64-bits
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1215 on: October 03, 2020, 02:33:57 pm »
JS, I have found something new On my PCB board, when I flash the Chip, I think it maybe be reset after a short time,

Here is a wave capture of PA6 which is used as UART TXD @ 9600 baud,
Note the output would reset 1.77ms pulses!



I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1216 on: October 03, 2020, 06:05:04 pm »
JS, The old code would not do calibration either! it was doing it before
I have done one time this code
Code: [Select]
EASY_PDK_FUSE(FUSE_SECURITY_OFF|FUSE_BOOTUP_SLOW);Now I just have commented out

Not sure what you reference with old code and new code.
Your screenshot shows, that you do a DELAY and CALIBRATION => This can not work.

Please add the startup delay and use factory tuning (no calibration will be done by programmer):

unsigned char _sdcc_external_startup(void)
{
  for(uint32_t delay=10000;delay>0;delay--); //delay before switching to high clock, use higher / lower numbers to check different delays
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_USE_FACTORY_IHRCR_16MHZ();           //use factory calibration value
  return 0;
}


That should be your complete _sdcc_external_startup code. Do not add or remove anything. Just use this code. The only thing you should try is to change the value for delay (10000 or 1000 or 100 or ...) in order to shorten / increase your startup delay. In any case it should work exact like before you started changing the code, but I expect it performs better (no lockups when used with your DCDC) when you found the correct startup delay.

After thinking a bit more about the problem adding the LVR *before* the switch to higher clock rate also might solve the problem. I'm just not sure how long it takes for the new LVR to be effective (maybe a small delay after setting LVR is needed):

unsigned char _sdcc_external_startup(void)
{
  MISCLVR = MISCLVR_4V5;
  for(uint8_t delay=10;delay>0;delay--);        //small delay after setting LVR - before switching to high clock (maybe not needed)

  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,4000);        //tune SYSCLK to 8MHz @ 4.000V
  return 0;
}



JS
« Last Edit: October 03, 2020, 10:18:31 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1217 on: October 04, 2020, 07:14:08 am »
Thanks JS,
The Code does not make any calibration, No matter what I put in startup code, I have done all the possible combinations!
I'm a Digital Expert from 8-bits to 64-bits
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1218 on: October 04, 2020, 12:21:50 pm »
Thanks JS,
The Code does not make any calibration, No matter what I put in startup code, I have done all the possible combinations!

That's very strange, let's investigate.

First check: Please check that you use latest "pfs173.h"
You can verify when you look in pfs173.h and find the following lines:
//set calibration macros
#define EASY_PDK_CALIBRATE_IHRC(frequency,millivolt) EASY_PDK_CALIBRATE_RC_M( EASY_PDK_CALTYPE_IHRC, 0x0B, frequency, millivolt )


Next check: Do you use the latest version of easypdk prog?
You can check by adding the -v option to easypdkprog command line:
easypdkprog -v --icname=PFS173 write build/lvrstartup.ihx
Searching programmer... found: /dev/tty.usbmodem1234567855AA1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.3
Erasing IC... done.
Blank check IC... done.
Writing IC (1592 words)... done.
Verifiying IC... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 5.00V ... calibration result: 8021146Hz (0x80)  done.


I also found a mistake in the _sdcc_external_startup code.
* MISCLVR is set to trigger <= 4.5V
* calibration is done at 4000 mV = 4.0 V
==> this means calibration can not be done (should give an ERROR)

==> change calibration voltage to your target system voltage of 5V:


unsigned char _sdcc_external_startup(void)
{
  MISCLVR = MISCLVR_4V;

  EASY_PDK_INIT_SYSCLOCK_8MHZ();                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,5000);        //tune SYSCLK to 8MHz @ 5.000V
  EASY_PDK_USE_FACTORY_BGTR();                  //use factory BandGap tuning value (tuned @ 5.0V)
  return 0;                                     //perform normal initialization
}


I also made some experiments:

- when setting SYSCLOCK to 8MHz you need to have >=4.0V
- when you power the system with external power supply and slowly increase voltage from 0V to 5V  the IC *WILL HANG* (that's why the LVR should be added)
- adding the LVR setup just in front of the EASY_PDK_INIT_SYSCLOCK is enough to get a stable startup even when you slowly increase voltage from 0V to >=4.0V

unsigned char _sdcc_external_startup(void) {
  MISCLVR = MISCLVR_4V;                                                         //set minimum voltage for 8MHz sysclock (lower voltage will reset IC)
  EASY_PDK_INIT_SYSCLOCK_8MHZ();                                                //use 8MHz sysclock
  EASY_PDK_CALIBRATE_IHRC(8000000,5000);                                        //tune SYSCLK to 8MHz @ 5.000V
  return 0;                                                                     //perform normal initialization
}

Now I'm thinking if we should add setting LVR to the INIT_SYSCLOCK macro...



JS
« Last Edit: October 04, 2020, 12:58:06 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: tim_, I wanted a rude username, serisman

Offline pacmancoder

  • Contributor
  • Posts: 6
  • Country: ua
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1219 on: October 04, 2020, 06:40:29 pm »
Hello! I am having problems with reading 16-bit timer value using an open-source toolchain:
- When trying to read the T16C value directly in the code, I am receiving the "Unimplemented __sfr16 load" from SDCC.
- I tried to use line of ASM code "__asm__("ldt16 _clocksSpent");" (where clocksSpent is my global uint16_t variable name). This compiles for pdk13 (PMS150C), but when compiling for pdk15 (PFS173) I am getting the following linker error:
Code: [Select]
[build] ?ASlink-Warning-Invalid address for instruction
[build]          file              module            area              offset
[build]   Refby  CMakeFiles\spl    loop              CODE                   000050
[build]   Defin  CMakeFiles\spl    loop              DATA                   010000
[build]
I suspect that clocksSpent may be not word-aligned as LDT16 instruction requires and I just accidentally was being lucky when code successfully compiled for pdk13?
Does anyone have similar error? Is there are any workaround for this?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1220 on: October 04, 2020, 10:23:54 pm »
Hello! I am having problems with reading 16-bit timer value using an open-source toolchain:
- When trying to read the T16C value directly in the code, I am receiving the "Unimplemented __sfr16 load" from SDCC.
- I tried to use line of ASM code "__asm__("ldt16 _clocksSpent");" (where clocksSpent is my global uint16_t variable name). This compiles for pdk13 (PMS150C), but when compiling for pdk15 (PFS173) I am getting the following linker error:
Code: [Select]
[build] ?ASlink-Warning-Invalid address for instruction
[build]          file              module            area              offset
[build]   Refby  CMakeFiles\spl    loop              CODE                   000050
[build]   Defin  CMakeFiles\spl    loop              DATA                   010000
[build]
I suspect that clocksSpent may be not word-aligned as LDT16 instruction requires and I just accidentally was being lucky when code successfully compiled for pdk13?
Does anyone have similar error? Is there are any workaround for this?

Looks like "__sfr16 load" is not implemented by SDCC (PDK13/PDK14/PDK15 are all affected).
Need to file a bug report to SDCC compiler project: https://sourceforge.net/p/sdcc/bugs/

Workaround:
Your __asm code as replacement is correct and compiles for all processors. But like you already found out it is required to have a WORD aligned variable.

* you can either word align the variable (place all your word variables (uint16_t) at the top of your source file (as global variables)

* or you use the compiler virtual "p" register in your assembly (the "p" register is just a reserved word at memory position 0/1, designed exactly for this kind of purpose - always have at least one word aligned variable):

  uint16_t clocksSpent;
  ...
  __asm__("ldt16 p               \n"
          "mov a, p              \n"
          "mov _clocksSpent, a   \n"
          "mov a, p+1            \n"
          "mov _clocksSpent+1, a \n");


I expect that the sfr16 load implementation will produce same assembly as above when added to SDCC

JS


« Last Edit: October 04, 2020, 10:25:31 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 

Offline pacmancoder

  • Contributor
  • Posts: 6
  • Country: ua
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1221 on: October 05, 2020, 07:14:05 am »
Thanks, JS!
Yes, moving around variable declarations helps, works great as a temporary solution!

The second way (with virtual p register) seems more reliable, though. The only concern I have here is that I may accidentally clobber the previous (potentially important) p,a,f register values when running inline assembly? I suppose, additional push af / pop af and push/pop of with p register value may be required? Or p/a/f registers can be overwritten by the inline assembly without any consequences?
Code: [Select]
; save context
push af
mov a, p
push af
mov a, p + 1
push af
; load TM16C
ldt16 p
mov a, p
mov _clocksSpent, a
mov a, p+1
mov _clocksSpent+1
; restore context
pop af
mov p + 1, a
pop af
mov p, a
pop af
However, if additional context saving is required, 13 cycles to load the word feels pretty slow in comparison to single ldt16 instruction. Maybe in the end, it is better to just move variable declarations around  :-\
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1222 on: October 05, 2020, 08:03:21 am »
Thanks, JS!
Yes, moving around variable declarations helps, works great as a temporary solution!

The second way (with virtual p register) seems more reliable, though. The only concern I have here is that I may accidentally clobber the previous (potentially important) p,a,f register values when running inline assembly? I suppose, additional push af / pop af and push/pop of with p register value may be required? Or p/a/f registers can be overwritten by the inline assembly without any consequences?
Code: [Select]
; save context
push af
mov a, p
push af
mov a, p + 1
push af
; load TM16C
ldt16 p
mov a, p
mov _clocksSpent, a
mov a, p+1
mov _clocksSpent+1
; restore context
pop af
mov p + 1, a
pop af
mov p, a
pop af
However, if additional context saving is required, 13 cycles to load the word feels pretty slow in comparison to single ldt16 instruction. Maybe in the end, it is better to just move variable declarations around  :-\

As soon as you use a __asm statement the compiler treats the values of a, f and p as "dirty" so no extra context saving required.

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

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1223 on: October 05, 2020, 09:49:49 am »
Quote
First check: Please check that you use latest "pfs173.h"
You can verify when you look in pfs173.h and find the following lines:
//set calibration macros
#define EASY_PDK_CALIBRATE_IHRC(frequency,millivolt) EASY_PDK_CALIBRATE_RC_M( EASY_PDK_CALTYPE_IHRC, 0x0B, frequency, millivolt )
The file is the latest version


Quote
Next check: Do you use the latest version of easypdk prog?
You can check by adding the -v option to easypdkprog command line:
easypdkprog -v --icname=PFS173 write build/lvrstartup.ihx
Searching programmer... found: /dev/tty.usbmodem1234567855AA1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.3
Erasing IC... done.
Blank check IC... done.
Writing IC (1592 words)... done.
Verifiying IC... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 5.00V ... calibration result: 8021146Hz (0x80)  done.

This is the output, it looks it's older, I will update and let you know the results
I'm a Digital Expert from 8-bits to 64-bits
 

Offline ali_asadzadeh

  • Super Contributor
  • ***
  • Posts: 1507
  • Country: ca
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1224 on: October 05, 2020, 10:05:05 am »
JS,The problem is solved, the files version was old, But I think you should put the MISCLVR = MISCLVR_4V; in startup for stable operation.
Big Thumbs up :-+
I'm a Digital Expert from 8-bits to 64-bits
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf