EEVblog #1144 - Padauk Programmer Reverse Engineering

[tim_]

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

Interesting. So I guess that is a way to address potential biterorrs in their OTP. They must have seen some in-field failures.

There should be some kind of way to detect read errors. Maybe a flag in an I/O register?

[electronic_eel]

Today I started working on PFC154 (industrial part?) and to my surprise after analyzing the READ and WRITE I found:

Nice find, thanks for sharing.

I think more traditional bigger MCUs, like for example the STM32, also have an ECC protection for their flash. But I think their flash works on larger words, it is always accessed on something like 64 bits in parallel. So they have implemented the ECC for such a word and not for each single command. But given the more simplistic design of the PDKs, I think adding some extra bits for each command is a reasonable approach.

Do you also happen to have some PMC150 at hand to analyze?

They are available in my favorite package, SOT23-6, at LCSC. I might want to replace the PMS150C-U6 with them for some applications.

[serisman]

[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...

It works! (First try!)

I got my STM32 mini-pill board delivered last Saturday and the Top Hat Programmer board delivered yesterday (Monday).  My big LCSC order got delivered today (Tuesday).  Feels like Christmas!

I started by soldering together the STM32 "mini-pill".  Soldering the STM32F072CBT6 was slightly challenging (I bent some pins on the first try), but everything else went on smoothly, and all the footprints worked out well.  A few places are a little tight, but manageable.  I left off R5 (1k5) because it isn't needed by the STM32F072 (it would probably be needed if using this as a generic dev board with a STM32F103xxxx).  I also left off R6 and D1 (LED connected to PC13) because they are covered up and duplicated on the top hat anyway.  Holding down the BOOT0 button while plugging it in (or while pressing the RESET button) launched the STM32 DFU bootloader successfully on the first try!

Next, I soldered together the STM32 Progammer Top Hat.  No real challenges on this one, other than a lot of cross referencing resistor and capacitor values against the schematic.  The schottky diodes are smaller than expected, but ended up being easy enough to hand solder.  Once again, all the footprints worked out well, and there was sufficient space (although a little cramped) to hand solder everything.

Finally, (after a close inspection under the magnifying lens) I soldered on the female header pins for the IC socket and connected the two halves together with male header pins.  It's a little tall with ZIF socket plugged in, but clearances on everything seem fine.

I had to change two lines in the Firmware source code to point to the correct ADC pins on this hardware revision (PA0/1 instead of PB0/1).  It was as simple as replacing ADC_CHANNEL_8 with ADC_CHANNEL_0 and ADC_CHANNEL_9 with ADC_CHANNEL_1.  Compiling the changes and uploading with the DFU utility was fairly straightforward.

Imagine my happiness when I put a PFS154 in the ZIF socket and saw the following output after running the probe command!:

Code: [Select]

>easypdkprog -v probe
Probing IC... found.
TYPE:FLASH RSP:0xAA1 VPP=4.50 VDD=2.00
IC is supported: PFS154 ICID:0xAA1

Then, I uploaded the pre-compiled hello world example:

Code: [Select]

>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.

And started it up:

Code: [Select]

>easypdkprog -n PFS154 -r 4.0 start
Running IC (4.00V)... IC started, press [Esc] to stop.
Hello World!
Hello World!

IC stopped

I repeated the same steps for the PFS173 IC, which also worked perfectly on the first try.

THANK YOU to JS, and anyone else involved in bringing this open source programmer to life!

Now its time for the real fun to begin!

(I'll post my board design files soon)

[serisman]

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.

And, yes, as expected, it also works fine with a SOIC-8 test clamp.

They haven't shipped yet, but I am still hopeful that I will get my dev boards by the end of the week which should make this a little bit cleaner still.

I also tested and verified that the PMS150C and PMS152 are probing correctly as well.

[tim_]

Good news. After some components were stuck for more than 2 weeks at customs, I finally received all parts for the "Lite" Easypdkprog.

Just to recap: This is a redesign of the easypdkprog with some circuit simplifications and only based on "Basic components" at the JLPCB assembly service. This means that it is possible to buy almost completely assembled PCBs directly from JLCPCB for very little money.

A few parts have to be added manually, see picture below.



The fully assembled programmer is shown below. Form, fit and function are basically identical to the original one:



I tested the r0 samples and found them to be functional. See list of tests below. One change from the original design was to remove the negative OPAMP supply, therefore the idle voltage of VDD and VPP is slightly larger than 0V, but that does not really have practical implications.



I also looked at the load behavior of the new boost converter in more detail. The new one shows slightly more ripple when unloaded. This is not a big issue, since VPP and VDD ripple is defined by the opamp loop gain. However, it still does not look very nice and I noticed that I operate the device (FP6291) marginally. There is a slightly more expensive boost converter from TI (TPS61040) that I will probably switch to for the final version.



I still have a few r0 boards including components to share, let me know if you are interested. Please note that also the MCU has to be soldered manually on the R0 board. I will prepare a r1 run for the final and then add it to the github with ordering instructions.

currently planned changes for r1:
   - Adjust USB solder screen for easier soldering - avoid solder bridge between ground pins.
   - Move components around so JLCPBC can place their mounting holes properly. (Current positions can be seen on the PCB - not optimal)
   - Possibly switch to new boost converter
   - Add a second row of headers, so it will be possible plug in SOIC14/16 break-out boards directly into the programmer.
   - remove r1.2 mark in metallization to avoid confusion.

Any additional suggestions?

Edit: All the r0 boards are gone, but if anyone is interested in an r1 board from the next order, please let me know.

[tim_]

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

[tim_]

Ok, just sharing my design progress for the r1 version of the "lite" programmer with you. Please let me know what you think and if there are any proposals for changes.

I ended up changing far more than I initiatially intended.

• I switched most passives to 0402 parts. Since this design is clearly intended for automated assembly, there is no point staying with 0603. 0402 saves cost and space and allowed to clean up the layout a bit to make space for fiducial holes. Total cost reduction is around 10%, most coming from omitting the 22µF cap.
• I was a bit unhappy with the performance of the FP6291 boost converter. While it generally works, it has bad control of switching frequency leading to unnecessary ripple and I had to operate it at marginal voltages. I ended up going back to the MT3608 that is used in the original easypdkprog. Unfortunately that means that $3.00 has to be added as "extended part fee" for each build, eating up the 10% savings from above.
• 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 changed most inscriptions to silkscreen. The silkscreen resolution at JLCPCB turned out to be good enough for down to 0.8 mm text height and the contrast is actually much better than with metal defined text.

3D rendering of current design:



I designed minimum size breakout boards for all SO8 and SO16 flash variants of the Padauk MCUs. These can be plugged into the programmer for programming and can then be used on a breadboard. These should be quite convenient for prototyping. An optional LED allows quick validation of "blinky".

It turns out two different pinouts are needed to cover all types. See attached PDF for more details. The V-scoring is quite aggressive - let's see whether that works out.

[serisman]

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

Thanks tim_!

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 did release all my design files for the STM32 "mini-pill" board.
   https://github.com/serisman/stm32-mini-pill
   https://hackaday.io/project/173350-stm32-mini-pill

I haven't yet released the design files for the programmer top hat, mostly because I haven't decided where to release them yet, and I am having too much fun using the completed programmer.   

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.

This repo is still in a fairly bare state, but I did check in my source code for one full working project (a 'bare-minimum' 4-digit 7-segment digital clock) that I am pretty happy with (https://github.com/serisman/Padauk/tree/master/projects/7-seg-clock).  I don't have a write up for it yet, and it is just on a breadboard for the moment, but was a great proof of concept for the usefulness of these ultra cheap MCUs!  I'll eventually create a custom pcb for it and complete a write up.  The entire program uses less than 0.5KW of code and around 20 bytes of RAM, so it should fit on just about any Padauk MCU that has enough pins (currently using 14 IOs, so needs a 16-pin IC).  I have tested it with a PFS154-S16, but imagine it would work with no changes on a PFS173-S16 and probably even a PMS152-S16 (once we have write support available in easypdkprog).  There is a mix of mostly C code as well as a few methods with 'optimized' inline assembly.  The optimization wasn't really needed, but I wanted to get some experience with the Padauk instruction set and see how small/fast I could make some of the more 'critical' code sections.

Over half the code is just the 'UI' that allows setting the time on the clock.  There is a single button.  A short press when the HH:MM is displayed will briefly switch to show seconds.  A medium 1-2 second press will switch into config mode, where short presses will increment the currently selected time value, and medium presses will advance to the next digit, and long presses will exit config mode.

The BOM is pretty minimal: (1) PFS154-S16 ~$0.07, (1) 4-digit 7-seg 'time' display ~$0.40, (1) 74HC595 used as a digit driver ~$0.03 (cheaper than discrete transistors, and provides 4-8 outputs from 3 IOs), (1) button ~$0.02, and (1) 32.758kHz crystal with (2) 22pF caps ~$0.04.  I'm doing a few naughty things driving the 7-segment display without proper current limiting resistors or digit drivers, but it seems to work pretty good so far.  Using a second 74HC595 could free up a bunch of additional IOs, meaning this would fit on 6 IO MCUs (i.e. SOP-8), but the overall price would still be about the same, so what's the point.

Originally, I had been experimenting with this 'digital clock' with an external I2C RTC (DS1307) with plans to switch to the much cheaper BM8563/PCF8563 when parts came in.  But, then I realized if I just use the 32.768kHz crystal directly on the Padauk MCU (as input for the T16 timer interrupt), it would reduce parts count further and still be just as accurate (hopefully).  There is some library source code for a 'generic' I2C master and the DS1307 RTC that was fairly easy to implement (I didn't finish the full project so that isn't checked in yet, but the library code is there).

[tim_]

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?

But first things first, need to finish the lite programmer before that...

[serisman]

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.

Yeah, I have looked into it, and agree it is pretty cheap, especially if you can make use of their basic components and/or need more than a small handful of boards.  I just haven't thought up any projects that make sense to use it yet.

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?

Yeah, my toolchain is a bit different too.  I haven't dug too deeply into yours, but if I remember correctly it is fairly similar to mine.  I like the include files from the Examples in the easy-pdk-programmer-software repo better than the standalone nature of the sdcc-pdk-code-examples repo.  But, I still wanted to augment them further.  I added a util.h file that has helpers that I find useful.  I also structured it in a way that separates library headers and code from the projects.  Each project has it's own build directory and Makefile where options can be tweaked.

[serisman]

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.

[electronic_eel]

• 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.

[js_12345678_55AA]

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

[serisman]

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

Thanks for your response JS,

I'm not sure if you read through the related GitHub issue, but some of this is answered there: https://github.com/free-pdk/easy-pdk-programmer-software/issues/26

I did make a test after setting PADIER (right before the calibration call) and it didn't seem to make any difference.

I do still have the exact same .bin files wrote/read if they are helpful, but I don't think the issue with with writing the IC at this point.

I just re-targeted my "mini-pill" Pull Request to the development branch (https://github.com/free-pdk/easy-pdk-programmer-software/pull/24).  It was cleanly able to be moved from master to development.

I will re-target the PMS152 one to the development branch in an hour or so.  I think I might need to do some merging on that one (and I'm unavailable for the next 40 minutes).

Thanks again for all your hard work on these ultra cheap MCUs!

[serisman]

=> 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?

[serisman]

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?

Ok, false alarm.  I was missing your flash type fix from yesterday.  Once I found and brought that fix over, OTP probe is working again.

EDIT: Writing to PMS152 (including calibration) now works too!

Code: [Select]

>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.


Code: [Select]

>easypdkprog -n PMS152 -r 4.0 start
Running IC (4.00V)... IC started, press [Esc] to stop.
Hello World!
Hello World!

IC stopped

It looks like PMS152 DOES need the PADIER fix like the PFS173.  I'll update the pms152.h include file appropriately.  I think when I tested this earlier I accidentally used the old .ihx file and didn't actually test the PADIER fix.

[serisman]

- 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.

[tim_]

• 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.

Thank you for your feedback! Yes, the breakout boards only make sense for the flash types.

I know that socket, I use it for the OTP variants It fits into the current DIP16 spacing, so no additional header would be needed.

[js_12345678_55AA]

- 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.

Hi,

during development for PFS173 I found that we need the PADIER for some ICs ==> I created the 9 (9 instructions) variant
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)
ILRC and BG calibration always worked with any value (no 10 variant needed)

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.

JS

[serisman]

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 agree.

Setting PADIER in all cases seems like a good idea, even if most ICs default it on reset at the hardware level.

And, I really like the idea of starting calibration at the lowest frequency and working our way up, instead of briefly using the max (technically unsupported?) frequency and then only switching to the lowest frequency after detecting a pulse on PA4.

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.

Yeah, that sounds even better.  Might want to allow setting the locations of all the registers (PAC, PA, PADIER, IHRCR, ILRCR, BGTR, etc...) so we only have one algorithm per calibration type.

[tim_]

I have been trying again to use bitfields in SDCC to ease port access. There is still a bug, where SDCC generates incorrect code.

I will also submit a ticket to SDCC.

Example code (Blinky):

Code: [Select]

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 version:

Code: [Select]

SDCC : gbz80/tlcs90/z80n/pic14/ds400/pdk13/pdk14/pdk15 4.0.2 #11683 (Linux)

Here is what is emitted:

Code: [Select]

                                    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

"AND io,a" and  "OR io,a" unfortunately do not exist. Therefore the assembler fails to assemble this. This needs to be replaced with set0 / set1.

Edit:

Once this works in SDCC it would be a very useful way to augment the port defines, because it will be possible to set single bits with direct assignments like "PA7=1", a direct equivalent to the machine instruction, instead of messing around with bitmasks. I use this all the time on AVR with AVR-GCC and it works very well. AVR-GCC generates very efficient code out of this.

[serisman]

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.



For the most part it works great and simplifies development a bit.



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 originally planned to use a 2x4 male IDC connector with an IDC cable back to the programmer, but had previously created two 1x4 cables for easier breadboarding, so instead choose to install a 2x4 female connector.  But, this could easily be change to a different connector as needed.

I whipped up an example program that makes use of the on-board LEDs and BTN.
Here is the obligatory blink example: https://github.com/serisman/Padauk/tree/master/examples/blink
- LEDs 1 and 2 (PA3 , PA4) alternate every quarter second or so.
- LED 3 (PA6) will light up whenever the button (PA5) is pressed.
- LED 4 (PA5) will also light up when the button is pressed as it shares a pin with the button.



I will share the design files somewhere if there is any actual interest from anyone for them.

[tim_]

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.

Nice! I like the pin descriptions.

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 original programmer probably uses a bus driver to convert the logic levels to ones that are consistent with VDD of the device. That should improve noise immunity a bit.

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?).

VPP is always connected to ground by a ~25 kOhm resistor due to the two voltage dividers that are used as feedback. So it is not possible to let it float. 

I whipped up an example program that makes use of the on-board LEDs and BTN.

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.

[serisman]

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.

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. 

Behind the scenes, 'setPinOutput(PIN_LED2)' is just calling a macro that ultimately does: 'PAC |= (1<<4)'.  The macro makes it cleaner/easier to read and makes it easier to swap pins around just by changing one #define at the top of the file (or passing in an override from the command line or Makefile).

Of all the things to dislike about Arduino, is the cleanliness/readability really one of them?  There is a reason that Arduino is so popular.  If we want more adoption, we'll need to lower the barrier to entry across the board, and having code environments that look a bit more similar to what a lot of people already know could help with that.  I might even change my repo name to be Pdkuino and try and cater to more of that audience.

[tim_]

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. 

You mean "setup()" and "main()"? Well ...

Of course an optional Arduino-like include could not hurt.

But I was thinking there is a lack of consistency in the general toolchains that exist around PDK. It would be good to have at least one point of reference that we can all agree on extending on together. (olbigatory: https://xkcd.com/927/)

There are now at least 4 different repositories that have examples sitting somewhere in a deeply nested folder. All of them based on a different set of system includes. But as someone wanting to start development, it is simply a pain to find somethign that is consistent.

For example, there are still glaring issues when trying to use "printf" (Some of the examples use "puts" for a reason) . I implemented some optimized routines that took a lot of effort, to be at least able to do basic printf-style debugging (https://github.com/cpldcpu/SimPad/blob/master/Toolchain/library/PDK_softuart.c), but there is simply no place to put them oither than my own repositiy.

I also still don't know how to build a librariy with conditional linking of functions to be able to cope with the limited program memory.

Could we agree on starting a new repository on "free-pdk" that contains a central repository for the toolchain and examples? (Also looking at JS and Phillipp)