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

0 Members and 2 Guests are viewing this topic.

Offline LovelyA72

  • Contributor
  • Posts: 43
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1325 on: April 22, 2021, 09:35:11 am »
Congratulations on the PMS150G!
Now the question is: how do we compile for PMS150G?
This chip contains a few additional features than PMS150C(e.g. PA5 can be used as a push-pull pin) but it runs slower(2MB).
Kashikoma!
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1326 on: April 22, 2021, 05:24:57 pm »
Congratulations on the PMS150G!
Now the question is: how do we compile for PMS150G?
This chip contains a few additional features than PMS150C(e.g. PA5 can be used as a push-pull pin) but it runs slower(2MB).

You program it just like any other IC.

Have a look in the "Examples" folder of easypdkprog. There you can find the "helloworld2mhz.c" program and in "Examples/src/easypdk" folder you have a fully adapted "pms150g.h" include file.

For example, if you want to setup PA5 as PP then you only have to set the correct FUSE value.

You can place this (after sysclock setup and calibrate):

unsigned char _sdcc_external_startup(void)
{
  EASY_PDK_INIT_SYSCLOCK_2MHZ();
  EASY_PDK_CALIBRATE_IHRC(2000000,4000);        //tune SYSCLK to 2MHz @ 4.000V
  EASY_PDK_FUSE(FUSE_SECURITY_OFF | FUSE_LVR_1V8 | FUSE_IO_DRV_NORMAL | FUSE_PA5OD_DISABLE | FUSE_BOOTUP_FAST);
  return 0;
}


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 #1327 on: April 30, 2021, 03:17:32 pm »
I think I found something strange regarding the "set1 M.n" instruction on the PDK13 (e.g. the  PMS150c). See the following example code:


.area OSEG (OVR,DATA)
tmp: .ds 22
var: .ds 1  ; 0x16

.area CSEG (CODE,ABS)
.org 0x0000
init:
   SET1   var, #3


Assemble it and disassemble it again:


sdaspdk13 -o test.rel test.asm
sdldpdk -ni test.ihx test.rel
dispdk 2A16 test.ihx

0x0000:   0x0376    SET1 [0x06].3


Notice that set1 should operate on memory location 0x16, but the disassembler thinks it works on address 0x06.

It gets even stranger when analyzing the code with ucsim (since i couldn't find a command to list instructions, setting the program counter to 0 shows the first instruction):


spdk -t PDK13 test.ihx
0>pc 0

 ? 0x000 0376 set0  54, #3


It thinks, it's set0 on 0x36!

Looking at the documentation (https://free-pdk.github.io/instruction-sets/PDK13), it looks like there was an error creating the table: the last two columns (constant and memaddr) are flipped in the header/body of the table (see attached screenshot). So which one is right?

Looking at the documentation at least made me realize that set1 M.n can only work on the first 16 SRAM-addresses. Given that, I think the assembler (or linker) should give an error here. Or is there something else going on?

edited to add: the 4-bit limitation is not mentioned in the datasheet, afaict.
« Last Edit: April 30, 2021, 03:45:42 pm by gir »
 

Offline gir

  • Contributor
  • Posts: 16
  • Country: at
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1328 on: April 30, 2021, 04:36:59 pm »
Also, ucsim seems to not handle 't0sn IO.n'? the first example sets flag.zero, the second example clears it (this seems to work, looking at the Flag= output of ucsim). But in both cases ucsim continues execution with the next instruction (the goto)?!

Code: [Select]
mov a, #0
and a, #1
t0sn f, z
goto foo
        Flag= 0x01(  1)
         ? 0x040 0c00 t0sn  [0], #0
        Flag= 0x01(  1)
         ? 0x041 1845 goto  #69
mov a, #1
and a, #1
t0sn f, z
goto foo
        Flag= 0x04(  4)
         ? 0x040 0c00 t0sn  [0], #0
        Flag= 0x04(  4) 
         ? 0x041 1845 goto  #69
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1329 on: April 30, 2021, 10:29:55 pm »

Looking at the documentation (https://free-pdk.github.io/instruction-sets/PDK13), it looks like there was an error creating the table: the last two columns (constant and memaddr) are flipped in the header/body of the table (see attached screenshot). So which one is right?


The header is wrong. Should read |c|4-bit MEM addr|


Looking at the documentation at least made me realize that set1 M.n can only work on the first 16 SRAM-addresses. Given that, I think the assembler (or linker) should give an error here. Or is there something else going on?

edited to add: the 4-bit limitation is not mentioned in the datasheet, afaict.

Documentation says first 16 SRAM addresses can be used which translates to 4 bit for the address (4 bit can encode 16 addresses).
So why do you think "the 4-bit limitation is not mentioned in the datasheet, afaict."?

I agree that the assembler could bring up a warning / error in this case (you can create a ticket for sdcc developers).

Everything is working correct, just a missing warning.

SDCC (the c compiler) does not use this special instructions (since it can not predict if a variable will end up in the desired space).


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

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1330 on: May 01, 2021, 07:56:36 am »
Also, ucsim seems to not handle 't0sn IO.n'? the first example sets flag.zero, the second example clears it (this seems to work, looking at the Flag= output of ucsim). But in both cases ucsim continues execution with the next instruction (the goto)?!

Code: [Select]
mov a, #0
and a, #1
t0sn f, z
goto foo
        Flag= 0x01(  1)
         ? 0x040 0c00 t0sn  [0], #0
        Flag= 0x01(  1)
         ? 0x041 1845 goto  #69
mov a, #1
and a, #1
t0sn f, z
goto foo
        Flag= 0x04(  4)
         ? 0x040 0c00 t0sn  [0], #0
        Flag= 0x04(  4) 
         ? 0x041 1845 goto  #69

Are you sure the goto instruction is actually executed in both cases?

Like the real IC all of the ...SN (skip next) instructions, the next instruction is fetched regardless of the "skip" state. Just execution of the instruction will be controlled by the SN.

So you see the PC always "walk" over the next instruction, it just will be ignored or executed based on the "skip" state.


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 #1331 on: May 01, 2021, 12:32:28 pm »
Thank you for fixing the table, JS!

Quote
Documentation says first 16 SRAM addresses can be used which translates to 4 bit for the address (4 bit can encode 16 addresses).

Well, I can't seem to find it (looking at the PMS150c v1.08 datasheet), but I guess I just needed a place to vent, since I wasted too much time on this quirk.

Quote
I agree that the assembler could bring up a warning / error in this case (you can create a ticket for sdcc developers).

'll do!

Quote
Are you sure the goto instruction is actually executed in both cases?

yes, the simulator follows the jump and continues execution at the same place.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1332 on: May 02, 2021, 06:40:44 pm »
I'm very close to finish support for PFC154.

Unfortunately it turned out, that this and some other new ICs require VDD >6.2 V for writing:

PFC154: VDD write hv: 7.8V
PMS150G: VDD write hv: 7.8V
...

While PMS150G seems to write reliable with the maximum easypdk programmer can produce (6.2V), writing PFC154 needs >7.2V to reliably write all bits. Even multiple writes could not overcome this issue.

==> So it seems we need to do a hardware mod on the programmer in order to support those ICs.

The only change needed is to swap the resistor R6 from 20k to 6.8k.

I will add an auto detection so existing programmer can be used as is. Only if you want to write the specific ICs you need to do the change.

JS

EDIT: PFC154 support is done (-> development branch, requires new firmware build for programmer and hardware mod to get VDD to 7.0V => change R6 to 6.8k)
« Last Edit: May 03, 2021, 12:18:29 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: tim_, serisman

Offline gir

  • Contributor
  • Posts: 16
  • Country: at
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1333 on: May 03, 2021, 04:17:30 am »
My project is done, btw: https://gir.st/chiptunes.html | https://git.gir.st/Chiptunes-pms150c.git

It plays 16 minutes of chiptune music when it's plugged in and requires no external components (well, except a coin cell).
 
The following users thanked this post: js_12345678_55AA, tim_, serisman

Offline homeworkboy

  • Contributor
  • Posts: 15
  • Country: tw
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1334 on: May 05, 2021, 09:27:58 am »
Attached file "reload.zip"
It's io loop.

picture 1.  don't "A5A5A5A4" key

picture 2.  have "A5A5A5A4" magic key

PA3, P4, P5 connect to ardunio

It's generate "A5A5A5A4"
PA6 is PMG150C or PMG150G  clock source.
When  PA6 clock stop, then PA0, PA7  stop.
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1335 on: May 05, 2021, 12:45:23 pm »
Attached file "reload.zip"
It's io loop.

Not sure what you want to show here. When you use programing startup sequence (VPP first, then VDD, then PREAMBLE "A5A5A5A" and then COMMAND "4) your code will NOT be executed.
So why do you present your "reload.asm" program here?

picture 1.  don't "A5A5A5A4" key
picture 2.  have "A5A5A5A4" magic key
PA3, P4, P5 connect to ardunio
It's generate "A5A5A5A4"
PA6 is PMG150C or PMG150G  clock source.
When  PA6 clock stop, then PA0, PA7  stop.

Like I wrote before CMD4 seems to be some special new programming command with unknown behavior.

In case you do NOT send the PREAMBLE + CMD within a specific time then IC will boot normally. This might be what you observe here...

JS
« Last Edit: May 05, 2021, 04:13:55 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 #1336 on: May 06, 2021, 12:51:31 am »
Hi Js:
I want to say,Padauk to have such a function?
Or  Padauk can read the protected code

Hong
 

Offline tim_

  • Regular Contributor
  • *
  • Posts: 189
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1337 on: May 06, 2021, 04:57:21 am »
My project is done, btw: https://gir.st/chiptunes.html | https://git.gir.st/Chiptunes-pms150c.git

It plays 16 minutes of chiptune music when it's plugged in and requires no external components (well, except a coin cell).

Wow, this is really great! Love everything about it - the flexboard solution, actually thinking through the signal path for audio (many designs just drop the PWM stream somwhere :) ), plug in detection. Congrats!

 

Offline LovelyA72

  • Contributor
  • Posts: 43
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1338 on: May 11, 2021, 01:04:30 am »
Hi js

A quick question regarding the 16 bit timer.
In mini-c there's an instruction that called stt16. Which can set the value of T16 counter with one single 16 bit value(word). Is it possible to do so in Free PDK?

Thank you
Kashikoma!
 

Offline spth

  • Regular Contributor
  • *
  • Posts: 145
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1339 on: May 11, 2021, 10:34:58 am »
Hi js

A quick question regarding the 16 bit timer.
In mini-c there's an instruction that called stt16. Which can set the value of T16 counter with one single 16 bit value(word). Is it possible to do so in Free PDK?

Thank you

stt16 is an assembler instruction.

SDCC supports the functionality to some degree via __sfr16. If the support in SDCC isn't sufficient for you, you can use the stt16 assembler instruction, e.g. via inline asm in a C function, or by just writing some code in assembler and then linking it with the rest of your program.
 

Offline LovelyA72

  • Contributor
  • Posts: 43
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1340 on: May 12, 2021, 02:40:54 am »
__sfr16? Is that a macro or sth?
An example will be greatly appreciated.

Thank you
Kashikoma!
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1341 on: May 12, 2021, 08:49:06 am »
__sfr16? Is that a macro or sth?
An example will be greatly appreciated.

Thank you

Hi,

if you have a look in "https://github.com/free-pdk/easy-pdk-programmer-software/blob/master/Examples/src/easypdk/pfs154.h" for example you can see:

...
__sfr16          _t16c;
...
#define T16C      _t16c
...

This means you can access the T16 counter value in C code like this:

T16C = 0;

However code generation for this from sdcc-pdk compiler is not fully supported. There was a discussion in this thread for alternatives:

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

however using the virtual 'p' register was not a good choice:

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

and the conclusion from "pacmancoder" :

So for now, the most usable way of using ldt16/stt16 is to make sdcc to place uint16_t variables to the word aligned address by placing as the first items in the first translation unit as JS suggested, or by introducing the additional single byte variables before ldt16/stt16 operand variables if their address is non-aligned.

is the way to go.

Here a small example how it could work:

#define _STRINGIFY(x) #x
#define _STR_VAR(x) "_"_STRINGIFY(x)

uint16_t t16c_tmp;

#define __ldt16(var) __asm__( \
    "ldt16 _t16c_tmp\n"\
    "mov a, _t16c_tmp\n"\
    "mov "_STR_VAR(var)", a\n"\
    "mov a, _t16c_tmp+1\n"\
    "mov "_STR_VAR(var)"+1, a\n"\
  );

#define __stt16(var) __asm__( \
    "mov a, "_STR_VAR(var)"\n"\
    "mov _t16c_tmp, a\n"\
    "mov a, "_STR_VAR(var)"+1\n"\
    "mov _t16c_tmp+1, a\n"\
    "stt16 _t16c_tmp\n"
  );

...


in your code you could now do:

uint16_t myT16val;

__ldt16(myT16val); //load IC T16C register into myT16val

myT16val = 0x1234;

__stt16(myT16val); //store myT16val into IC T16C register



JS
« Last Edit: May 14, 2021, 07:31:21 am by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: LovelyA72

Offline LovelyA72

  • Contributor
  • Posts: 43
  • Country: us
  • Kashikoma from Massachusetts!
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1342 on: May 12, 2021, 02:19:30 pm »
Hi JS

Thanks for the code example! however, the code doesn't work as expected. No matter which value I wrote during the T16 interrupt, the frequency stayed the same.
T16C does work and can modify the frequency. However, it only worked with 8 bit values(as you said, it's not implemented. They should really implement the 16bit part of it. Since in Mini-C you can just do "stt16 a16BitValue;" and everything works)
I also saw this error during the compilation.
?ASlink-Warning-Invalid address for instruction
Code: [Select]
-------------- Build: Release in PWMBell154 (compiler: Small Device C Compiler)---------------

sdcc.exe -mpdk14  --opt-code-size  -std=c11   -IC:\Software\FreePDK\include -IC:\Software\sdcc\include -c main.c -o obj\Release\main.rel
sdcc.exe -LC:\Software\sdcc\lib -o bin\Release\PWMBell154.ihx -mpdk14  --opt-code-size  -std=c11    -lpdk14 obj\Release\main.rel
at 1: warning 118: option '-s' no longer supported  'use --code-loc instead'
?ASlink-Warning-Invalid address for instruction
         file              module            area              offset
  Refby  obj\Release\ma    main              CODE                   000078
  Defin  obj\Release\ma    main              DATA                   000007
at 1: warning 118: option '-s' no longer supported  'use --code-loc instead'
Process terminated with status 1 (0 minute(s), 0 second(s))
0 error(s), 1 warning(s) (0 minute(s), 0 second(s))
 
« Last Edit: May 12, 2021, 02:23:27 pm by LovelyA72 »
Kashikoma!
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1343 on: May 12, 2021, 06:46:23 pm »
Hi JS

Thanks for the code example! however, the code doesn't work as expected. No matter which value I wrote during the T16 interrupt, the frequency stayed the same.
T16C does work and can modify the frequency. However, it only worked with 8 bit values(as you said, it's not implemented. They should really implement the 16bit part of it. Since in Mini-C you can just do "stt16 a16BitValue;" and everything works)
I also saw this error during the compilation.
?ASlink-Warning-Invalid address for instruction
Code: [Select]
-------------- Build: Release in PWMBell154 (compiler: Small Device C Compiler)---------------

sdcc.exe -mpdk14  --opt-code-size  -std=c11   -IC:\Software\FreePDK\include -IC:\Software\sdcc\include -c main.c -o obj\Release\main.rel
sdcc.exe -LC:\Software\sdcc\lib -o bin\Release\PWMBell154.ihx -mpdk14  --opt-code-size  -std=c11    -lpdk14 obj\Release\main.rel
at 1: warning 118: option '-s' no longer supported  'use --code-loc instead'
?ASlink-Warning-Invalid address for instruction
         file              module            area              offset
  Refby  obj\Release\ma    main              CODE                   000078
  Defin  obj\Release\ma    main              DATA                   000007
at 1: warning 118: option '-s' no longer supported  'use --code-loc instead'
Process terminated with status 1 (0 minute(s), 0 second(s))
0 error(s), 1 warning(s) (0 minute(s), 0 second(s))
 
The warning suggests that you did not place the temp variable "uint16_t t16c_tmp;" at an even address (word alignment is needed for 16 bit access).
Maybe you defined some other variables (e.g. 1, 3, 5, 7, ... bytes) before that.
To make sure all your 16 bit variables are word aligned you can define them at the start of your main c code file, just before defining other variables.
In order to find the real cause it would be helpful to post a complete demo project / source code showing the problem.

BTW: Not sure why you want to write to the counter register of timer16 in order to change it's frequency. T16 frequency is specified via the scaler / pre scaler. In case you need finer control then you could use TM2 or TM3 with their "bound" register.
You also can use the interrupt (of a faster) timer to count a variable which then only triggers something when it reaches a specific value.

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

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1344 on: May 14, 2021, 10:33:56 am »
Hi,

we now have support for PFC232. A flash based "Multi-Core" IC (in development branch).  8) 8) 8)

I added a dual core example hello world:
* core 1 sends out the "Hello World!" string
* core 2 detects pin changes on incoming serial port and sets a flag
* when core1 sees the flag it will clear it and output a '2' (hello from core 2)

When you run the 2core hello world directly in easy pdk programmer it will capture and output the "Hello World!" and when you press a key on the host computer (which causes serial data to be sent, which causes pin changes detected by core2) you will get some '2' outputs:

./easypdkprog -n PFC232 write Examples/src/build/helloworld_2cores_pfc232.ihx -v
Searching programmer... found: /dev/tty.usbmodem1234567855AA1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.4 (1.3-40-g98c7c8d-dirty)
HWVAR:0 HWMOD:1
Erasing IC... done.
Blank check IC... done.
Writing IC (321 words)... done.
Verifiying IC... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 5.00V ... calibration result: 7949466Hz (0x70)  done.

./easypdkprog start
Running IC (5.00V)... IC started, press [Esc] to stop.
Connected @168421 baud
Press a key on the host computer to send some bits, core2 will detect this and core1 will output a '2' for every 1 bit
Hello World!
Hello World!
222222222222222222Hello World!
222222222222222222222Hello World!
Hello World!

IC stopped


==> BE AWARE: SDCC PDK compiler does not support code generation for parallel execution of functions. Our best chance is to use SDCC C code for core1 and write assembly code for all additional cores.

JS

P.S. Calibration seems a bit wrong. That's why it shows so high baud rate. I will have look at it.

Edit: Interesting... The 7 cycle calibration loop seems to take 10 cycles on this IC.
Where are the 3 extra cycles coming from ? ? ? The IC runs in "single core" mode during calibration.

Calibration loop is like this:

LOOP:
  SET1 IO(0x10).3  (PA.3)
  MOV IO(0x0B), A  (IHRCR)
  T0SN IO(0x10).4  (PA.4)
  ADD A, 0x01
  SET0 IO(0x10).3
  GOTO LOOP


Maybe it is from context switching between cores, even that FPPEN only activated core 1 during calibration?
When setting the fuse bit to use only 1 core then the above loop will take the exact 7 cycles.  ???

Looks like PDK IDE + WRITER also sets the (single core) fuse before calibration. I wonder what this fuse actually means...


EDIT2: During analyzing the PDK IDE stub inserted for PFC232 IC calibration I found 2 new undocumented instructions in 14 bit instructions set.
Most likely LDTABL and LDTABH  8) 8) 8) (like in 15 bit instruction set).

0   0   0   0   0   1   0   (7-bit MEM addr)  0    LDTABL M  :  A ← LowByte@CodeMem(M)  (last bit of M set to 0, M must be word aligned)

0   0   0   0   0   1   0   (7-bit MEM addr)  1    LDTABH M  :  A ← HighByte@CodeMem(M) (last bit of M set to 1, M must be word aligned)

8)  Very useful for lookup tables in code mem...
« Last Edit: May 14, 2021, 11:20:05 pm by js_12345678_55AA »
Easy PDK programmer and more: https://free-pdk.github.io
 
The following users thanked this post: tim_

Offline kaweksl

  • Contributor
  • Posts: 17
  • Country: pl
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1345 on: May 15, 2021, 11:42:32 am »
Hi,

we now have support for PFC232. A flash based "Multi-Core" IC (in development branch).  8) 8) 8)


Thanks for that.

Can you give some more details about that R6 mod witch is required for that to work ?

EDIT:

Ok, i found info that R6 have to be changed to 20k

« Last Edit: May 15, 2021, 01:47:12 pm by kaweksl »
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1346 on: May 16, 2021, 02:26:04 am »
Hi,

we now have support for PFC232. A flash based "Multi-Core" IC (in development branch).  8) 8) 8)


Thanks for that.

Can you give some more details about that R6 mod witch is required for that to work ?

EDIT:

Ok, i found info that R6 have to be changed to 20k

In fact R6 needs to be changed from 20k to 6.2k.

However, I was able to capture a "limited voltage" write (VDD max used 5V), which I will try to implement. Then no hardware mod is needed for this IC.


JS
« Last Edit: May 17, 2021, 08:06:45 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 #1347 on: May 20, 2021, 05:45:27 am »
Hello

I just read that the PFC232 can now also be used. Could anyone tell me, where you can buy this uC? I searched LCSC for it, but it seems the do not sell it right now.
 

Offline KaeTo

  • Contributor
  • Posts: 20
  • Country: de
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1348 on: May 20, 2021, 07:39:38 am »
And there is another question I have. For experimenting I use the PFS154, a breadboard and my lab bench power supply. It seems the uC has always problems and does not function as expected, if I enable the power output of my power supply. I have to apply power first and then put the uC on the breadboard or disconnect the power cable and connect it again.
I looked at the power on behavior. There are no peaks, only the loading curve of the output capacitors can be seen.
What could be the problem?
 

Offline js_12345678_55AA

  • Frequent Contributor
  • **
  • Posts: 297
  • Country: ht
Re: EEVblog #1144 - Padauk Programmer Reverse Engineering
« Reply #1349 on: May 20, 2021, 12:47:16 pm »
And there is another question I have. For experimenting I use the PFS154, a breadboard and my lab bench power supply. It seems the uC has always problems and does not function as expected, if I enable the power output of my power supply. I have to apply power first and then put the uC on the breadboard or disconnect the power cable and connect it again.
I looked at the power on behavior. There are no peaks, only the loading curve of the output capacitors can be seen.
What could be the problem?

Make sure you set setup LVR (Low Voltage Reset) in case you use a sysclock >= 2MHz.
In case you set a higher sysclock and your power supply is just ramping up (supplying like 2V) the IC starts up (using ILRC) but then locks up when switching to the higher clock (e.g. IHRC/2).

There was a discussion about this, some "pages" ago in this thread.

The examples which come with easy pdk programmer software include automatic setup of LVR based on clock frequency. Have a look at the Examples/src/easypdk headers, e.g.:
https://github.com/free-pdk/easy-pdk-programmer-software/blob/development/Examples/src/easypdk/pfs154.h
...
#define EASY_PDK_INIT_SYSCLOCK_8MHZ()       {_misclvr=MISCLVR_3V5;_clkmd=CLKMD_ENABLE_ILRC|CLKMD_ENABLE_IHRC|CLKMD_IHRC_DIV2;}

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


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf