Hi,
Today I started working on PFC154 (industrial part?) and to my surprise after analyzing the READ and WRITE I found:
PFC154 program word = 14 bits, but read / write using 19 bits.
5 extra bits are attached to the beginning of every program word. Some extra bits usually are for error corrections, lets' see..
Some samples from logic analyzer reading: 14 bit data => 5 extra bits:
3FFF => 1F
0070 => 08
2F00 => 0E
0182 => 04
First try: classic Hamming ECC
Confirmation by using this web site http://www.ecs.umass.edu/ece/koren/FaultTolerantSystems/simulator/Hamming/HammingCodes.html
After entering the binary 14 bit values from above, website will show result attached to the end of the bistring.
=> All matching! It is a classic Hamming ECC using the standard syndrom
It is a bit unexpected, but it looks like the "industrial grade parts" are really having some extra features.
JS
Today I started working on PFC154 (industrial part?) and to my surprise after analyzing the READ and WRITE I found:
[Original post for STM32 "mini-pill" (1/2 Blue Pill)]
...I decided to go ahead to create a bottom board... I call this the STM32 Mini-Pill. It is essentially 1/2 of the infamous "Blue-Pill" board...
[Original post for STM32 "mini-pill"/"blue-pill" Padauk Programmer Top Hat]
...I ended up creating a (mostly compatible) variation that is a top-hat for said boards...
>easypdkprog -v probe
Probing IC... found.
TYPE:FLASH RSP:0xAA1 VPP=4.50 VDD=2.00
IC is supported: PFS154 ICID:0xAA1
>easypdkprog -n PFS154 write Examples\helloworld_pfs154.ihx
Erasing IC... done.
Writing IC... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 4.00V ... calibration result: 7951482Hz (0x84) done.
>easypdkprog -n PFS154 -r 4.0 start
Running IC (4.00V)... IC started, press [Esc] to stop.
Hello World!
Hello World!
IC stopped
Here's a few more pictures.
I cleaned up the board-to-board connection, and removed the unused pins on the overhanging section of the IC socket. I kinda like leaving the overhang because it protects the otherwise exposed pins of the zif adapter.
Here's a few more pictures.
I cleaned up the board-to-board connection, and removed the unused pins on the overhanging section of the IC socket. I kinda like leaving the overhang because it protects the otherwise exposed pins of the zif adapter.
That looks like a very clean design! This should certainly be attractive for people who want to build and populate their own programmer. Maybe you should switch the two tiny diodes to larger ones, so it is still possible to work without a microscope
I love the puzzle and art of pcb design. I'm a bit jealous of being able to use 0603 or 0402 sized components, because it looks like they can really help shrink the board size further, and provide more layout options. But, I just find them too small to be worth trying to hand solder, and I am not ready to commit to automated assembly yet. If I make a second version of the programmer top hat, I will look into using larger sized diodes, but for now I have no use for any more programmer boards, so no incentive for a re-spin at the moment.
I also started my own repository to gather Padauk documentation, library files, and source code for my projects (https://github.com/serisman/Padauk). I don't mean to compete with anything you or JS or spth have done, but I needed to get some of what I was working on checked in and backed up so it wasn't just on my hard drive. At the very least it is a play area to try some things out slightly differently than the other repos.
I love the puzzle and art of pcb design. I'm a bit jealous of being able to use 0603 or 0402 sized components, because it looks like they can really help shrink the board size further, and provide more layout options. But, I just find them too small to be worth trying to hand solder, and I am not ready to commit to automated assembly yet. If I make a second version of the programmer top hat, I will look into using larger sized diodes, but for now I have no use for any more programmer boards, so no incentive for a re-spin at the moment.
I love it too, it's almost like meditation . You should look into the JLCPCB assembly service, it's probably much cheaper than you think.
I also started my own repository to gather Padauk documentation, library files, and source code for my projects (https://github.com/serisman/Padauk). I don't mean to compete with anything you or JS or spth have done, but I needed to get some of what I was working on checked in and backed up so it wasn't just on my hard drive. At the very least it is a play area to try some things out slightly differently than the other repos.
Well, I basically only have my own repository because my toolchain is a bit different from the one in the free-pdk repository. We should somehow all work together on cleaning that up and create better documentation so other people have a less steep learning curve. Maybe we could activate the Wiki on Github?
- I added a second pin header to allow plugging in wide breakout boards. More about this below. Unfortunately this means that the programmer will not fit into JS casing anymore without using a hacksaw... Let me know if you think this is a bad idea.
JS,
FYI... I just submitted a Pull Request (https://github.com/free-pdk/easy-pdk-programmer-software/pull/25) for adding preliminary support for PMS152 as well as fixed a few bugs that I found after researching the datasheets and Padauk IDE files. I tried to write a PMS152, after un-commenting the appropriate code in fpdkicdata.c and re-compiling easypdkprog. It seemed to mostly write correctly, but failed on calibration, and when read back, there are a few differences. So, it may require some more code changes in easypdkprog before it is fully supported. I already wasted two ICs before deciding to stop until someone more familiar with the code could take a look.
JS,
FYI... I just submitted a Pull Request (https://github.com/free-pdk/easy-pdk-programmer-software/pull/25) for adding preliminary support for PMS152 as well as fixed a few bugs that I found after researching the datasheets and Padauk IDE files. I tried to write a PMS152, after un-commenting the appropriate code in fpdkicdata.c and re-compiling easypdkprog. It seemed to mostly write correctly, but failed on calibration, and when read back, there are a few differences. So, it may require some more code changes in easypdkprog before it is fully supported. I already wasted two ICs before deciding to stop until someone more familiar with the code could take a look.
Hi,
Writing of PMS152 was never tested from me. I just copied some values around to have place holders. A capture with logic analyzer is needed to reveal full details.
=> Do you still have the exact same hex file you wrote and a read back from the IC?
Until now there was no demand for PMS152 so it was pushed back on my list.
But, since you really try to develop something for this IC and you also open sourced your project I'm more than motivated to put PMS152 on top of the list now
I had a brief look at your PMS152.h and it looks good.
Some things I noticed:
- it looks like you used the main branch as source since some of the unknown ROP defines are already deciphered and in development branch (see PFS173.h).
- you should try the H9 and L9 macro for IHRC/ILRC calibration since it might be that PADIER needs to be set explicit in order to get input (development branch has H9/L9 macros and easypdkprog has calibration code for H9/L9 14 bit).
=> You also should target your pull requests to the development branch.
JS
=> You also should target your pull requests to the development branch.
JS,
I re-targeted my pull request to the development branch, re-applied my mini-pill changes, re-build and uploaded the new 1.3 firmware, and re-compiled easypdkprog. But now I can't even probe OTP ICs (I tried both PMS150C and PMS152). Flash based ICs still seem fine (I can probe/erase/write/read to both PFS154 and PFS173). So, it seems like OTP support may be broken right now in the development branch. Can you duplicate this on your end?
>easypdkprog -n PMS152 write Examples\helloworld_pms152.ihx
Writing IC (186 words)... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 4.00V ... calibration result: 8006747Hz (0x4E) done.
>easypdkprog -n PMS152 -r 4.0 start
Running IC (4.00V)... IC started, press [Esc] to stop.
Hello World!
Hello World!
IC stopped
- you should try the H9 and L9 macro for IHRC/ILRC calibration since it might be that PADIER needs to be set explicit in order to get input (development branch has H9/L9 macros and easypdkprog has calibration code for H9/L9 14 bit).
- I added a second pin header to allow plugging in wide breakout boards. More about this below. Unfortunately this means that the programmer will not fit into JS casing anymore without using a hacksaw... Let me know if you think this is a bad idea.
I think different widths are a good idea. I personally don't think breakout boards are worth it (especially for the OTP types), but some people may prefer to work that way.
I think different widths are more interesting to fit different kinds of IC sockets, so sourcing fitting ones becomes easier. Currently you need ones with 7.62mm spacing, but some seem to me like they have 10.16mm spacing:
https://www.aliexpress.com/item/1107288077.html
I think you'd have to add another row for them, but that shouldn't be a problem.
As the case is 3d printed, I don't think it is an issue to change it.
- you should try the H9 and L9 macro for IHRC/ILRC calibration since it might be that PADIER needs to be set explicit in order to get input (development branch has H9/L9 macros and easypdkprog has calibration code for H9/L9 14 bit).
JS,
It looks like the 14 bit version is H10, not H9, and there is not yet a L10 equivalent. Does that seem correct? If so, I can add the L10 equivalent. Looks like we need a new equivalent of B1A for bandgap calibration as well.
Also, it looks like H10 starts off at 0x00 instead of 0xFF, meaning the first measured value is 0x01 instead of 0x00. Doesn't that mean the calibration value will also be off by one (or is that tweaked elsewhere)?
I'm wondering if we would be better off getting SDCC to add the PADIER=0xFF (and any other needed default overrides) as part of the initialization code so we don't have to have so many different calibration routines, and our programs can then rely on the same defaults across MCUs as well. I think the Padauk IDE already does it this way. Maybe if SDCC can't/shouldn't do it, we can find a way to insert it in the IC specific .h include files.
during development for PFS172 I found that using a value of 0xFF in IHRCR locked up the IC so I created the 10 variant (1 more instruction to start with 0 - the new offset is respected in calibration)
I think we should rework calibration to use the "works for all" 10 version for all IC variants, even if it "wastes" 2 instructions in code memory on some ICs.
I also plan to make a more generic calibration routine so we can specify the location of ILRCR and BGTR register as a parameter in tuning macro.
struct PORT_bits
{
uint8_t p0:1;
uint8_t p1:1;
uint8_t p2:1;
uint8_t p3:1;
uint8_t p4:1;
uint8_t p5:1;
uint8_t p6:1;
uint8_t p7:1;
}; // __attribute__((__packed__));
#define BF_PA (*(volatile struct PORT_bits *)&PA)
void main(void)
{
PAC |= _BV(LEDPIN); // This syntex will infer set0/set1
for (;;) {
BF_PA.p0=1;
// PA ^= _BV(LEDPIN); // Toggle LED
delay_ms(500);
BF_PA.p0=0;
delay_ms(500);
}
}
SDCC : gbz80/tlcs90/z80n/pic14/ds400/pdk13/pdk14/pdk15 4.0.2 #11683 (Linux)
260 ; bitfields.c: 55: BF_PA.p0=1;
000040 01 2F 261 mov a, #0x01
a 000042 262 or _pa+0, a
...
00004C FE 2F 270 mov a, #0xfe
a 00004E 271 and _pa+0, a
I got my dev boards in the mail today, and soldered one up with a PFS173-S16 this evening. I'll build another one with a PFS154-S16 later.
I did have to change the resistor on PA6 to 22k (instead of the 10k that the PA3,PA4,PA5 are able to use) in order to actually successfully program the IC through the header. The datasheet seems to indicate that 10k is all the isolation that's needed, but the characteristics of the easy-pdk-programmer must be different. Maybe the timing could be adjust to compensate? I'm not sure why the other pins seem fine with 'only' 10k resistors though.
The other 'issue' I noticed is that the programmer appears to be pulling PA5 low while it is connected, even while it is idle. This makes the code think that the button is always pressed (and the PA5 LED is always lit up). If the programmer is disconnected, it works properly. I think the programmer is trying to idle (i.e. high-z) the line, but the op-amp is pulling it low. I reported this as an issue in GitHub, but I'm not sure if anything can or
will be done about it. Possibly the easiest solution would be to allow the programmer to idle the PA5/VPP line high (maybe through an extra command line option with easypdkprog?).
I whipped up an example program that makes use of the on-board LEDs and BTN.
setPinOutput(PIN_LED2);
Code: [Select]setPinOutput(PIN_LED2);
Do we really have to copy the Arduino style? With bitfields (see above) we could directly turn individual pins into variables so you can write e.g. PA5=1;. The compiler should be able to generated optimal code once fixed.
Code: [Select]setPinOutput(PIN_LED2);
We, of course don't have to do anything. That code is easily changeable if/when something better is available.
If you don't like that, don't look at some of the more recent updates I just pushed.