EEVblog #1144 - Padauk Programmer Reverse Engineering

[EEVblog]

I'm trying to buy the parts from the BOM file in the github and it seems it's for LCSC, but when I load the CSV into LCSC using their BOM tool it's just a mess.
Anyone know why?
It is because it's semicolon delimited instead of coma delimited?
Thanks.

[EEVblog]

I'm trying to buy the parts from the BOM file in the github and it seems it's for LCSC, but when I load the CSV into LCSC using their BOM tool it's just a mess.
Anyone know why?
It is because it's semicolon delimited instead of coma delimited?
Thanks.

I downloaded the LCSC BOm template and manually copied everything over and it's still a mess when I import it into LCSC 

Turns out there is a bug in the LCSC BOM. It re-loads the previous (incorrect) file even when you try and upload a new one. You have to restart the web page.

XLS BOM attached in LCSC format

[js_12345678_55AA]

I downloaded the LCSC BOm template and manually copied everything over and it's still a mess when I import it into LCSC 

Turns out there is a bug in the LCSC BOM. It re-loads the previous (incorrect) file even when you try and upload a new one. You have to restart the web page.

XLS BOM attached in LCSC format

Hi,

Thanks for bringing this up. Looks like export/import from EasyEDA / LCSC is language dependent (my language uses semicolons in CSVs, so maybe that's why it was working for me).

I added your excel file to the github repository. This should be always working now.


For simplicity I suggest that you order a SOP socket (keep an eye on the spacing of the pin headers, some are narrow, some are wide).
This one should work: https://www.aliexpress.com/item/32890300159.html

This can be used with all SOP versions of PMC150C / PFS154 / PFS173 / ... and fits directly on top of the programmer.

Have fun,

JS

[ali_asadzadeh]

JS I made progress! I have soldered a 8MHz crystal to the board and now it can Erase the part ok, But when I read it, it says "Could not read data from programmer"
 


what should I do?

[js_12345678_55AA]

JS I made progress! I have soldered a 8MHz crystal to the board and now it can Erase the part ok, But when I read it, it says "Could not read data from programmer"

Hi,

It already looks very good!
The read command already executed correctly ("Reading IC... done."). This means the programmer was able to read out the IC into its internal buffer.

The error you get is from USB communication only. The command to get the data from programmer back to your PC failed for some reason (it just sends more data then the previous commands).

Did USB disconnect in this moment (observe in device manager if device disappears when you do the read).
If so, I would suggest to inspect the 8MHz crystal soldering and the 2 small caps next to the crystal. USB is very picky with the 48MHz bus clock speed and possible drifts.

Another possibility could be a bad USB cable / bad USB hub / ... Easiest way to find out is to connect the programmer directly to the computer and / or try it on another computer. Then you know it is either the programmer or something else.

EDIT: A friend of mine reported the same problem on Windows 10... I will have a look later. Maybe your programmer works correct already.

You are almost there.

Update: I was able to reproduce the problem and added a fix for Windows. New development version (and release) will not give this strange error anymore:

https://github.com/free-pdk/easy-pdk-programmer-software/releases

JS

[ali_asadzadeh]

Dear JS, Thanks for your help and support, big thumbs up
Now it's working, my Design did not have any problem, it was just not soldering the crystal, so you can now add my Altium files to the repo if you want

Also Now is the time to do some programming...

how to get started with SDCC for PFS173, I see your examples and they are for PFS154, is there something that I should change?

[spth]

how to get started with SDCC for PFS173, I see your examples and they are for PFS154, is there something that I should change?

Despite having -pfs154 in the name, both hello-pfs154 and count-pfs154 are written to work on both: When using sdcc -mpdk14 they get compiled for PFS154, when using sdcc -mpdk15 they get compiled for PFS173.

Philipp

[ali_asadzadeh]

Thanks, I have done two project successfuly, JS I think I have found another bug in the PC software

I have modified the Hello example to output the UART on the PA.7 port, so after starting easypdkprog, it should capture the UART data, it can not get the UART data for now, But I have connected an external UART Bridge(FT230x) to it and it's putting data on the line,


here is the Modified code for PFS173.

Code: [Select]

// "Hello, world!" for the Padauk PFS154, to be compiled with SDCC.
// Repeatedly outputs the string "Hello, World!" at 9600 baud on pin 0 of Port A.
// Written by Philipp Klaus Krause in 2019.
// Source code under CC0 1.0.

// Output on PA0 at 1200 baud.

#include <stdbool.h>
#include <stdio.h>

volatile unsigned char sendcounter;
volatile unsigned int senddata;
volatile bool sending;

//PFS173 SFR's
__sfr __at(0x00) flag;
__sfr __at(0x02) sp;
__sfr __at(0x03) clkmd;
__sfr __at(0x04) inten;
__sfr __at(0x05) intrq;
__sfr __at(0x06) t16m;
__sfr __at(0x0a) eoscr;
__sfr __at(0x0b) ihrcr;
__sfr __at(0x0c) integs;
__sfr __at(0x0d) padier;
__sfr __at(0x0e) pbdier;
__sfr __at(0x0f) pcdier;
__sfr __at(0x10) pa;
__sfr __at(0x11) pac;
__sfr __at(0x12) paph;
__sfr __at(0x13) pb;
__sfr __at(0x14) pbc;
__sfr __at(0x15) pbph;
__sfr __at(0x16) pc;
__sfr __at(0x17) pcc;
__sfr __at(0x18) pcph;
__sfr __at(0x19) pbpl;
__sfr __at(0x1a) pcpl;
__sfr __at(0x20) adcc;
__sfr __at(0x21) adcm;
__sfr __at(0x22) adcr;
__sfr __at(0x24) adcrgc;
__sfr __at(0x26) misc;
__sfr __at(0x2b) gpcc;
__sfr __at(0x2c) gpcs;
__sfr __at(0x30) tm2c;
__sfr __at(0x31) tm2ct;
__sfr __at(0x32) tm2s;
__sfr __at(0x33) tm2b;
__sfr __at(0x34) tm3c;
__sfr __at(0x35) tm3ct;
__sfr __at(0x36) tm3s;
__sfr __at(0x37) tm3b;
__sfr __at(0x40) pwmg0c;
__sfr __at(0x41) pwmgclk;
__sfr __at(0x42) pwmg0dth;
__sfr __at(0x43) pwmg0dtl;
__sfr __at(0x44) pwmgcubh;
__sfr __at(0x45) pwmgcubl;
__sfr __at(0x46) pwmg1c;
__sfr __at(0x48) pwmg1dth;
__sfr __at(0x49) pwmg1dtl;
__sfr __at(0x4c) pwmg2c;
__sfr __at(0x4e) pwmg2dth;
__sfr __at(0x4f) pwmg2dtl;

void send_bit(void) __interrupt(0)
{
	// Reset interrupt request, proceed only if we had a timer interrupt.
	if(!(intrq & 0x40))
	{
		intrq = 0x00;
		return;
	}
	intrq = 0x00;

	if(!sending)
		return;

	if(senddata & 1)
		pa = 0x80;
	else
		pa = 0x00;
	
	senddata >>= 1;

	if(!--sendcounter)
	{
		sending = false;

		inten &= ~0x40;
	}
}

int putchar(int c)
{
	while(sending);

	senddata = (c << 1) | 0x200;

	sendcounter = 10;

	tm2ct = 0;

	sending = true;

	inten |= 0x40;

	return (c);
}

unsigned char _sdcc_external_startup(void)
{
#ifdef __SDCC_pdk15
	ihrcr = *((const unsigned char*)(0x8bed)); // Use PFS173 factory calibration value for IHRC at 16 Mhz.
#else
	ihrcr = *((const unsigned char*)(0x87ed)); // Use PFS154 factory calibration value for IHRC at 16 Mhz.
#endif

	clkmd = 0x34; // Use IHRC / 2 = 8 Mhz for system clock, disable watchdog.
	clkmd = 0x30; // Disable ILRC

	return 0; // perform normal initialization
}

void main(void)
{
	// Set timer 2 for interrupt for 1200 baud.
	tm2c = 0x10; // Use CLK (8 Mhz)
	tm2s = 0x06; // Divide by 6 + 1 ~> 1142857 Hz
	tm2b = 118;  // Divide by 118 + 1 ~> 9604 Hz
	inten = 0x40;
__asm
	engint
__endasm;

	pac = 0x81;

	for(;;)
	{
		printf("ASiDesigner!\r\n");
		for(unsigned long int i = 0; i < 150000; i++); // Wait approx. 3s.
	}
}

Also I have another question, is it possible to run the device @ 16MHz, I have changed the clkmd =0x54; and it's certainly running @ 8MHz.

[ali_asadzadeh]

Does the printf accept additional arguments?

Code: [Select]

printf("ASiDesigner! %d\r\n",k);
k++;

if Not,I suppose we write something like this library for AVR (General purpose numeral output module)  form http://elm-chan.org/docs/avrlib/xitoa.zip
Unfortunately it's in AVR asm, But it should be some way of porting it to PADAUK.

[js_12345678_55AA]

I have modified the Hello example to output the UART on the PA.7 port, so after starting easypdkprog, it should capture the UART data, it can not get the UART data for now, But I have connected an external UART Bridge(FT230x) to it and it's putting data on the line,

There is no "BUG" with easypdkprog. EasyPDK programmer features AUTO-BAUD-DETECTION which requires to send 0x55 as first character followed by at lest 4 extra stop bits (or a small delay) to internally apply the baud rate.
It is reported to work fine with baud rates up to 1.5 Mbit.

I'm working on a clean "Hello World!" example project, which will be included in easypdkprog release.

Also I have another question, is it possible to run the device @ 16MHz, I have changed the clkmd =0x54; and it's certainly running @ 8MHz.

How did you measure the internal clock speed? Serial port implementation in the sdcc-example program which you used is based on IHRC directly, not on SYSCLK, This means baud rate will not change when you change SYSCLK.

Does the printf accept additional arguments?

Yes it does. Most likely the SDCC library is not compiled as "small" so the full printf (including support for width adjustments, leading spaces / zeros / floats / ...) implementation simply does not fit in our ultra ultra small RAM.


JS

EDIT: It is included in the Release now: https://github.com/free-pdk/easy-pdk-programmer-software/releases/latest

[spth]

Also I have another question, is it possible to run the device @ 16MHz, I have changed the clkmd =0x54; and it's certainly running @ 8MHz.

I don't know. I've asked Padauk, but didn't get a reply yet.
For the PFS173, PMS133 and PMS134, the datasheets are contradictionary on that question. Section 6.3 vs. sections 5.4.2 and 5.4.5.

[ali_asadzadeh]

Thanks JS

[ali_asadzadeh]

Is there a way to tell how much flash and ram is used with SDCC?

[spth]

Is there a way to tell how much flash and ram is used with SDCC?

Flash is easy. Have a look at the .map file.
For RAM, in general, you'd have to solve the halting problem (the data from the .map file does not include RAM used for the stack).

[ali_asadzadeh]

Thanks,Is there a way to add it to the command prompt? using make to tell the flash usage?

[ali_asadzadeh]

Guys I have some Idea, is it possible to add easypdkprog into the SDCC tool's, I mean adding the executable's to the distribution,

Something like winAVR for AVR. they had put AVRDUDE in it.

Then we can make a generic make file with the programming command too, also If there is some way of adding the code generated examples for PADAUK IDE for USART send,receive, I2C, SPI, PS2 and ADC it would be very nice too. I think the AVR and winavr was a smart choice at that time and place,(you could easily change the CPU name and FPCU in make file) and also PADAUK are very similar to lower end AVR's, still cheaper tough

[spth]

Thanks,Is there a way to add it to the command prompt? using make to tell the flash usage?

If you don't use any custom segments, the const segment is last in Flash. So you could parse the line, e.g.

Code: [Select]

Area                                    Addr        Size        Decimal Bytes (Attributes)
--------------------------------        ----        ----        ------- ----- ------------
CONST                               0000106E    00000B16 =        2838. bytes (REL,CON)

with grep to get the start and size, then add them (e.g. using bc with ibase=16), then divide by 2 to get the size in words.

If you are just worried about exceeding the available Flash: The Linker will warn you about that (if you have a device that has the maximum Flash that the architecture supports).

[ali_asadzadeh]

Thanks, It's always beneficial to have some info, Today I'm working on embOS, such a great OS for Cortex M devices, though I have used a lot FreeRTOS and RTX, but now I prefer embOS simply because it would get much more info from inside the internal workings!

If we could have something like this, it would be very helpful

Program Size: Code=15080 RO-data=464 RW-data=284 ZI-data=4704 

can we have an OS on PAUDUK, something like this

http://www.femtoos.org/


or Am I dreaming

[spth]

can we have an OS on PAUDUK, something like this

http://www.femtoos.org/


or Am I dreaming

Maybe, but it probably would work only on the bigger devices. Maybe try porting a more leightweight OS, such as Atomthreads first?
It probably won't we worth using an OS on such a small device though.

[tim_]

Then we can make a generic make file with the programming command too, also If there is some way of adding the code generated examples for PADAUK IDE for USART send,receive, I2C, SPI, PS2 and ADC it would be very nice too. I think the AVR and winavr was a smart choice at that time and place,(you could easily change the CPU name and FPCU in make file) and also PADAUK are very similar to lower end AVR's, still cheaper tough

I started putting some things together. It will automatically compile&program and also output program length:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain

Still very much work in progress. Next step would be a smaller printf function. And we also need agreement on SFR names... My current favourite would be to use all capitals, like it is done for all other 8bit MCUs.

Regarding a multitaskting OS: I believe that is quite in contradiction to the "FPPA" paradigm. The idea of the Padauk MCUs is to do multithreading with deterministic timing in hardware. That is much more valuable than preemptive multitasking in software and requires little software overhead. Software based preemtive multitasking will not allow you to implement virtual periphery, as it is possible with the FPPA approach.

edit: Of course you could use one FPPA with a multitaksing OS and use other FPPAs for virtual periphery. Things are getting a tad bit complex then.

For those that are a bit more into computer architecture, you can find an introduction to XMOS below. This is based on similar ideas as the padauk FPPA.

https://www.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.18.4-DSP/HC23.18.410-XMOS-XS1-May_Xmos.pdf

[tim_]

Also I have another question, is it possible to run the device @ 16MHz, I have changed the clkmd =0x54; and it's certainly running @ 8MHz.

I don't know. I've asked Padauk, but didn't get a reply yet.
For the PFS173, PMS133 and PMS134, the datasheets are contradictionary on that question. Section 6.3 vs. sections 5.4.2 and 5.4.5.

Please let us know their response. I am getting the feeling that the PDK architecture is indeed a 2 cycle architecture. I was also fooled by the clock options initially. But then, there are some instruction that are very hard to efficiently implement in a 1 cycle architecture. For example the memory RMW-instructions (INC, many others). These would require a two port memory or would be very wasteful in ressources (f.e. double edge memory access).

[spth]

Regarding a multitaskting OS: I believe that is quite in contradiction to the "FPPA" paradigm. The idea of the Padauk MCUs is to do multithreading with deterministic timing in hardware. That is much more valuable than preemptive multitasking in software and requires little software overhead. Software based preemtive multitasking will not allow you to implement virtual periphery, as it is possible with the FPPA approach.

edit: Of course you could use one FPPA with a multitaksing OS and use other FPPAs for virtual periphery. Things are getting a tad bit complex then.

For those that are a bit more into computer architecture, you can find an introduction to XMOS below. This is based on similar ideas as the padauk FPPA.

https://www.hotchips.org/wp-content/uploads/hc_archives/hc23/HC23.18.4-DSP/HC23.18.410-XMOS-XS1-May_Xmos.pdf

Their current FPPA paradigm is not very compatible with C. It looks like they designed a non-parallel instruction set, and then just made some parallel devices.
SDCC currently does not support multiple FPPA.

For efficient parallelism for the Padauk µC, we'd need:
* Stack-pointer-relative addressing and better stack handling (I'm currently running some experiments - when you compile code with --stack-auto for the current architecure, code size triples)
* Synchronization. We would need at least a compare-and-swap instruction, and an xch withindirect addressing mode. Preferably also an idxadd variant of add M, a.

I believe I can add support for multiple FPPA to SDCC. But the generated code will be big and slow. For practical purposes, running a multitasking OS on a single FPPA would be more efficient.

[tim_]

Their current FPPA paradigm is not very compatible with C. It looks like they designed a non-parallel instruction set, and then just made some parallel devices.
SDCC currently does not support multiple FPPA.

For efficient parallelism for the Padauk µC, we'd need:
* Stack-pointer-relative addressing and better stack handling (I'm currently running some experiments - when you compile code with --stack-auto for the current architecure, code size triples)
* Synchronization. We would need at least a compare-and-swap instruction, and an xch withindirect addressing mode. Preferably also an idxadd variant of add M, a.

I believe I can add support for multiple FPPA to SDCC. But the generated code will be big and slow. For practical purposes, running a multitasking OS on a single FPPA would be more efficient.

I don't think true c-compatible paralellism was their ultimate goal. (They don't even provide a C-compiler...). Obviously that would have added a lot of additional complexity, as you point out.

The idea is probably to have specific tasks assigned to specific threads. For example one thread runs the SPI peripheral, a second one runs a control loop, while the main thread mostly sleeps and does housekeeping/reconfiguration. Each of these would reside in their own memory space with dedicated ressources and would use minimal inter-thread communication via pipes. This would keep synchronization overhead down a lot.

For SDCC, the main challenge would be to allow multiple main function to initialize each FPPA. Maybe that could be dont similar to interrupts? It would be up to the user to ensure that variables are not reused between different threads.

Of course, something needs to be done with the p-register. A very rigid approach would be to clearly assign each function to only one FPPA.

A more pragmatic approach, for now, would be to have C-code always stay on FPPA0 and use assembler for the others...

Regarding preemtive multitasking: Of course this would free up some of the synchronization headache, but then the usefulness would be quite limited compared to using multiple hardware threads.

[tim_]

Brainfuck, now also on Padauk:

https://github.com/cpldcpu/SimPad/tree/master/Toolchain/examples/pfs1xx_brainfuck

[oPossum]