27512 #210

Open DavidGriffith opened 3 years ago

In GitLab by @evanfoss on Feb 12, 2021, 17:39

Hi,
I just bought a TL866II Plus and I am trying to read and write 27512 EPROMs and it's not going smoothly. I am using a fresh git clone. I tried updating the firmware first.

I pulled the firmware from XgproV1075_Setup.rar from the companies website.

sudo minipro -F ../../firmware/TL866IIplus/updateII.dat
Found TL866II+ 04.2.124 (0x27c)
Warning: Firmware is newer than expected.
Expected 04.2.123 (0x27b)
Found 04.2.124 (0x27c)
../../firmware/TL866IIplus/updateII.dat contains firmware version 4.2.124

Do you want to continue with firmware update? y/n:y
Switching to bootloader...
IO error: bulk_transfer: LIBUSB_ERROR_IO
IO error: expected 8 bytes but 0 bytes transferred
failed!

On a second try I get this...

sudo minipro -F ../../firmware/TL866IIplus/updateII.dat
Found TL866II+ in bootloader mode!
../../firmware/TL866IIplus/updateII.dat contains firmware version 4.2.124 (newer)

Do you want to continue with firmware update? y/n:y
Erasing... OK
Reflashing... 100%
Resetting device...
IO error: bulk_transfer: LIBUSB_ERROR_IO
IO error: expected 8 bytes but 0 bytes transferred
failed!
Segmentation fault

Does this mean I have corrupted firmware on the programmer now and if so how do I unbrick it? I tried reading an AM27512 and the software keeps telling me "device not found" is that a fw error or does this software have a different supported device list from the windows application?

Thanks,
Evan Foss

In GitLab by @radiomanV on Feb 13, 2021, 03:43

It seems that there's an issue while resetting the programmer. The first attempt to switch to bootloader failed (but the programmer entered the boot mode).
Then on the second attempt the device was already in bootloader mode and firmware reflash was ok (100%). Then when switching back to normal mode failed again. I don't think that the device is bricked.

This is a known issue for some motherboards/chipsets with USB3 and this programmer under Linux (see issue #148).
Please disconnect the programmer and reboot your machine. Then connect the programmer again and from terminal do this: lsusb | grep a466. If you get something like Bus 001 Device 013: ID a466:0a53 the programmer is ok (bus and device numbers may differ).
Also you can try this on another computer. The solution is to use a powered USB 2.0 hub.

In GitLab by @evanfoss on Feb 13, 2021, 18:29

Thanks! You were right of course. I had tried a USB2.0 powered HUB before and had checked that it could power the device on it's own before trying the update. That said when I checked dmesg it showed that the raspberry pi was going under voltage. I changed the power cable on the pi to a shorter one and that fixed it. Sorry I forgot to mention that I was not running this on a standard PC.
I ran the test you suggested and got this back. Which makes sense but the absense usual text following the ID made me panic a bit.
Bus 001 Device 015: ID a466:0a53

Then I check the other fields and I assume this vendor just does this differently?
idVendor 0xa466
idProduct 0x0a53
iManufacturer 1 Xingong Electronicg Co..
iProduct 2 Xingong XGecu USB Prog.. Device

Anyway I tried to do a blank check on the EPROM. (Sorry for the stupid question about the supported devices)

sudo minipro -b -d 27512@DIP28
[sudo] password for evan:
Found TL866II+ 04.2.124 (0x27c)
Warning: Firmware is newer than expected.
Expected 04.2.123 (0x27b)
Found 04.2.124 (0x27c)
Name: 27512@DIP28
Memory: 65536 Bytes
Package: DIP28
ICSP: -
Protocol: 0x07
Read buffer size: 512 Bytes
Write buffer size: 128 Bytes
***
VPP programming voltage: 12V
VDD write voltage: 5.5V
VCC verify voltage: 5V
Pulse delay: 1000us

I was expecting a Yes or No. I tried googling what the format of the reply for this would look like and I didn't see an example. I double checked the syntax against your past post here. https://gitlab.com/DavidGriffith/minipro/-/issues/160
Would you please explain what I am missing here?

Thanks,
Evan

In GitLab by @radiomanV on Feb 14, 2021, 05:17

Bus 001 Device 015: ID a466:0a53
Then I check the other fields and I assume this vendor just does this differently?
idVendor 0xa466
idProduct 0x0a53
iManufacturer 1 Xingong Electronicg Co..
iProduct 2 Xingong XGecu USB Prog.. Device

This is ok, no worries.

The syntax is wrong. Let me explain. We have three kind of commands:

Maintenance commands
-F firmware update
-t hardware self check
-V print software version and database info
-k query currently connected programmer version
-Q query supported programmers (currently TL866A/CS and TL866II+)
Database search and device info
-l display all supported chips
-L search database (for ex. minipro -l 27c25 will display all supported device like this)
-d display info about a chip

As you can see the -d is used for querying device info. Then we have commands which requires an action. An action is when we physically interact with a supported chip. This can be read, write, erase, blank check or read the device ID (if that device has one).
When an action is involved then the -p is used. Like this: minipro -p TMS27C256@DIP28. Then we must specify an action, like blank check for example: minipro -p 27512@DIP28 -b

The following actions are supported:
-r read device, -w write device, -E erase device, -b blank check, -m verify device, -D read device ID.
For the TL866II+ we have also the -z which will issue a bad pin contact check. This command can be used alone (minipro -p 27512@DIP28 -z will check if all required chip pins have a good contact) or you can use it as part of another action (minipro -p 27512@DIP28 -b -z first will check if all required chip pins have a good contact an then a blank check).
Then we have control switches when we want to control the action flow (skip reading the device ID, which device section to use for controllers, skip size warnings, control the voltages for Eproms and so on)

In GitLab by @evanfoss on Feb 14, 2021, 13:02

Thanks again radioman. I was confused between -p and -d. The listing you get from -h doesn't really clarify it.

Unfortunately I am still stuck.

sudo minipro -p '27512@DIP28' -b
Found TL866II+ 04.2.124 (0x27c)
Warning: Firmware is newer than expected.
Expected 04.2.123 (0x27b)
Found 04.2.124 (0x27c)
Invalid Chip ID: expected 0x890D, got 0x1C0D (unknown)
(use '-y' to continue anyway at your own risk)

I tried "" quotes instead and still got an error.

Now if I wanted to program a variant of the 27512 that uses a different programming voltage the syntax would be --vpp=12.5?

In GitLab by @radiomanV on Feb 15, 2021, 10:38

What exactly this chip is? the full markings please. Also please insert the -z switch to make sure that you don't have a bad pin contact.
Like this: minipro -p '27512@DIP28' -b -z The --vpp=12.5 syntax is correct but this voltage is used only in programming phase.

For ex. if we want to write a file to our EPROM (uv erasable prom) the syntax would be:
minipro -p M27512@DIP28 -z -w ./test.bin --vpp=13 --vcc=5.5 --vdd=5.5 --pulse=100.
This will perform a pin test and if ok will write the test.bin file to EPROM. The vpp, vcc, vdd and pulse are optional and you should pass them only if you want to override the default parameters for this chip and are taken into account only in write (programming) mode (-w). For read/verify/blank check they are ignored and the default chip voltage is used to read/verify/blank check (-r -b -m).

If you have an unknown unsupported chip please pass the -x switch. This will skip chip ID read and will perform the requested action using the default protocol for that chip.

In GitLab by @evanfoss on Feb 15, 2021, 16:29

I have some legit 27512's that I need to read but I think the chip I had in there at the time was a M5L27512K which I ultimately want to write too. For reading I thought it wouldn't matter. Obviously I am wrong I guess.
https://www.jameco.com/Jameco/Products/ProdDS/2288055.pdf

minipro -p '27512@DIP28' -b -z
Found TL866II+ 04.2.124 (0x27c)
Warning: Firmware is newer than expected.
Expected 04.2.123 (0x27b)
Found 04.2.124 (0x27c)
Pin test passed.
Invalid Chip ID: expected 0x890D, got 0x1C0D (unknown)
(use '-y' to continue anyway at your own risk)

Not that this is relevant but my HP3325B (function gen) died from what I believe to be rot of it's EPROMs. Normally I would stop and burn more time try to work out more of this myself but I was using it to work from home.

I saw a reference to XML in the source but I assume that's a format for chip configurations. Is there a way to use that to load/store?

In GitLab by @radiomanV on Feb 16, 2021, 06:39

Yeah, according to the datasheet the chip is M5L27512K which is not supported.
But you can try to read/write this chip by manually passing the right voltages and write timings.
First do a blank check like this: minipro -p '27512@DIP28' -b -y. If the chip is blank you can proceed and write it like this: minipro -p '27512@DIP28' -w ./file.bin --vpp=12.5 --vdd=5.5 --vcc=5 --pulse=1000 -y.

According to the datasheet the chip vcc during the programming phase should be 6.0V and 5.0V for read/verify. The VCC write voltage (vdd in minipro) is set to 5.5 here, but you can increase it to 6.5 if you want.

That xml file is the actual database and can be edited by everyone to add unsupported chips.

In GitLab by @evanfoss on Feb 17, 2021, 07:50

Thank you very much! The blank check worked with the -y option to force it to run. Writing worked as well with the settings you recommended.

minipro -p '27512@DIP28' -y -w 03325-60302-r2802.bin --vpp=12.5 --vdd=5.5 --vcc=5 --pulse=1000
Found TL866II+ 04.2.124 (0x27c)
Warning: Firmware is newer than expected.
Expected 04.2.123 (0x27b)
Found 04.2.124 (0x27c)

VPP=12.5V, VDD=5.5V, VCC=5V, Pulse=1000us
WARNING: Chip ID mismatch: expected 0x890D, got 0x1C0D (unknown)
Writing Code... 229.75Sec OK
Reading Code... 1.19Sec OK
Verification OK

Is there a document that explains how the "Chip ID" is assessed by the minipro? I want to understand the error messages better so I can be less of a pest.

As 27512's are getting rarer (at least New Old Stock) once I am sure the settings work should I attempt to add profile for the M5L27512K to it? Jameco still has them in stock, knowing them from a bulk order they made in the 1990s. Digikey is the only other source but even there it's a "marketplace product".

In GitLab by @radiomanV on Feb 17, 2021, 12:23

Is there a document that explains how the "Chip ID" is assessed by the minipro?

No, but that assessment is just a two numbers compare function in minipro. The firmware within TL866 is structured as simple functional primitives. Each primitive does a simple task like switching to a programming algorithm, controlling the right voltages, read or write a simple data block to a given address and so on.

The entire read/write flow of an action is decomposed in primitives by the minipro sofware. So for example in our case after the programmer version identification and protocol switching, the chip ID is read. Then that ID (a number) is compared with the expected chip ID specified by the device passed to -p. If they match, the next step is executed.
If no, well, the -y is evaluated; if set to true a warning is printed and the chip ID is searched through the entire database to eventually find the real device.

If the chip ID is not found in the database then you'll get something like got 0x1C0D (unknown).
If the -y is not specified (ie, set to false) and the chip ID does not match then a full stop is performed and the entire operation is aborted.

We also have the -x option which will entirely bypass/skip the chip ID read step but only when a read action is performed. A read action can be a blank check, verify or device read. For chip write operations the -x is ignored and only the -y is evaluated.

once I am sure the settings work should I attempt to add profile for the M5L27512K to it?

Sure. I'll be glad to assist you. This is the best thing about the open source software. Everyone can help.
Unfortunately all the hard work is done by reverse engineering a commercial Chinese product.

Look at this line:

<ic name="27512@DIP28" type="1" protocol_id="0x07" variant="0x10" read_buffer_size="0x200" write_buffer_size="0x80" code_memory_size="0x10000" data_memory_size="0x00" data_memory2_size="0x00" chip_id="0x890d" chip_id_bytes_count="0x02" opts1="0x40" opts2="0x0000" opts3="0x03e8" opts4="0x0068" opts5="0x4000" opts6="0x0000" opts7="0x0006" opts8="0x0c16" package_details="0x1c000000" fuses="NULL" />

This is the database definition for the Intel 27512 EPROM in DIP28 package.

You should change the ic name field from 27512@DIP28 to M5L27512K@DIP28 and the chip_id field from 0x890d to 0x1c0d. That's quite simple but if you want to raise the VPP programming voltage from 12V to 12.5V you should get your hands dirty and modify some opts fields. In our case the opts5 field.
This is a 32bit number with several packed bitfields inside. The VPP is a 4bit field at the bit 7 position. So the field mask would be 0xffffff0f.
So if we look at the database opts5="0x4000" we should change the second zero from the right with something to raise the VPP to 12.5V. These definitions are declared in the source code (main.c file) but i'll extract them here for you:

  tl866ii_vpp_voltages[] = {{"9", 0x01},    {"9.5", 0x02},  {"10", 0x03},
                            {"11", 0x04},   {"11.5", 0x05}, {"12", 0x00},
                            {"12.5", 0x06}, {"13", 0x07},   {"13.5", 0x08},
                            {"14", 0x09},   {"14.5", 0x0a}, {"15.5", 0x0b},
                            {"16", 0x0c},   {"16.5", 0x0d}, {"17", 0x0e},
                            {"18", 0x0f},   {NULL, 0x00}},

So in our case for 12V the filed should be 0x00 (which already is) and we want to modify it to 0x06 to raise the VPP voltage to 12.5V. So finally the opts5 filed would be: opts5="0x4060"

Because this xml file is generated by a dump tool, all those custom defined chips are located in a custom section within xml file (look at the line 16655 from infoic.xml).
Just define a new custom section like this:

    <custom name="MITSUBISHI">

    </custom>

And place the above modified line inside this declaration.
Then you should verify if the new chip is recognized by issuing a database search like this:
minipro -d 'M5L27512K@DIP28'
If all is ok you can use the minipro without manually specifying the --vpp, ----vcc, --vdd and --pulse or -y switch.
Just minipro -p 'M5L27512K@DIP28' -bz for example.

This way when a new xml database is generated i only copy the custom defined chips over the new generated xml file and we're all set.

If you're running the minipro tool from the source tree you should modify the xml file from the source directory. If you use it globally (you did a make install) then the infoic.xml should be located in /usr/local/share/minipro directory.

Hope this helps.

DavidGriffith / minipro-import-test

27512 #210