vdudouyt/minipro

An open source program for controlling the MiniPRO TL866xx series of chip programmers

This project has moved to https://gitlab.com/DavidGriffith/minipro/

minipro's Issues

Writing PIC config erases chip

Writing PIC config (or probably anything) erases the chip. This makes it impossible to set code protect since if you set it first, it gets erased. If you set it last, it erases the program you put into the chip.

Using the TSOP-48 adapter fails, but works in Windows

If I use the official TSOP-48 adapter (original V3), I seem to read garbage from the chip (A MX29LV160T). It reads extremely fast, much faster than the official software. Now if I try to read it in Windows first, and then in Linux, it seems to work... Programming, reading everything... Reading then goes slower.

Any clues?

It's almost as if some variable is undefined by this software, which is set by the Windows software, and apparently survives being software disconnected from a virtual Windows machine to the Linux host.

dpkg-buildpackage fails with missing libusb dependency info (error #2)

Can be solved by adding the following to debian/rules as a quick fix:

override_dh_shlibdeps:
dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info

Floating point exception error

I you give minipro -p "GAL16V8" -r readfile.jed minipro returnes with Floating point exception error.

Using make on OS X 10.13

Hi there!
I can't compile minipro on macOS v10.13 & Xcode 9.0
Could you help me?

terminal:
osx:minipro User$ make
make: pkg-config: Command not found
cc -g -O0 -c -o byte_utils.o byte_utils.c
make: pkg-config: Command not found
cc -g -O0 -c -o database.o database.c
make: pkg-config: Command not found
cc -g -O0 -c -o minipro.o minipro.c
make: pkg-config: Command not found
cc -g -O0 -c -o fuses.o fuses.c
make: pkg-config: Command not found
cc -g -O0 -c -o easyconfig.o easyconfig.c
make: pkg-config: Command not found
cc -g -O0 -c -o main.o main.c
make: pkg-config: Command not found
cc -g -O0 -c -o minipro-query-db.o minipro-query-db.c
make: pkg-config: Command not found
cc byte_utils.o database.o minipro.o fuses.o easyconfig.o main.o -o minipro
Undefined symbols for architecture x86_64:
"_libusb_bulk_transfer", referenced from:
_msg_transfer in minipro.o
"_libusb_claim_interface", referenced from:
_msg_transfer in minipro.o
"_libusb_close", referenced from:
_minipro_close in minipro.o
"_libusb_error_name", referenced from:
_minipro_open in minipro.o
_msg_transfer in minipro.o
"_libusb_init", referenced from:
_minipro_open in minipro.o
"_libusb_open_device_with_vid_pid", referenced from:
_minipro_open in minipro.o
"_libusb_release_interface", referenced from:
_msg_transfer in minipro.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [minipro] Error 1
osx:minipro User$

I was have before another error "minipro.c:1:10: fatal error: 'libusb.h' file not found" & "./minipro.h:7:10: fatal error: 'libusb.h' file not found" and it fixed by editing line in these files to "#include <libusb-1.0/libusb.h>". At now I can't resolve second problem.

Please add a free software license to this project

This is an awesome project! Please add a free software license such as GNU GPL or something else. This will encourage other people to contribute to your project.

happy hacking,
Felipe Sanches
Garoa Hacker Clube
São Paulo, Brazil

Last proper release 0.1 is quite old now

First, thanks to the maintainer and contributors for providing this important tool for embedded development on open systems.

I use the TL866 on Mac OS X and ran into a weird problem today, when I noticed that it would not read the config file of my ATtiny45. I checked the issues and found a showstopper that made reading of fuses on ATtiny impossible – but it had already been fixed long ago. It took me some moments to realize that Mac Ports does rely on the 0.1 release, which is four years old now … and quite buggy.

May I suggest to tag a new minor release like 0.1.1 in the near future, so packagers can notice that and finally catch up with some important fixes. ;)

New Programmer: TL866II Plus

XGecu alias Autoelectric has just released the TL866II Plus with new features.

Main changes:

• minium Vcc 1.8V support – enhanced from 3.3V
• maximum Vpp reduced to 18V – down from 21V
• NAND flash support
• 512MB flash support – up from 128MB
• Pin detection (?)

TL866A/CS are no longer in production.

Regarding the device list, some ICs will be supported by the TL866II Plus only (especially Vcc 1.8V devices), some by TL866A/CS only (Vpp 21V devices) and some by TL866II Plus and TL866A only (those needing the ICSP port).

There's also new Windows software (6.70 for TL866A/CS and 7.05 for TL866II Plus).

Build from github, crlf error

fakeroot dpkg-buildpackage -b
dpkg-buildpackage: пакет исходных текстов minipro
dpkg-buildpackage: версия исходных текстов 0.1-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: исходные тексты изменены minoru minoru@unknown
dpkg-buildpackage: архитектура узла i386
dpkg-source --before-build minipro
»pkg-source: ошибка: неправильное поле Format «3.0 (quilt)
dpkg-buildpackage: ошибка: dpkg-source --before-build minipro возвратил код ошибки 25

after this command all builds fine:
find ./ -type f -exec dos2unix {} ;

Power up / power off target device

After ICSP programming need an option to power up/power off the device with ICSP VCC pin.

NAND

Приветствую! Мне сказали, что minipro не поддерживает программирование NAND-флеш через адаптер TSOP48. Так ли это? Нельзя ли добавить в таком случае новый протокол ".protocol_id" для программирования NAND? Или это принципиально невозможно? Или для этого нужно менять прошивку самого программатора? Или подскажите мне пожалуйста, где я мог бы найти информацию, чтобы самому добавить такой протокол? Благодарю за труд!

Hello! I was told that the minipro does not support the programming of NAND flash using adapter TSOP48. Is it really so? Is it possible to add in this case a new Protocol ".protocol_id" for programming NAND? Or is it fundamentally impossible? Or do we need to change the firmware of the programmer? Or tell me please, where could I find information to add such a Protocol? Thank you for your work!

Windows Support?

Any idea what it would take to support windows? This seems like a great tool, and the need for a command line access to the MiniPro under window is great.

Warning: firmware is too old??

I recently purchased a Minipro TL866A and found this software. Thank you for making it! I just installed it on my Ubuntu laptop and it compiled and installed correctly. As a test I tried reading the contents of an AM27C128 @dip28 EPROM I had lying around (the ROM chip from my Replica I) and that seemed to work correctly (so far anyway.. I have yet to try writing to an EPROM) However I get the message "Warning: firmware is too old" My device is recognized as a Minipro TL866A v3.58.2. Will this software still work with my older firmware, or is there a problem and should I upgrade to a newer firmware? If so, can someone provide a direct link to it? The only sites I am able to find are in Chinese, which I do not speak/read, and the Google translation is somewhat lacking, and I have had no luck navigating them.

Support for Microchip new devices (12LF1820/12LF1844)?

Hi all,
I'm new on gitHub, how can add support for a new device in minipro?
Thank you so much

Claudio

Firmware is too old / Core dumped

Hello minipro fans,
I'm new to PLD and trying all this out.
Ubuntu 16.04.1 LTS, minipro 0.1, TL866A
from lsusb: Bus 002 Device 042: ID 04d8:e11c Microchip Technology, Inc. TL866CS EEPROM Programmer [MiniPRO]

Here's what I get.

$ sudo minipro -p "ATF16V8B" -r testread.bin
Warning: firmware is too old
Found Minipro TL866A v03.2.58
Floating point exception (core dumped)

The little Minipro lamp blinks when this happens so something is reaching the hardware at least.
On core dump, I get the Ubuntu "splat" screen. Sorry, getting info out of it is vague. I've updated everything and my system whines about some Gnome conflict. I'd imagine that doesn't hurt minipro, but I've no idea.
Thanks for any help.

Some PICs have 2 Fuse Words

Great work and seems to work fine. However, some PICs (e.g., 16F886) have two config fuse words. I tried adding a 2nd entry in the fuse list with the same cop code and offset of 2 but that gives an I/O error presumably because the firmware is preset for the smaller config area.

I haven't dug into the firmware to determine how that works yet.

Reading fuses over icsp error

minipro -i -p "ATMEGA8L" -c config -r atmega8l.fuses
Found Minipro TL866A v3.63.2
Chip ID OK: 0x1e9307
Reading fuses... IO error: expected 10 bytes but 9 bytes transferred.

Testing TTL chips

The TL866 is capable of testing IC chips with the Windows app. Is it possible to use the minipro command to test TTL's such as the 74HC86? I see that the chip is listed in the supported output, but how do I verify that it is working? Is it just a matter or reading it and comparing the hex output to a known good chip?

Issues with newer firmware?

I have been using my TL866 for a bit exclusively under Linux with satisfaction, it was always working fine.

Then I connected it to a Windows machine, and the Autoelectric software updated it. Since then I am having lots of issues under Linux. It clearly goes "too fast" and 90% of the time it doesn't program EPROMs correctly.

Firmware version:

Found Minipro TL866CS v03.2.81

Merge in changes from https://github.com/rozhuk-im/minipro

A year and a few months ago, @rozhuk-im made extensive changes in his own fork (https://github.com/rozhuk-im/minipro) and @vdudouyt never replied to his pull request. As time rolled on, the two forks diverged to such a degree that a clean merge is no longer possible. @rozhuk-im's changes are very useful and I feel we should begin the process of manually applying his changes to @vdudouyt's repository.

Downloadable release source archive (with a version number)

Hello I'd like to add this utility to MacPorts and it gets complicated without a versioned source archive (I can't use the generic master zip file that github provides I need one with a version number in it). It'll be really nice if you could provide one.

RFE/RFD: Defining your own chip configs

Developers that only occasionally dump stuff for Mame often have a TL866, which works well enough for EPROMs, but the database does not cover many PROMs. The PROMs are usually very simple; address lines, data lines, GND, VCC, and chip enable. Current method of dumping them is usually to pull out an arduino, breadboard and a handful of wires. Then rewire for each chip type. On the small board I'm working on now there are 3 diffrent chip types.

It would be nice if we could just add the chip definition to the TL866 database and recompile instead. So is there an ELI5 for what to write in the database to get a specific pinout just for reading? Writing is not interesting.

For reference, here is the data cheet for one of the ones I'm about to dump: http://hxc2001.free.fr/Squale/datasheet/TBP18S030.pdf

check device ID

I'm trying to read out a DS1645 for a tds520 scope I'm fixing.
The DS1245 is listed as supported. they are the same except one is larger than other.
Is there anyway to disable device ID check with your tools like in the GUI version?

Thanxs...
Great work FYI.
Always want to use linux/bsd vs WINBLOWS

AM28F020A support?

I have a whole tube of these things, but it seems that only the AM28F020 is supported. The AM28F020A has a built-in sequencer that does most of the work, simplifying the erase and program process. However, this makes it completely incompatible with the AM28F020 mode. Since it is a much simpler protocol, it should not be very difficult to implement.

Can't program gal 22v10d with jedec file

Hi!

I'm trying to burn a jedec file into a Lattice 22v10d GAL:

andreas@Elektronik2:~/pal_gal/c64_z80/gal$ miniprohex -p GAL22V10D -w
z80logic.jed
Found Minipro TL866CS v03.2.72
Incorrect file size: 1764 (needed 5892)

andreas@Elektronik2:~/pal_gal/c64_z80/gal$

Nu success so far. What am I doing wrong?

Thanks in advance,
Andreas

Version number mismatch compared to Windows app

I just started using my new TL866A and I had to upgrade the firmware, however while this program worked fine, I noticed that it is reporting a different version number to the Windows application:

Before the reflash the Windows program reported device firmware 3.2.58, while this application reported 3.58.2. After the reflash the Windows program told me I was now on firmware version 3.2.72, while this app is reporting 3.72.2.

Hopefully it's just a simple matter of swapping the version numbers so it's consistent with the Windows app!

Vpp/Vcc/PulseWidth setting

Very nice work. I am planning to use your code under OSX and hope to replace my GQ4X and Wellon VP280 programmers. So the final utility should have all the possibilities the Windows SW has.
In your code I did not find any hint on how the Programming/Verification voltage and the programming pulse length for i.e. EPROMs is set / can be changed. Did you already find out anything about this?

Btw., I have successfully written a utility to use the original "InfoIC.dll" to read the chip information - it does return all of the members from the device_t structure - except "write_unlock". Where the hell did you get this value from?? I can not imagine, you USB-sniffed all 10000+ settings... :*) On the other side, the DLL returns 2 additional values, that I can not make any sense of, but I bet they have to do with the Vcc/Vpp/pulse settings.

Multipple entries in devices.h

Hi
I have a ST M27C256B DIP eprom, I can successfully read and write it from MiniPro V6.00 in wine but fail to read it with minipro:

% ./minipro -p "M27C256B @dip28" -c code -w test3
Found Minipro TL866A v3.62.2
Chip ID OK: 0x208d
Couldn't open file: No such file or directory

There are multiple entries in devices.h of '.name = "M27C256B @dip28"', that whould be the ST and SGS versions? Is there a way to specify brand?

Thanks for the utility btw! :)

Problem programming 16f84

Hi,

Could just be me being a noob, but I am having problems burning a hex file compiled using mpasmx to a PIC16F84. When I try to burn the firmware to the uC, I get the error below:

pete@xps:~/pic16f84/blink$ minipro -p pic16f84 -c code -w hex/blink.hex
Found Minipro TL866CS v3.62.2
Incorrect file size: 200 (needed 2048)

When I disassemble the hex file, I get the listing below.

000000: 280d goto 0xd
000001: 0181 clrf 0x1
000002: 0801 movf 0x1, w
000003: 3c20 sublw 0x20
000004: 1d03 btfss 0x3, 0x2
000005: 2802 goto 0x2
000006: 3400 retlw 0
000007: 0181 clrf 0x1
000008: 0801 movf 0x1, w
000009: 3c10 sublw 0x10
00000a: 1d03 btfss 0x3, 0x2
00000b: 2808 goto 0x8
00000c: 3400 retlw 0
00000d: 1683 bsf 0x3, 0x5
00000e: 301f movlw 0x1f
00000f: 0085 movwf 0x5
000010: 3000 movlw 0
000011: 0086 movwf 0x6
000012: 3007 movlw 0x7
000013: 0081 movwf 0x1
000014: 1283 bcf 0x3, 0x5
000015: 0185 clrf 0x5
000016: 0186 clrf 0x6
000017: 1406 bsf 0x6, 0
000018: 2007 call 0x7
000019: 1006 bcf 0x6, 0
00001a: 2817 goto 0x17
002007: 3ff0 addlw 0xf0

A quick search on google doesn't bring up anyone else having the same problem, which makes me think I'm doing something stupid, so sorry of this is just a waste of everyone's time.

Is support for DS12887A (PC BIOS/CMOS) chips possible?

I am wondering whether it is possible to add support for the Dallas DS12887A and similar chips, used on many older PC motherboards for storing settings and the clock when the PC is switched off.

Technically this is a non-volatile RAM chip (has an internal battery) so it would be nice to be able to read and write the contents with the TL866 but I am not sure how flexible the devices are.

Are all the read/write algorithms in the minipro software, or are they stored in the TL866 firmware?

Testing 6116 RAM

Hi, how would you go about testing a 6116 RAM with this command line tool? Is there a particular file to write and read back or a function to invoke? I have it successfully compiled for macOS 10.12.

Testing

I have a somthing chips taken from motherboards and other... Let`s do testing and compare with windows version at freetime and developer request! I have a chips:

1. 25x80avaiz by WINBOND
2. 49lf004b by SST LPC
3. p89v52xfa by NXP i8051 microcontroller
4. atmega16a
5. atmega32a
6. attiny26
7. attiny261 not present in tl866 windows software
8. 25x80 like unnamed chip(DIP case)
9. 2 soic unknown spi flash

Duplicate entries in devices.h

While working on the OS X port, I noticed that the devices.h entry for the M27C4001 @DIP32 was duplicated in the devices.h file. I wrote a python script to parse the file and print out any duplicate entries. When I run it, I see 1554 duplicate entries. Some are in there twice and some three times.

I put the script here: https://gist.github.com/rjwalsh/d85b898fa27a54034a22

Reading config file truncates top byte of config word

When writing a PIC config, easyconfig.c (line 141) has the following line:

if(!sscanf(strval, "0x%02x", &intval) ...

This causes a hex config word to be truncated at 2 characters when it should be 4. I would push the fix, but don't have my own fork.

The printf just below probably ought to be %04 too although since it overflows it works ok.

MX25L4005A

Emit a list of supported devices

It would be nice if I could do "minipro -l | less" to get a list of all devices supported so I can be sure I select exactly the right device name.

ST M27C256B chips all fail strangely

I have a tube of ST-branded M27C256B UV-erasable EPROMs that all fail to have stuff written from 0x200 to 0x27F. The first bad byte written is 0x00. Subsequent bad bytes are 0xFF. Then from 0x280 on, the chip contains the expected data. Would this be caused by a failure in the chips or might there be something wrong with the controlling program? I don't have any other means of programming chips.

Unknown device

System UBUNTU 14.04 x64 (TL866CS (minipro))

Have this:
./minipro -p am29f040 -r am29f040.bin
Unknown device

Thanks

Q: hacking USB dumps (firmware update, version test, system test)

During the latest upgrade to Minipro 6.16, I did a full dump of the firmware update process using Wireshark. In order to avoid reinventing the wheel: does anyone of the developers have tools at hand that extract the payload data from such a dump? Would be a bit cumbersome to extract this packet-wise using tshark and additional scripting.

If of common interest, I can also provide a version-test dump and a system test dump (including error on one of the pins during GND test).

Doesn't seem to work on OS X El Capitan

I've installed libusb using brew. I then build with the Makefile.osx, and everything seems to go fine. I then plug in my TL866CS programmer from autoelectric.cn with a W27C512 int the 40 pin and run this command line.

./minipro -p "W27C512 @dip28" -r "test.hex"

Nothing is printed and the command never returns. However, if I unplug the programmer, I get:

IO error: bulk_transfer: LIBUSB_ERROR_IO

Any ideas?

Intel hex

Great code @vdudouyt it would be even better if it was able to read and write intel hex format files.

ATtiny2313A does not run after RSTDISBL fuse was programmed.

I'm having trouble programming an ATtiny2313A with the RSTDISBL fuse enabled. It works when using the Windows software under Wine. Here is the config (SPIEN off, RSTDISBL on):

fuses_lo = 0x0064
fuses_hi = 0x00fe
fuses_ext = 0x00ff
lock_byte = 0x00ff

After the fuse is programmed, only 0xff is read from the uC, and the part can no longer be identified. The same happens with the Windows software. The difference is that the uC actually runs when using the Windows software. With this software, it looks like it stays in reset...

I can reset the fuse (ie fuses_hi = 0x00df) just fine and the uC will then again respond normally.

OS X 10.9 support

Hi there,

I'm going to attach a diff that allows minipro to compile on OS X. I tested it with my tl866cs and I was able to read an ST eeprom (M27C4001, pulled from an old SparcStation 10).

Quick summary of diff:

• Add a return NULL to the end of get_device_by_name, to stop LLVM warning about no return value at the end of the function.
• Added a prototype for Config_open to easyconfig.h, to stop LLVM warning about missing declarations for functions.
• Made update_status return void instead of int, to stop LLVM warning about no return value at the end of the function.
• Changed a bunch of char *'s into unsigned char *'s to stop LLVM warning about implicit casts from char * to unsigned char *.
• Don't include malloc.h on OS X in minipro.c. Include stdio.h instead.
• Check libusb function calls for errors and print them out nicely. This was helpful while I was trying to debug the port.
• Before attempting a bulk transfer, claim the interface. On OS X, the transfer fails otherwise.
• Changed msg_transfer, msg_send and msg_recv to take a signed integer length instead of unsigned, because the libusb calls all take signed values. The compiler didn't complain about this - I just noticed it while I was doing the port.
• Make minipro_get_system_info return void instead of int, to stop LLVM warning about no return value at the end of the function.
• Added prototypes for minipro_read_fuses, minipro_write_fuses, minipro_prepare_writing and minipro_get_system_info to stop LLVM warning about missing declarations for functions.

Not yet tested:

• I didn't attempt to write to the eeprom.
• I haven't tested whether I broke the Linux build. In particular, the calls to libusb_claim_interface should be checked. Nothing of the other changes I made should impact Linux, though.

Suggested change of project description

It seems more aesthetically pleasing to have the following text as the project's description: "An Open Source program for controlling the MiniPRO TL866xx series of chip programmers.". It should also help casual wanderers find software for burning chips under Linux.

udev files put in the wrong place for local compilations

The change 52786b1 changes the location where minipro's udev file is written to from /etc/udev/rules.d to what renders as /lib/udev/rules.d. This is okay for binary packages (ie debs), but not when minipro is compiled and installed from source. Some mechanism is needed to detect if a package is being built and to use /etc/udev/rules.d if this is not the case.

Issues writing eeprom data to Attiny85 and Atmega328

writing and reading eeprom data on Attiny and Atmega328 not working.
had a look in main.c. think 'addr = addr >> 1' should only be done for flash, but not eeprom.

Some ATtiny fuse support missing

Most newer ATtiny devices use protocol ID 0x73. No case in the fuse select code added fuse support. I have a code patch to apply to main.c to (hopefully) fix this issue, but it has only been partly tested with the ATtiny13A. I also have ATtiny44A, ATtiny45, ATtiny84A and ATtiny85 devices to test fuse configurations with,

Programming 12F675

I was trying to burn a 12f675 device. These devices reserves one word at the end of programming space to calibrate its internal clock. This word is calibrated by the factory before the device is been delivered to market. Its is very common to do not overwrite the original value.

The device definition, inside device.h, follows:
{
.name = "PIC12F675",
.protocol_id = 0x63,
.variant = 0x73,
.read_buffer_size = 0x80,
.write_buffer_size = 0x20,
.code_memory_size = 0x7fe,
.data_memory_size = 0x80,
.data_memory2_size = 0x00,
.chip_id = 0x00,
.chip_id_bytes_count = 0x02,
.opts1 = 0x00,
.opts2 = 0x00,
.opts3 = 0x40,
.opts4 = 0x1102330,
.package_details = 0x8000200,
.write_unlock = 0x1ba,
}

Although the device has 1024 words of code memory, the definition above declares only 1023 words (2046 bytes). I think it is done in order to preserve the original calibrated clock already set.

There are two problems on the above limit code approach:

1. the program does not work. It can not read or write data from the device. At line 146 of main.c the instruction:
   if(size % device->read_buffer_size != 0) {
   does not allow code odd aligned code - different from value specified device->read_buffer_size

2. if the code size would be set to the correct value 1024 words (which will be aligned to device->read_buffer_size), during normal device programming, a impatient user would overwrite the original factory value set. This behavior will force users to read this value and set it on its binary source file, before program the device.

My suggestion is create a memory map, for each device, specifying memory regions where the program must read from device before write the buffer to the device. Its a good idea create a option flag disabling this behavior.

Support for ATmega8/16/32U series wanted

These are newer AVR microcontrollers with integrated USB. Well, not so new, as Arduino Leonardo uses an ATmega32U4.

Series includes at least:

• ATmega8U2 – id 0x1E9389
• ATmega16U2 – id 0x1E9489
• ATmega32U2 – id 0x1E958A
• ATmega16U4 – id 0x1E9488
• ATmega32U4 – id 0x1E9587
• ATxmega16A4U – id 0x1E9441
• ATxmega32A4U – id 0x1E9541
• ATxmega64A4U – id 0x1E9646
• ATxmega128A4U – id 0x1E9746

Datesheets are here:

• ATmega*U2
• ATmega*U4
• ATxmega*A4U – file size 24MB!

I will look into the datasheets next days if the programming scheme resembles some existent devices.

Device query option?

Apologies if I've missed something blatantly obvious, is there a way to query what device is in the programmer (ie, if the markings have been scrubbed off the chip) ?