PMS150G support

[spth]

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

[spth]

The device seems to be available in shops now: http://www.atwdz2014.com/shop/supply/133232266.html http://www.b2b198.com/product-42500975.html

[spth]

Another shop that has the PMS150G:

https://www.1688.com/huo/detail-610331251267.html?spm=a262i4.9164788.zhaohuo-list-offerlist.31.413b7368sYytKO

[spth]

A week ago, Padauk updated the PMS150G datasheet, which now also lists the PMS15B.

Apparently, the PMS15B is an otherwise identical variant of the PMS150G with only half the program memory (similar to PMS15A vs. PMS150C).

[Kashouryo]

@freepdk Are you still working on this? I might be able to provide some of these MCUs for free(e.g. PMS150G, PMS131, etc) if that helps with the development.

[freepdk]

I had a quick look at the include file from PADAUK IDE and it looks like PMS150G is in many ways identical to PMS150C.

In order to add support I would need the real IC-ID which you can find out by running

easypdkprog -v probe

output should be something like this:

Searching programmer... found: /dev/tty.usbmodem1234567855AA1
FREE-PDK EASY PROG - HW:1.2 SW:1.3 PROTO:1.3
Probing IC... found.
TYPE:FLASH RSP:0x1EA2 VPP=4.50 VDD=2.00
...

Can you please try this and report the value of RSP (response) for PMS150G ?

[Kashouryo]

Can you please try this and report the value of RSP (response) for PMS150G?

Sure, I'll order them. They should arrive after the lunar new year holiday.

[Kashouryo]

Also, Spth mentioned that

During programming, the PMS150G uses a lower voltage on PA5, but a higher one on VCC than the PMS150C.

What's the highest VDD voltage FreePDK programmer v1.2 can deliver? Or do we also need to have a programmer revision?

[freepdk]

Also, Spth mentioned that

During programming, the PMS150G uses a lower voltage on PA5, but a higher one on VCC than the PMS150C.

What's the highest VDD voltage FreePDK programmer v1.2 can deliver? Or do we also need to have a programmer revision?

This are just values from data sheet mentioning what could happen when the original WRITER is used... we will see reality.

VPP ==> max easy pdk programer can do is ~ 13.0 V VDD ==> max easy pdk programmer can do is ~6.6 V

In case we really need 2 voltages >7.5V then we could just change "R6" on pcb to change the opamp curve.

[Kashouryo]

I just received these ICs. Here's the probe information:

Searching programmer... found: COM6 FREE-PDK EASY PROG - Hardware:1.2 Firmware:1.3 Protocol:1.3 Probing IC... found. TYPE:OTP RSP:0x18E60 VPP=4.50 VDD=2.00 Unsupported IC

Underneath the IC the first line reads:

XDS18A

This indicates that it's probably a completely new IC.

[freepdk]

Ok,

Based on this the ICID 12 bit is 0x639

You could try to add the following block to "fpdkicdata.c" (e.g. right after the PMS150C):

  { .name                         = "PMS150G",
    .otpid                        = 0x2539,
    .id12bit                      = 0x639,
    .type                         = FPDK_IC_OTP1_2,
    .addressbits                  = 12,
    .codebits                     = 13,
    .codewords                    = 0x400,
    .ramsize                      = 0x40,
    .exclude_code_start           = 0x3F6,
    .exclude_code_end             = 0x400,
    .vdd_cmd_read                 = 2.5,
    .vpp_cmd_read                 = 5.5,
    .vdd_read_hv                  = 2.5,
    .vpp_read_hv                  = 5.5,
    .vdd_cmd_write                = 4.3,
    .vpp_cmd_write                = 8.0,
    .vdd_write_hv                 = 5.8,
    .vpp_write_hv                 = 10.5,
    .write_block_size             = 2,
    .write_block_clock_groups     = 1,
    .write_block_clocks_per_group = 8,
  },

This will let probe report is as a PMS150G.

Now you can try to read the IC easypdkprog -n PMS150G -b read pms150gempty.bin. If this works please zip the file and attach it here (you can attach files by drag and drop them to this comment window here).

If the read does not work try to change .type to FPDK_IC_OTP2_2.

NOTE: All voltages are just copied from PMS150C. Voltages for reading are low and safe. The voltages for writing might be wrong and could destroy your valuable PMS150G IC ;-) The only way to get the voltages is to run power trace during a programing cycle with WRITER (monitor VPP/VDD over time).

[Kashouryo]

Here's the bin file. FPDK_IC_OTP1_2 worked just fine pms150gempty.zip Btw: I have hundreds of these PMS150Gs so It's fine to ask me to do some dangerous tests. I am planning on recording the programming sequence voltages(VDD VPP) of PMS150G. What is an appoprate sample rate for Padauk's protcol?

[freepdk]

The readout look good :-) Thanks for this.

WRITER usually is doing:

• some probing
• reading
• writing program
• writing end area
• calibrating
• writing calibration values

So when you capture the complete process (some seconds only) we will see multiple different voltages.

The voltage trace for VDD/VPP should have a resolution of at least 100 samples / second (higher is better).

Since reading is working already, we only need to see the voltages for the write command:

• VPP write command phase
• VDD write command phase
• VPP write high voltage phase
• VDD write high voltage phase

They can be identified easily in power trace (VPP/VDD in high voltage phase are the highest voltages of complete programing cycle)

[Kashouryo]

Here's the PulseView file I captured with two probes under 10x mode. From the capture, I saw that the highest voltage VDD went was 850mV(with a 10x probe). pms150g_prog_voltage.zip

[freepdk]

Somehow the capture does not look right. Also when I open your attached file in pulseview it shows a different capture than your screen shot.

The attached .sr file shows a negative voltage on VDD channel when idle.

Could it be that you did not connect GND of VDD channel properly?

The write cycle from SR file shows

VDD cmd write 3.0V VPP cmd write 7.5V VDD hv write 8.5V VPP hv write 7.5V

suggested values to try

    .vdd_cmd_write                = 4.0,
    .vpp_cmd_write                = 8.0,
    .vdd_write_hv                 = 6.5,
    .vpp_write_hv                 = 8.0,

Then try to write a file easypdkprog -v -n PMS150G write helloworldpms150g.ihx and have a look at the output.

In case you run into a verification error, you can try again to program the same IC. You only have to disbale "blank check": easypdkprog -v -n PMS150G write helloworldpms150g.ihx --noblankchk

Sometimes write needs more current / higher voltage to flip all required bits. Nevertheless a second pass usually flips the remaining bits and the IC is still usable.

[Kashouryo]

easypdkprog -v -n PMS150G write Serial_HelloWorld_PMS150C.ihx --noblankchk Searching programmer... found: /dev/ttyS5 FREE-PDK EASY PROG - Hardware:1.2 Firmware:1.3 Protocol:1.3 Writing IC (208 words)... FPDK_ERROR: command ack failed / wrong icid

This is what I got. After this unsuccessful write, the dumped bin looks identical to the empty one.

[freepdk]

The error message says that after starting the write command the IC did not respond with the proper ICID.

Please try to use " FPDK_IC_OTP2_2" in icdata for PMS150G maybe this fixes the problem already.

If not then the write command maybe different and we need a complete capture of a write with logic analyzer (usually I use 5 MHz for this).

[Kashouryo]

Here is a CLK and DAT capture of the prog sequence. If I connect the probe's ground to the programmer's ground, the programmer will throw an error. So I connected my probe's ground to the programmer's USB connector shell.

pms150g_prog_seq1.zip

[Kashouryo]

Any update on this topic?

[freepdk]

I had a look at your capture, unfortunately it is incomplete.

PMS150C / G? uses more pins: CLK/DATOUT/DATIN/(CLK2?) It also is very useful to have all pins captured (including VPP/VDD).

You should connect all 8 programing from WRITER to your logic analyzer (you can find the 8 pins when you open the back of WRITER, this is a convenient way to connect). Also make sure to use the digital GROUND from WRITER (I soldered an extra pin on back for this). !!! make sure that your logic analyzer can handle >5V when you connect VPP/VDD !!!

[Kashouryo]

PMS150G_16Mhz_8CH.zip There you go. Fortunately seems like my FX2LP can handle it's VPP

[Kashouryo]

However, If I connect my probe to IC's signal ground, WRITER will throw an open circuit error. To compensate for that, I increased the sample rate to 16Mhz

[LovelyA72]

May I see your extra digital ground pin?

[freepdk]

@LovelyA72 Have a look in the PMS150C data sheet -page 67- : http://www.padauk.com.tw/upload/doc/PMS15A,PMS150C%20datasheet%20V108_EN_20200724.pdf

There you can see the back of the WRITER (when you open the service door).

Between CN40 and CN39 is an empty looking area. You can see 4 through hole pins (from the programing button pushed through the pcb) The bottom 2 pins of this push button are GND (you also can see the big trace / ground plane).

I soldered an extra pin header pin to one of the 2 GND pins (big solder blob and stick a pin inside).

[freepdk]

@Kashouryo

The readout is still not optimal (looks like your logic analyzer does not show VDD / VPP properly ... maybe your threshold level is not optimal / to high (on my logic analyzer I set >2V = logical 1).

However I could identify D0 as CLK D1 as DATOUT (data to IC) D5 as DATIN (data from IC) - however here logic levels seem to be not good so only parts can be seen

I clearly could see: READ command with trailer is A5A5A5A6 => type is for sure FPDK_IC_OTP1_2 read sends 12 address bits, followed by 13 clocks to read in the data bits

=> addressbits = 12 => codebits = 13

WRITE command with trailer is A5A5A5A7 => this command is used for write by FPDK_IC_OTP1_2 write sends groups of: 13 data bits word1 13 data bits word2 12 address bits 1 dummy clock 8 slow pulses an DATOUT for write to happen (clock is always high during this period) 1 dummy clock

=> write_block_size = 2 => write_block_clock_groups = 1 => write_block_clocks_per_group = 8

What I could not see was the direct response to the READ or WRITE command (the thing what easypdk programmer is complaining is not matching for write).

The protocol itself looks to be identical with the PMS150C protocol.

So things to try is to "play" with the voltages for the write command. Either you can read the real voltage values during a write or you just try:

First only play with the CMD voltages. The IC expects a voltage difference > 2.0 V between VDD and VPP.

.vdd_cmd_write  = 4.3   <== slowly increase / decrease this value (0.1 steps)
.vpp_cmd_write  = 8.0   <== slowly decrease / increase this value (0.5 steps)

e.g. VDD 4.5 VPP 8.0 VDD 4.6 VPP 8.0 VDD 4.7 VPP 8.0 VDD 4.8 VPP 8.0 VDD 4.9 VPP 8.0 VDD 5.0 VPP 8.0

VDD 4.5 VPP 8.5 VDD 4.5 VPP 7.5 VDD 4.0 VPP 6.5 VDD 3.5 VPP 6.0

You found a working pair as soon as you do not get the "FPDK_ERROR: command ack failed / wrong icid" anymore.

After that write might be working or not... maybe also needs to play with hv voltage...

[Kashouryo]

Is it possible to add a cli argument that specify the vdd and vpp? That will be an awesome feature for testing out new ics

[Kashouryo]

BTW, one more information: This ic is not supported by the P-002 programmer. All of these captured sequences came from a newer P-003 programmer

[Kashouryo]

update regarding the writer I was able to write sth to the PMS150G with the following settings and command The binary was for PMS150C since there is no such setting for PMS150G in the include file. dumped.zip

easypdkprog.exe write -npms150g C:\Software\FreePDK\projects\Blinky2\bin\Release\Blinky2.hex --noblankchk
Writing IC (87 words)... done.
FPDK_ERROR: verify failed

    { .name                         = "PMS150G",
    .otpid                        = 0x2539,
    .id12bit                      = 0x639,
    .type                         = FPDK_IC_OTP1_2,
    .addressbits                  = 12,
    .codebits                     = 13,
    .codewords                    = 0x400,
    .ramsize                      = 0x40,
    .exclude_code_start           = 0x3F6,
    .exclude_code_end             = 0x400,
    .vdd_cmd_read                 = 2.5,
    .vpp_cmd_read                 = 5.5,
    .vdd_read_hv                  = 2.5,
    .vpp_read_hv                  = 5.5,
    .vdd_cmd_write                = 4.5,
    .vpp_cmd_write                = 8.0,
    .vdd_write_hv                 = 6.5,
    .vpp_write_hv                 = 8.0,
    .write_block_size             = 2,
    .write_block_clock_groups     = 1,
    .write_block_clocks_per_group = 8,
  },

[Kashouryo]

But when I power up the micro, the LED just constantly stays lit. I think a clock calibration might help.

[Kashouryo]

Also, without the --noblankchk the writer will complain that the IC is not empty

[freepdk]

@Kashouryo This looks very promising...

Also, without the --noblankchk the writer will complain that the IC is not empty

Since your PMS150G has an extra factory value @0x3F5 you should exclude this word as well change ==> .exclude_code_start = 0x3F5, then it should not complain about "non blank" ic.

easypdkprog.exe write -npms150g Blinky2.hex --noblankchk Writing IC (87 words)... done. FPDK_ERROR: verify failed

It looks like the write was not 100% successful (some bits have not been written properly) Just try to write again (with the --noblankchk). This will most likely fix the problem.

Usually this is caused by to low vpp_write_hv ==> I suggest you set it a bit higher... (9V or 10V)

Edit: It looks like just a single bit in the very first written word was not flipped. So you are very close to a 100% good writing. Try to increase "VDD_cmd_write" and/or "VPP_write_hv" just a small bit and it should work perfect.

But when I power up the micro, the LED just constantly stays lit. I think a clock calibration might help.

This is most likely caused by the write not complete (verify failed). See above.

[Kashouryo]

Nope, doesn't work. With 10.5V VPP and 6.6V VDD and multiple writes, the IC still doesn't verify or run. Here's a dump of the IC ROM content. How do I force a calibration even if the programmer can't verify the IC? 2.zip

[Kashouryo]

Alright, I edited the code to skip the verification Here's what I got

easypdkprog.exe write -npms150g C:\Software\FreePDK\projects\Blinky2\bin\Release\Blinky2.hex --noblankchk
Writing IC (87 words)... done.
FPDK_ERROR: verify failed
ERROR: Verify failed.
Calibrating IC
* IHRC SYSCLK=1000000Hz @ 4.00V ... calibration result: 0Hz (0x00)  out of range.
ERROR: Calibration failed

[freepdk]

@Kashouryo There is an option in easypdk prog to skip verify "-noverify".

However if verify fails (like in your case) most likely calibration can not be performed since some bits of the program memory are written incorrectly. Calibration needs the injected calibration code to run correctly.

The problem is not that "the programmer can not verify the IC". The problem is that the IC was not written correctly!

Like I said before... Try to play with the voltages. I suggested to not only play with "VPP_write_hv" instead it is more likely that you might be successful when you increase "VDD_cmd_write".

Best way would still be to measure the real voltages (with correct ground reference) when original WRITER is performing the write. then you would not have to try so hard...

[homeworkboy]

I use Padauk writer. write data at 150G

@0068 1700 // MOV A, 0x00 @0069 1000 // ADD A, 0x00 @006a 1001 // ADD A, 0x01 @006b 1002 // ADD A, 0x02 @006c 1003 // ADD A, 0x03 @006d 1004 // ADD A, 0x04 @006e 1005 // ADD A, 0x05 @006f 1006 // ADD A, 0x06 @0070 1007 // ADD A, 0x07 @0071 1008 // ADD A, 0x08 @0072 1009 // ADD A, 0x09 @0073 100a // ADD A, 0x0A @0074 100b // ADD A, 0x0B @0075 100c // ADD A, 0x0C @0076 100d // ADD A, 0x0D @0077 100e // ADD A, 0x0E @0078 100f // ADD A, 0x0F @0079 1010 // ADD A, 0x10 @007a 1011 // ADD A, 0x11 @007b 1012 // ADD A, 0x12 @007c 1013 // ADD A, 0x13 @007d 1014 // ADD A, 0x14 @007e 1015 // ADD A, 0x15 @007f 1016 // ADD A, 0x16 @0080 1017 // ADD A, 0x17 @0081 1018 // ADD A, 0x18 @0082 1019 // ADD A, 0x19 @0083 101a // ADD A, 0x1A LA view OTP at 150G at 0x080 correct data "1017" read data "1A42" ........

May it VPP voltage right.

[freepdk]

I use Padauk writer. write data at 150G at 0x080 correct data "1017" read data "1A42" ........

May it VPP voltage right.

Finally I got hold of some PMS150G.

I have writing + reading working reliable.

What you observed is correct. It is a new "feature".

=> It looks like the first 32 instructions are scrambled, this repeats every 64 instructions.

The scrambler is a simple substitution cipher (bits are shuffeled around).

I already have a full mapping and can scramble and unscramble this data

@PADAUK: You really love 55AA right ? :-)

Full PMS150G support is not far away.

[homeworkboy]

{ .name = "PMS150G", .name_variant_1 = "PMS15B", .otpid = 0x2539, .id12bit = 0x639, .type = FPDK_IC_OTP1_2, .addressbits = 12, .codebits = 13, .codewords = 0x400, .ramsize = 0x40, .exclude_code_start = 0x3F6, .exclude_code_end = 0x400, .vdd_cmd_read = 2.6, .vpp_cmd_read = 5.5, .vdd_read_hv = 2.6, .vpp_read_hv = 5.5, .vdd_cmd_write = 4.5, .vpp_cmd_write = 8.0, .vdd_write_hv = 6.5, .vpp_write_hv = 8.0, .write_block_size = 2, .write_block_clock_groups = 1, .write_block_clocks_per_group = 8, }, read cmd 2.5V -> 2.6V . Reading data is reliable. data "1801" at address 0x000 It's random

[freepdk]

I just measured the voltages WRITER uses and everything worked at the first try (even reading the first address is working). => Measuring instead of trying is the right way...

  { .name                         = "PMS150G",
    .name_variant_1               = "PMS15B",
    .otpid                        = 0x2539,
    .id12bit                      = 0x639,
    .type                         = FPDK_IC_OTP1_2,
    .addressbits                  = 12,
    .codebits                     = 13,
    .codewords                    = 0x400,
    .ramsize                      = 0x40,
    .exclude_code_start           = 0x3F5,
    .exclude_code_end             = 0x400,
    .vdd_cmd_read                 = 2.5,
    .vpp_cmd_read                 = 5.5,
    .vdd_read_hv                  = 2.0,
    .vpp_read_hv                  = 2.0,
    .vdd_cmd_write                = 3.5,
    .vpp_cmd_write                = 6.5,
    .vdd_write_hv                 = 7.8, //this voltage can not be reached by esay pdk programmer, however maximum VDD voltage (~6.6V) works fine
    .vpp_write_hv                 = 6.5,
    .write_block_size             = 2,
    .write_block_clock_groups     = 1,
    .write_block_clocks_per_group = 8,
  }

=> REMEMBER Due to the new instruction block scrambling you can not write a working program right now.

I still need to add some extra code to scramble (before writing) and descramble (after reading) the scrambled instructions blocks.

[freepdk]

Looks like this scrambler which scrambles 32 instructions, skips 32 instructions, scrambles 32 instructions, ... will cause problems with our calibration since we can not "overwrite" the 0xFF initial value with the final tuning value, in case the calibration routine is located inside of a scrambled region.

Therefore I will need to add some extra stuff (in the pms150g header file) so calibration routines are always located in unscrambled areas.

EDIT: After I fully understood the scrambling, I found that this will not be a problem at all.

[freepdk]

And it seems to work:

./easypdkprog -n PMS150G write Examples/src/build/helloworld_pms150g.ihx
Writing IC (186 words)... done.
Calibrating IC
* IHRC SYSCLK=2000000Hz @ 4.00V ... calibration result: 1991689Hz (0x41)  done.
Writing IC Fuse... (0x0EFD) done.

./easypdkprog start --runvdd=4.0
Running IC (4.00V)... IC started, press [Esc] to stop.
Connected @28933 baud
Hello World!
Hello World!

I will cleanup and prepare update of development branch... should be there soon

[freepdk]

Closing this one. PMS150G was added in c1ff506

[hashuser]

PMS150G now supports maximum clock 8MHz