free-pdk / easy-pdk-programmer-software Goto Github PK

I just tried the current version from development.
When trying to build the firmware without dfu-suffix installed, I got an error. But after installing dfu-suffix (but installing it shouldn't matter for this bug), make claimed that there was nothing to be done. Only after doing a make clean could I then get a proper firmware build with dfu-suffix.

If dfu-suffix is not necessary to build the firmware, there should be no error. If it is necessary, there should still be an error the second time make is invoked (if dfu-suffix is still missing, otherwise there should be a build using dfu-suffix).

The problem is in the Makefile:

$(BUILD_DIR)/%.dfu: $(BUILD_DIR)/%.bin | $(BUILD_DIR)
	cp $< $@
	-$(DFU_SUFFIX) -v 0483 -p df11 -a $@

This rule first creates the target file, then uses dfu-suffix on it. Even if there is no dfu-suffix, the target file is created, so on second invokation of make, make thinks everything is fine.

Apologies, as this may not be the form to discuss such things ... but I want to build one of these programmers.

Can see the stm32f072 is the target MCU.

I already have an ample supply of stm32f103c8t6 MCUs on hand.

Would it be too much trouble to try to compile the firmware to target the f103?

The PMS152 is currently the cheapest 16-pin Padauk IC from LCSC. Currently, support for the PMS152 is read-only. It would be good to have write support for this device.

Here is a PR that adds compile time support to source code in the Examples directory, but there is no way to test this until the programmer can actually write these ICs. #25

Padauk released version 0.05 of the PMS150G datasheet in 2021/12/16.
PMS150G now supports maximum clock 8MHz.

Padauk just released the pdk14 PFC151, which apparently is their smallest / simplest flash-based µC so far. It would be good to have support.

Due to chip shortage, especially apply to STM32 family would be great to have possibility to use functional and pin-to-pin substitution for STM32F072C8Tx. The most appropriate candidate is STM32F042C6Tx (with good availability in my area).

So, fast look on schematic can't find any specific features that can have only F072, perhaps F042 also can be used at functional level - only rebuild FW for F042 required.

Is it possible to use the STM32F042C6Tx instead of the STM32F072C8Tx?
If so, can I ask to build FW also for F042? 🙏🏻

When using the 'start' command, it would be nice to see the baud rate that easypdkprog 'detected' from the MCU's autobaud transmission.

@serisman I like your refactoring of the includes very much. It's a nice way to retain compatibility to intellisense and keep everything organized.

My proposal would be to move the toolchain/includes, plus examples and potential library functions to a new repository within the free-pdk organization. Maybe "free-pdk-toolchain" ?

• Right now it is buried in the programmer firmware in a directory nobody will naturally look at.
• In addition, it would make a lot of sense to be able to prepare separate releases of toolchain and programmer.

We should also convert all the other examples (e.g. phillipps, mine) to the new include and clean everything up.

Another option would be to separate examples and toolchains into two repositories.

@freepdk, @spth, @serisman What do you think?

Now that there are a fair number of supported ICs, it might be nice to sort the list alphabetically to make finding a specific IC a little easier.

Current list (development branch - including PMS152 pull request):

>easypdkprog list
Supported ICs:
 PMC251   (0x058): OTP  : 1024 (16 bit), RAM:  59 bytes (RO)
 PMS132   (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS132B  (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS150C  (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes
 PMS15A   (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes
 PMS152   (0xA27): OTP  : 1280 (14 bit), RAM:  80 bytes
 PMS271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes (RO)
 PMC271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes (RO)
 PFS154   (0xAA1): FLASH: 2048 (14 bit), RAM: 128 bytes
 PMS133   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes (RO)
 PMS134   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes (RO)
 MCU390   (0xC31): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes (RO)
 PMC131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes (RO)
 PFS172   (0xCA6): FLASH: 2048 (14 bit), RAM: 128 bytes
 PMS171B  (0xD36): OTP  : 1536 (14 bit), RAM:  96 bytes (RO)
 PMS154B  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS154C  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PFS173   (0xEA2): FLASH: 3072 (15 bit), RAM: 256 bytes

Sorted list:

>easypdkprog list
Supported ICs:
 MCU390   (0xC31): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PFS154   (0xAA1): FLASH: 2048 (14 bit), RAM: 128 bytes
 PFS172   (0xCA6): FLASH: 2048 (14 bit), RAM: 128 bytes
 PFS173   (0xEA2): FLASH: 3072 (15 bit), RAM: 256 bytes
 PMC131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes (RO)
 PMC251   (0x058): OTP  : 1024 (16 bit), RAM:  59 bytes (RO)
 PMC271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes (RO)
 PMS131   (0xC83): OTP  : 1536 (14 bit), RAM:  88 bytes (RO)
 PMS133   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes (RO)
 PMS134   (0xC19): OTP  : 4096 (15 bit), RAM: 256 bytes (RO)
 PMS132   (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS132B  (0x109): OTP  : 2048 (14 bit), RAM: 128 bytes (RO)
 PMS150C  (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes
 PMS152   (0xA27): OTP  : 1280 (14 bit), RAM:  80 bytes
 PMS15A   (0xA16): OTP  : 1024 (13 bit), RAM:  64 bytes
 PMS171B  (0xD36): OTP  : 1536 (14 bit), RAM:  96 bytes (RO)
 PMS154B  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS154C  (0xE06): OTP  : 2048 (14 bit), RAM: 128 bytes
 PMS271   (0xA58): OTP  : 1024 (16 bit), RAM:  64 bytes (RO)

Is your feature request related to a problem? Please describe.
I'm a git noob , and was just bitten by not being able to switch to the development branch.
I could not get my (Tim's) lite programmer to do a calibration , as it was not in master.
I spent 2 days debugging my soldering etc , learned a lot. But could not get calibration to work.

Describe the solution you'd like
I would like for the easypdkprog & firmware to include the git version in the revision printout.

Improvement for output of easypdkprog -V and easypdkprog --verbose probe

$ git rev-parse HEAD
78983e5

Or
$ git log -1
commit 78983e5 (HEAD -> master, tag: 1.3, origin/master, origin/development, origin/HEAD)

Could you in the makefile run a: git rev-parse HEAD , save it in a "GIT_VER"
Then insert a -DGIT_BUILD=$GIT_VER , and use that GIT_BUILD as a string in the -V output ?

That could come in handy , when noobs like me don't know how to checkout development via git ?

easypdkprog -V
easypdkprog 1.2 - Git:78983e5aee2ab4bc16628405a0da99ca290f9af3

Same for programmer firmware

$ easypdkprog --verbose probe
Searching programmer... found: /dev/ttyACM3
FREE-PDK EASY PROG - Hardware:1.2 Firmware:1.3 Protocol:1.3 Git:78983e5aee2ab4bc16628405a0da99ca290f9af3
Probing IC... found.
TYPE:FLASH RSP:0x1AA1 VPP=4.50 VDD=2.00
IC is supported: PFS154 ICID:0xAA1

Maybe see thread here
https://www.eevblog.com/forum/blog/eevblog-1144-padauk-programmer-reverse-engineering/msg3134838/#msg3134838

serisman suggests : I would think the releases would still just use the release number, but branches could use a git commit or possibly the git branch name and git commit.

I'm not a git Guru , maybe there's a more elegant way of extracting what branch/git-nuber one uses when compiling.
But i'm sure i would have gotten som efficient help if had posted a : easypdkprog -V or easypdkprog --verbose probe - Showing i was on a totally wrong branch/level.

TIA
Bingo

Describe alternatives you've considered
Learning git :-)

Additional context
When i worked on Versalon (an opensource arm programmer) , it was super usefull to be able to get info about the specific version , that a user problem was related to.

Is your feature request related to a problem? Please describe.
Right now the information encoded in _hw_variant is not used anywhere.

Describe the solution you'd like
I would suggest to output this information when using the command line tool, for example as part of the "-v" or "-V" reply.

Or any other idea how to use it?

I got some padauk IC。The seller said those ics are pms171b (include sop16 and sop8). But i use the easyprog command -probe to check ic. it responsed the rsp is 0xe360 not 0xd360. I am confused. need help!!!

A while ago, Padauk released the PFS123.

Since this is a flash device, I'd expect it to be popular among hobbyists, and it would be good to have support for it.

Padauk recently released datasheets for the PFS252, another dualcore flash device, and the first such device in the PFS series (all other such devices so far are in the PFC series).

Since the PFS tend to be cheaper than the PFC, this could be the cheapest dualcore flash device, and become quite popular.

It would be good to have support in easypdkprog.

Is your feature request related to a problem? Please describe.
I was watching Daves video setting up the whole free-pdk toolchain, and while it seemed fairly trivial compared to what other toolchains can be like, I do see why Dave ran into the issues he did.

Describe the solution you'd like
It looks to my fairly untrained eye like all the bits and pieces are there to add support for this in platform IO, depending on how interested the platformIO team is, but I can't see why they'd deny the value of such a low cost mcu family being made easily available to the masses.

Thanks for your time on this, it's very exciting :)

I've noticed two things so far that are less than ideal when using easypdkprog connected to a flash based IC that is on a board with various other components. I am curious if either of these can be solved by a change to the programming hardware and/or software. Please feel free to close or move this if this is not a good place for discussion related to this.

1. Programmer doesn't properly disconnect from PA5.
2. Can't program when crystal connected to PA6/PA7.

For issue 1, it appears that the programmer is pulling PA5 low even when it is idle. PA5 is an ideal pin to place a button as it can be configured either for hardware reset or for general user functionality. But, when the programmer pulls the pin low, the IC will always be in reset (if configured with hardware reset functionality), or always read as button pressed, even when using the internal or external pull-up resistors. This means the programmer has to be physically disconnected after programming before executing user code. After a quick glance at the programmer firmware and schematic, it looks like it is trying to idle the line (i.e. tri-state), but I think it is being pulled low because it is connected to one of the outputs of the opamp (i.e. VPP). Potentially an analog switch (i.e. CD4051 or similar) could be used for a true disconnect, but I'm not sure if that is worth the extra complexity. Is there any firmware way for the programmer to truly release the line (i.e. high-z)? Or, could the programmer perform a weak pull-up on the line in 'idle' state?

For issue 2, it appears that the programmer is not able to properly communicate with the IC when there is a crystal (and supporting caps) connected to pins PA6/PA7. If there is a need for an external crystal, it has to be connected to PA6/PA7. I think I narrowed it down to the capacitors, not necessarily the crystal. According to the datasheet, on-board programming should be ok as long as PA6 has less than 220pF of capacitance. The 32kHz crystal I am using only uses 22pF capacitors, so in theory this should be ok. I am wondering if the 100 ohm resistors on the programmer are contributing to the problem. The datasheet indicates a direct connection to the IC, not going through what I assume are programmer pin protection resistors? So, should the resistors be removed? Or, can the timing be adjusted in the firmware/software to make up for the extra resistance?

I'd like easypdkprog to display the number of words written or read when done (or alternatively show the number of words about to be written before writing). At least in verbose mode.
This is a common feature for such software (e.g. stm8flash, stcgal).

Right now the IHRC trimming routing is using PA4 on PFS154/173. PA4 is not part of the programming interface on these devices and requires running an extra connection to the test board. This could be simply fixed by using PA6 instead. No change possible for 6 wire interface, of course.

Btw, I discovered this, because I missed that line. It seems the programmer is not able to detect this condition.

Hi, we made a board with support of PFC154-S14 and PFC154-S16.
They seem to identify different (PFC154-S16 shows as A34B)

TYPE:FLASH RSP:0xA34B VPP=4.50 VDD=2.00

Can that be supported (happy to supply chips for testing and a bounty)

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

The serial UART monitor supposedly uses autobaud. For some reason I can only get it to work with 2400 or 1200 baud. Any higher rate fails. For example 38400, even though it perfectly works with serial to USB adapters.

A while ago, Padauk released the PMS15A. It would be good to have support for it.

While LCSC currently does not stock it (I guess no one asked them for it so far), other vendors supply it.

The PMS15A is the lowest-end device by Padauk so far. Since part of the popularity of these devices is their low price, I'd expect the PMS15A to become quite popular among the OTP devices.

Having support for the PMS234 would be good:

Currently, no pdk16 devices have write-support. Having write support would be useful to go ahead with assembler and compiler support. The PMS234 would be a good choice for first supported pdk16 device, since among the pdk16 it is one of the two with the largest memory, thus allowing more experiments to be done than others.

I find it helpful to be able to adjust DAC coefficients in FPDK_SetVDD & FPDK_SetVPP without recompiling firmware.
Especially in case of non-precise resistors in dividers or customized feedback ratios (R6).

The PMS131 is one of the parts available at LCSC, supported by SDCC (since it is pdk14) and featured in eevblog videos. This makes the part a likely choice for many newcomers to Padauk-µC.

Currently, support for the PMS131 is read-only.

In an eevblog videos (https://www.eevblog.com/forum/blog/eevblog-1306-(4-of-5)-3-cent-micro-sdcc-c-compiler/), lack of write support for the PMS131 was one of the problems encountered.

It would be good to have write support for this device.

Describe the bug
The software can not be built on MSYS2 MinGW

To Reproduce
MSYS2 mingw: make all

Expected behavior
output.exe

Screenshots
MSYS2 MinGW:
gcc -std=c99 -pedantic -Wall -O2 -Ilib/argp-standalone-1.3 -o easypdkprog easypdkprog.c serialcom.o fpdkutil.o fpdkcom.o fpdkicdata.o fpdkihex8.o fpdkiccalib.o fpdkicserial.o lib/argp-standalone-1.3/libargp.a
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: fpdkutil.o:fpdkutil.c:(.rdata+0x0): multiple definition of FPDK_ERR_MSG'; C:\msys64\tmp\ccIMxD7Q.o:easypdkprog.c:(.rdata+0xd00): first defined here C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: fpdkcom.o:fpdkcom.c:(.rdata+0x60): multiple definition of FPDK_ERR_MSG'; C:\msys64\tmp\ccIMxD7Q.o:easypdkprog.c:(.rdata+0xd00): first defined here
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:31：easypdkprog] Error 1

Desktop (please complete the following information):

• OS: Windows 10
• Version 1903

Additional info
I am on the current development branch. I also tried the master branch but no luck.

Having support for the PMS271 would be good:

Currently, no pdk16 devices have write-support. Having write support would be useful to go ahead with assembler and compiler support. The PMS2714 would be a good choice for first supported pdk16 device, since it already has read support, and it is the cheapest pdk16 device, thus likely to be popular.

It seems the firmware file does not have a valid DFU suffix signature.
Current versions of dfu-utils warn about that, but it will be an error in future versions. So to ensure that nothing breaks in he future, it would be good if the build process would result in firmware with a valid DFU suffix signature.

Hi,
Thanks for adding PFC232 support
Finally i got some time to play with this MCU and i run into some issue.

Describe the bug
Getting verify failed error when flashing PFC232
And on latest development version calibration fails too.

./easypdkprog -n PFC232 write Examples/src/build/helloworld_2cores_pfc232.ihx -v
Searching programmer... found: /dev/ttyACM1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.5 (1.3-52-ge064f5d)
HWVAR:0 HWMOD:1
Erasing IC... done.
Blank check IC... done.
Writing IC (325 words)... done.
Verifiying IC... FPDK_ERROR: verify failed

./easypdkprog -n PFC232 write Examples/src/build/helloworld_2cores_pfc232.ihx -v --noverify
Searching programmer... found: /dev/ttyACM1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.5 (1.3-52-ge064f5d)
HWVAR:0 HWMOD:1
Erasing IC... done.
Blank check IC... done.
Writing IC (325 words)... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 5.00V ... calibration result: 0Hz (0x00)  out of range.
ERROR: Calibration failed

Desktop (please complete the following information):

• Ubuntu 20.04 x64
• SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ez80_z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15 4.0.3 #11850 (Linux)

./easypdkprog probe -v
Searching programmer... found: /dev/ttyACM1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.5 (1.3-52-ge064f5d)
HWVAR:0 HWMOD:1
Probing IC... found.
TYPE:FLASH RSP:0x1BA8 VPP=4.50 VDD=2.00
IC is supported: PFC232 ICID:0xBA8

Additional context
I have also tried version with PROTO:1.4 (commit a5e3d29),
PFC232 calibrates with --noverify only on programmer with R6 mod
and example code works.

./easypdkprog -n PFC232 write Examples/src/build/helloworld_2cores_pfc232.ihx -v --noverify
Searching programmer... found: /dev/ttyACM1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.4 (1.3-46-ga5e3d29)
HWVAR:0 HWMOD:1
Erasing IC... done.
Blank check IC... done.
Writing IC (325 words)... done.
Calibrating IC
* IHRC SYSCLK=8000000Hz @ 5.00V ... calibration result: 8002134Hz (0x6E)  done. 

helloworld_2cores_pfc232 programmed on PROTO 1.4, HWMOD:1 runs ok on programmer with latest firmware.

/easypdkprog start -v
Searching programmer... found: /dev/ttyACM1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.5 (1.3-52-ge064f5d-dirty)
HWVAR:0 HWMOD:1
Running IC (5.00V)... IC started, press [Esc] to stop.
Connected @169611 baud
Press a key on the host computer to send some bits, corg2 will detect this and core1 will output a '2' for every 1 bit
Hello World!
222222222222222222222Hello World!
222222

I noticed while looking at the fppa-pdk-documentation that the original Writer keeps track of erase counts for flash based parts in the last 'reserved' section of code memory.

That may be a useful feature to retain.

I have a few MTP ICs that I have written to a bunch of times during development, but have no way of knowing how many times, or how close they are to needing to be replaced. The datasheet simply states "programming cycle at least 1,000 times", but it might be nice to start gathering our own data. At least knowing how many times an IC has been erased/written would be interesting to track, especially if we start receiving reports of failures.

Potentially the programmer software could print this value out after a probe and/or read, and also print out the updated value after an erase and/or write. I might be a good idea to print a notice or warning message if the value is over 1000 as well.

@freepdk - Just wondering what your thoughts are about cutting a new release version (v1.3?) of this repo?

It seems like some users are hitting a bit of a snag with the new calibration routines, where for whatever reason they are not realizing that they have to first pull down the development branch as well as re-compile both the Firmware as well as easypdkprog software. An official release would potentially help a bit. Or, are there other things you want to add, finish, clean up, or test further before a new release?

Describe the bug

Programming a PFS173 does not work with the code from the development branch.
It works fine from the master branch.

To Reproduce

• checkout master branch
• build easypdkprog, build firmware, flash firmware
• easypdkprog --icname=PFS173 write Examples/helloworld_pfs173.ihx
• easypdkprog --runvdd=5.0 start

-> works fine

• checkout development branch or #33
• build easypdkprog, build firmware, flash firmware
• easypdkprog --icname=PFS173 write Examples/pre-compiled/PFS173/helloworld.ihx

-> error:

Erasing IC... done.
Writing IC (184 words)... done.
FPDK_ERROR: verify failed

Expected behavior

Programming a PFS173 should work without errors.

Desktop (please complete the following information):

• OS: Linux 64bit
• Version: UBUNTU 20.04

Additional context

I also tested my own program compiled with SDCC and it has the same issue: It works with the master branch, but fails with the development branch or #33.

Padauk just released the PFS172, a pdk14 flash µC. It would be good to have support for it.

I currently have two programmers, two PFS154 boards, two PFS173 boards (the f-eval boards from git - all identical except for PFS154 vs PFS173).
Using the current software, both programmers work fine with the PFS173 boards.

However, I see issues for the PFS154. Currently, only one programmer-board combination works sometimes (write sometimes works, sometimes fail at verify). The other 3 combinations always give

Erasing IC... done.
Writing IC... FPDK_ERROR: command ack failed / wrong icid

I have not yet done further testing. I probably should try older software versions, as I remember both programmers working with both boards in the past. Also, I'll create a few more PFS154 boards and test on them.

Hey Folks! I tried to probe the Programmer after uploading the firmware to it, but without success. As I'm sitting on a macOS machine I don't know if it has anything to do with that, but I have 2 programmers here and easypdkprog can't probe neither of them. I successfully installed SDCC, uploaded the firmware to the programmer and compiled some Example Code for the PFS137, but unfortunately uploading the program doesn't seem easy. As you can see below I had success with installing the easypdkprog I guess, but I would be very thankful for any help I can get. Sitting on this problem for almost 2 weeks now and its becoming really frustrating.

dfu-util -d 0483:df11 -a "@Internal Flash  /0x08000000/064*0002Kg" --dfuse-address 0x08000000 -D EASYPDKPROG.dfu

I uploaded the firmware to the Programmer via DFU mode and got the information 'File download was successfully'.

(base) USERS-iMac:EASYPDKPROG USERNAME$ cp easypdkprog /usr/local/bin/
(base) USERS-iMac:EASYPDKPROG USERNAME$ easypdkprog -V
easypdkprog 1.2
(base) USERS-iMac:EASYPDKPROG USERNAME$ easypdkprog probe
No programmer found
(base) USERS-iMac:EASYPDKPROG USERNAME$ 

I also tested the programmers voltage levels with my multimeter. The 3.3V DC converter module seems working fine and as I can see from the schematics and my measurements there should be no hardware issues with the programmers. And if so it would be very unfortunately that both programmers have the same issue

Today, Padauk released version 0.00 of the PMS150G datasheet.

Since this device seems to be another low-end device, very similar to the PMS150C, it wil probably become quite popular; so it would be good to have support. I guess it will take a few more weeks until devices arrive at distributors though.

From the datasheet, the PMS150G is nearly identical to the PMS150C.

Differences:

• During programming, the PMS150G uses a lower voltage on PA5, but a higher one on VCC than the PMS150C.
• When programmed using an official Padauk programmer, the PMS150G requires a newer minimum hardware version (PDK5S-P003) vs. the PMS150C (PDK3S-P002).
• The PMS150G can operate at 1.8V, while the PMS150C needs at least 2.0V.
• The PMS150G needs more power when operating at about 60 kHz (22 µA vs. 13 µA).
• The PMS150G can drive and sink more current on the I/O lines than the PMS150C.
• The PMS150G takes a bit more time for boot-up from power-on.
• The PMS150G has a maximum clock of 2 Mhz vs. 8 Mhz on the PMS150C

A while ago, Padauk released the PFS 122.

Since this is a flash device, I'd expect it to be popular among hobbyists, and it would be good to have support for it.

A while ago, Padauk announced the PFC154. Yesterday, the datasheet was released.

I guess it will take a few more weeks until devices become available at distributors.

From the documentation, the PFC154 looks like an EFT-tolerant variant of the PFS154. In particular, section 13 on program writing in the PFC154 datsheet looks very similar to the corresponding section 9.2.8 in the PFS154 datasheet. A notable exception is the voltage on PA5 (5V on the PFC154 vs 8V on the PFS154).

Padauk just released the PFC154, which seems quite similar to the already supported PFS154. The main difference seems improved ESD/EFT capabilities, and possibly the process used (0.5 µm vs 0.18 µm?).

While moving the sources to STM32CubeIDE I noticed somewhat doubtful code.
This may be for a purpose or an error.
I have not noticed any erroneous behaviour based on this.

USBD_CDC_SetTxBuffer() and USBD_CDC_SetRxBuffer() use the same buffer address UserRxBufferFS.

From usbd_cdc_if.c istarting line 150.
/* Private functions ---------------------------------------------------------*/
/**

• @brief Initializes the CDC media low layer over the FS USB IP
• @RetVal USBD_OK if all operations are OK else USBD_FAIL
  /
  static int8_t CDC_Init_FS(void)
  {
  / USER CODE BEGIN 3 /
  / Set Application Buffers /
  USBD_CDC_SetTxBuffer(&hUsbDeviceFS, UserRxBufferFS, 0);
  USBD_CDC_SetRxBuffer(&hUsbDeviceFS, UserRxBufferFS);
  return (USBD_OK);
  / USER CODE END 3 */
  }

Hello, I would like to make a programmer shield for the bluepill board I believe that many have this MCU in their hands and it would make the programmer project even cheaper, could someone compile and provide the firmware for the stm32f103c8t6 please

Describe the bug
I am encountering a strange bug: The programmer will disconnect after issuing a "start" command and is unresponsive after that until reconnecting. This errors seems to be specific to the communication that takes place after starting the program on the MCU, as I can see that the "blinky" firmware I loaded into the MCU is active for a very short time (~100 ms)

I am suspecting that this is actually an issue with the USB driver on my set up. As the setup is a bit exotic (MXlinux, ZOTAC Barebone ZBox-CI323NANO), I will simply not use it for now. The same programmer works well on my normal set up.

I still wanted to share in case someone has an idea.

DMESG output below.

[ 0.000000] microcode: microcode updated early to revision 0x368, date = 2019-04-23
[ 0.000000] Linux version 4.19.0-6-amd64 ([email protected]) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 root=UUID=0d4e0af4-6bd6-4e33-b8fa-15ff7e598c7c ro quiet splash
[ 0.000000] x86/fpu: x87 FPU will use FXSAVE
[ 0.000000] BIOS-provided physical RAM map:
...

[ 143.737547] xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr
[ 143.737558] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.
[ 143.739602] xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr
[ 143.739613] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.
[ 143.742010] xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr
[ 143.742021] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.
[ 143.744224] xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr
[ 143.744234] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.
[ 143.746492] xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr
[ 143.746502] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.
[ 143.748600] xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr
[ 143.748610] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.
[ 143.750904] xhci_hcd 0000:00:14.0: WARN Cannot submit Set TR Deq Ptr
[ 143.750914] xhci_hcd 0000:00:14.0: A Set TR Deq Ptr command is pending.
[ 143.751035] xhci_hcd 0000:00:14.0: WARN Event TRB for slot 13 ep 2 with no TDs queued?
[ 143.800772] usb 1-5.3.1.3: USB disconnect, device number 14
[ 143.803273] cdc_acm 1-5.3.1.3:1.0: failed to set dtr/rts
[ 149.144391] usb 1-5.3.1.2: new full-speed USB device number 15 using xhci_hcd
[ 149.247354] usb 1-5.3.1.2: New USB device found, idVendor=0483, idProduct=5740, bcdDevice= 2.00
[ 149.247371] usb 1-5.3.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 149.247382] usb 1-5.3.1.2: Product: Easy PDK Programmer
[ 149.247391] usb 1-5.3.1.2: Manufacturer: free-pdk.github.io
[ 149.247399] usb 1-5.3.1.2: SerialNumber: 1234567855AA
[ 149.257225] cdc_acm 1-5.3.1.2:1.0: ttyACM0: USB ACM device

Padauk just released the PFC232 (a PFS232 is not yet officially released, but seems to be the same except for temperature range or ESD rating), their first Flash Multicore-µC. It would be good to have support for them.
This is also the first pdk14 multicore µC.

Thanks for sharing your design.

I assembled a board, loaded firmware, connected a PFS173 (SOIC16). Probe fails:

$ easypdkprog probe
Probing IC... Nothing found.

I captured the per-pin data with a logic analyzer. You can download my capture and view it with their software: https://www.saleae.com/downloads/

Smaller lower resolution capture:
https://www.dropbox.com/s/7ih8tvkrcb0lwat/easypdk-probe-PFS173-smaller.logicdata?dl=0

~1gb high resolution capture:
https://www.dropbox.com/s/qqwybo7lcyldlz8/easypdk-probe-PFS173-failure.logicdata?dl=0

Channels in order:
0: vdd
1: pa7
2: pa6
3: pa5
4: pa0
5: pa4
6: pa3

1. OTP Program Memory: PMS150C - 1KW; PMS15A - 0.5KW
   Memory size is different. They have an identical identifier?

2. OTP Program Memory: PMS133 - 3KW; PMS134 - 4KW
   Similarly

3. PMC251 - 60 Bytes data RAM
   .ramsize = 0x3C (not 0x60)

Question:
vpp_write_hv for OTP: PMS154B, PMS154C - 11V, for the others - 10.5V
It essentially? What possible deviation? These are volts or conditional coefficient?

Padauk just released the PFC161, which seems to be a variant of the PFC151 with some additional peripheral for interfacing with touch-screens. It would be good to have support.

Having support for the PMC234 would be good:

Currently, no pdk16 devices have write-support. Having write support would be useful to go ahead with assembler and compiler support. The PMC234 would be a good choice for first supported pdk16 device, since among the pdk16 it is one of the two with the largest memory, thus allowing more experiments to be done than others.

I compiled the source code to generate "easypdkprog.exe" and "easypdkprogtest.exe" but these two always show "No programmer found" in case the release here work fine _"https://github.com/free-pdk/easy-pdk-programmer-software/releases/tag/1.3"_(can detect MCU but can't verify the code: "FPDK_ERROR: verify failed"
I think i need to measure the voltage, but "easypdkprogtest.exe" do not work.
Please show me how to compile the source code or send me "easypdkprogtest.exe" that run by your side.
I really need your help.
Thanks in advance

I came across a very interesting bug. It appears that the last instruction word is not completely written to the flash. See screenshot below showing a disassembly of the hex file before writing (right side) and after reading back from the device (PFS154, left side).

In this case a "ret" instruction is encoded here. Usually, when the source is only one file and the main loop never finished, this RET is never reached. However, when linking more than one source file, SDCC puts all subroutines from sources other than the main there, so that the missing RET will cause the MCU to enter a neverending loop.

When flashing the .ihx file provided in this repo, the helloworld example works,
but when I compile it from source code using the SDCC snapshot, it doesn't.
Actually I couldn't get any of the showcase projects to work, yet...

Here are the files created by SDCC: helloworld_pfs173.zip

• OS: Linux 64bit
• Version: Debian Testing
• Compiler: SDCC 4.2.8 (Snapshot Sep 1 10:30)