Support for XGECU T48 aka TL866-3G ? #270

Open DavidGriffith opened 2 years ago

In GitLab by @gtoal on Aug 30, 2022, 09:18

Can this software drive the T48/TL866-3G? I've searched the repository and can't see a reference to it. Can I just treat it like a TL866ii or plus?

Support list is at www.xgecu.com/MiniPro/T48_List.txt

manufacturer's forum: http://forums.xgecu.com/viewthread.php?tid=684&extra=page%3D1

manufacturer's software: http://forums.xgecu.com/viewthread.php?tid=20&page=1&extra=#pid23

Thanks.

In GitLab by @emrickds on Aug 31, 2022, 09:18

Hi, Grahm,

This is almost identical to a now closed issue from about a week ago.

I've just received a T48 and confirmed that it is functional with the manufacturer's software (version 12.15) on Windows. On Linux, minipro doesn't seem to recognize the programmer. Any attempt to use it results in "IO error: bulk_transfer: LIBUSB_ERROR_OVERFLOW" with an EPROM in the programmer and no response if there is no EPROM in the programmer.

I don't yet understand enough of David's code to help at this point, but I'm available to test any updates, should that be of any value..

Dan

In GitLab by @gtoal on Aug 31, 2022, 10:59

Thanks. I guess I should have ordered a TL866ii instead. I ordered one of these T48's because my preferred Willem GQ4x4 doesn't handle these GALs at all, and the T48 seemed to have the broadest range of supported chips.

In GitLab by @emrickds on Aug 31, 2022, 14:33

Well, maybe together we can help David add the T48. That's my hope, at least.

As much as I hate the situation, I'll use my T48 with that other OS for the time being.

In GitLab by @bert.vermeulen on Sep 6, 2022, 09:26

I've just received my T56, apparently top of the line in the series. I'd like to help get this supported as well as the T48.

@DavidGriffith do you have any insight into any protocol changes that may have happened in the T48/T56?

I could also use some guidance on how to properly test these, for example a list of chips that puts the programmer/protocol through its paces. I don't really want to just add the USB vid/pid and assume that's all it needs.

In GitLab by @emrickds on Sep 6, 2022, 16:21

FWIW I've been unable to get the T48 to be recognized under WINE on Linux Mint. This makes me wonder if the cause of it not being recognized by minipro on the same machine might be something other than minipro. As soon as I get a chance, I'll try minipro on a different machine with a different Linux distro and advise.

In GitLab by @bert.vermeulen on Sep 7, 2022, 04:23

@emrickds or @gtoal Could you get me the output of lsusb -v -d <vid>:<pid> where vid and pid are the appropriate numbers for your T48? On the TL866+ this would be lsusb -v -d a466:0a53.

In GitLab by @emrickds on Sep 7, 2022, 06:21

@bert.vermeulen : I've attached the output requested. Ventor:product are the same. Command finishes with message presumably from stderr: "can't get debug descriptor: Resource temporarily unavailable"

Device now functioning under WINE. I'm on a new distro of linux mint so I'll try a new install of minipro and report.

lsusb_xgpro.txt

In GitLab by @emrickds on Sep 7, 2022, 06:52

With new build of minipro on Linux Mint 20.3 the T48 RUN light blinks and the program ends with: "IO error: bulk transfer: LIBUSB_ERROR_OVERFLOW" Command was 'minipro -p 27C256 -r test.bin' Researching.

In GitLab by @bert.vermeulen on Sep 7, 2022, 06:54

Thanks for the lsusb, Dan.

Yes, the T48 and T56 have a different USB endpoint profile than the TL855/II. The USB VID/PID are the same, but you can distinguish them by the number of endpoints (4 and 6 respectively). The protocol is thus at least a little different, but I'm still digging into it.

Did you do anything special to get Wine to talk to that USB device? Mine doesn't find it, and I have no idea how to enable that in Wine.

In GitLab by @emrickds on Sep 7, 2022, 08:08

Re: WINE First, on LM 20.3 don't use distro version of WINE. It is BROKEN!! Use winehq-stable from WINE web site, https://wiki.winehq.org/Download . I used the Ubuntu version. If you don't have libusb installed, install in manually. Then manually install libusb-dev. After the libusb-dev, the big thing is the udev rules entry 51-minipro.rules which should contain: SUBSYSTEMS=="usb", ATTRS{idVendor}=="a466", ATTRS{idProduct}=="0a53", GROUP="plugdev", MODE="0666"

I think that was it.

In GitLab by @radiomanV on Sep 7, 2022, 11:42

The wine usb wrapper (setupapi.dll) can be compiled with debug support with make CFLAGS=-DDBG.
This way when you run the xgpro software from console (with wine ./Xgpro.exe) the wrapper will print all usb transactions to console in hex format. This way you can view what's under the hood.
As i'm away for some time, my development branch is quite stalled now but, i will gladly respond to any technical questions regarding the Xgecu programmers.

For now if anyone with a T48 and T56 can compile my usb wrapper in debug mode and paste here the console output when the software is starting.
Something like this:

Dll Loaded.
Found Xgpro v7.32
Base Address = 0x00400000
Code section = 0x00401000,0x00201C00
Open Devices found at 0x00461E70
Close Devices found at 0x00461C60
Usb Handle found at 0x00696B74
WinUsb Handle found at 0x0069E0E0
Devices count found at 0x0069DAD8
Open devices.
Close devices.
RegisterDeviceNotifications hWnd=1E02E04

............................................
some usb transactions in hex format here..
............................................

Thanks.

In GitLab by @bert.vermeulen on Sep 7, 2022, 12:30

Thanks @radioman, but I'm used to sniffing USB protocol stuff like this with usbmon, and that works well. Changing out ubuntu's wine for winehq's fixed the wine problem.

In GitLab by @radiomanV on Sep 7, 2022, 12:45

Well, yes, any sniffer will do the job. I just wanted to show that the usb debug stuff is already built in. If you or someone else can show me some usb captures from T48/T56 i'll be happy to look at.

In GitLab by @emrickds on Sep 7, 2022, 16:10

@radioman I clearly have something mis-configured. I keep getting "No such file or directory" errors for .h files when I run make.

Will try more later.

In GitLab by @radiomanV on Sep 7, 2022, 18:13

Perhaps some dev packages not installed.
Here is the debug version of setupapi.dll setupapi.dll

In GitLab by @bert.vermeulen on Sep 8, 2022, 05:33

A little extra work in the protocol to identify a device, but there's some extra info as well:

sumner: ./minipro -k 
Detected TL56
  Firmware version: 1.59
  Device version: 6
  Device code: 13202164
  Serial number: UWD85ZEP9DR8UMARD1H56AQJ
  Manufacturing date: 2022-03-06 19:25
  Regional distributor: XGecu Directly

In GitLab by @emrickds on Sep 8, 2022, 06:46

Bert - just did fresh download/compile/install of minipro. Executing minipro -k gives the old LIBUSB_ERROR_OVERFLOW. Rules in udev are as instructed. Might I have overlooked something?

Using Xgpro with WINE and the debug version of setupapi.dll gives screens and screens of output while successfully reading or programming a 27C256. I'll provide an edited version for radioman to look at soon.

In GitLab by @bert.vermeulen on Sep 8, 2022, 07:26

Sorry if it wasn't clear, but that's the output of the code I'm working on here, not current git minipro. Check out the new fields the T56 has, compared to the TL866II+:

sumner: ./minipro -k 
Detected TL56
  Firmware version: 1.59
  Device version: 6
  USB voltage: 4.94
  Device code: 13202164
  Serial number: UWD85ZEP9DR8UMARD1H56AQJ
  Manufacturing date: 2022-03-06 19:25
  Regional distributor: XGecu Directly
Detected TL866II
  Firmware version: 2.109
  Device version: 5
  Hardware version: 4
  Device code: 19336096
  Serial number: DA786SHGJINCN4BMJOLN

The vendor software also sends a bunch of stuff when finding a T56, apparently an FPGA stream.

In GitLab by @emrickds on Sep 8, 2022, 10:44

@radioman Attached file is part of the output of Xgpro.exe under WINE using the debug setupapi.dll you graciously provided.

First part is from start through first 1K of hex/ASCII. Second part is just after last 1K of hex/ASCII to the end. Hopefully it means something to you. (The complete file is 143 K) XgproDebug.txt

In GitLab by @radiomanV on Sep 9, 2022, 24:36

Hopefully it means something to you

It means everything to me :)
Thank you for your capture.

As i see the request info size is the same as in TL866II but there are some changes in how strings and additional info is distributed. The device version member is in the same position with 1=TL866A, 2=TL866CS, 5=TL866II+, 6=T56, 7=T48.
This is easy. Now there's an extra command: 3E 00 F7 F7 20 2D F7 F7 with the opcode 3E which i don't know what is. The last command code defined in current version of minipro is 3D used for switching device in boot mode.

#define TL866IIPLUS_BOOTLOADER_WRITE 0x3B
#define TL866IIPLUS_BOOTLOADER_ERASE 0x3C
#define TL866IIPLUS_SWITCH 0x3D

The next part is the same like in TL866x (begin_transaction->read_id->read_data->end_transaction).

The data is divided using the same rule like in TL866II. If the header+payload <= 64 then only endpoint 1 is used, otherwise the header will be sent over the endpoint 1 and payload divided/distributed over the remaining endpoints using some weird algorithm (see usb_nix.c line 205 and 235).

The T48 and T56 might use a different splitting/interlacing algorithm so pay attention to this, the usb code should be adapted (both win and nix versions) for these two new programmers.

The next thing is the database. I don't know if the T48 or T56 uses the same algorithm and same data structure to map the device structure members to begin_transaction command structure (see tl866iiplus_begin_transaction) but i guess not. Pay a very special attention to this one because you can fry your chip by applying a wrong supply voltage.
I believe that this is the most hard task. Writing the fast xml sax parser used in minipro (because the facile dom model was dead slow for the giant database xml file) was a nightmare, not to mention the C# software used to dump the .dll database with all its members. Also there are many chips that are supported only by these new programmers. This should be taken into account.

The new T48 and T56 have a different DC/DC voltage regulators and different voltage levels (64 voltage levels compared to TL 866A/CS=8 levels and TL866II=16 levels). Also the I/O voltage can be programmed instead of fixed 3.3v voltage used in TL866xx. This also should be investigated. Perhaps new voltage lookup tables should be written.

Another thing is the increased pin drivers count (48/56). The new protocol for the raw pin manipulation protocol (used by hardware test/logic test and bad pin contact test) must be reversed. As someone said above there's an FPGA which must be programmed prior to any transaction? perhaps used as pin driver mux or else.

Another chef's specialty is the device update. The protocol must be reversed, the encrypted firmware file structure should be reversed also.
Well, and this should be done by a person and that person should be warned that the risk to brick his device is very high.
I bricked two TL866A and one TL866II+ when i wrote the firmware update code, so beware.

The current minipro code base covers only lets say ~60 percent from the total of chips supported by the official windows client. No NAND chips, no RAM tests, some controllers are not supported. The effort should be concentrated to this. I have managed to remove all hardcoded things from database code (database.c) and made all things configurable like this:

<ic
   name="ATMEGA8@DIP28"
   type="2"
   protocol_id="0x1d"
   variant="0x1143"
   read_buffer_size="0x100"
   write_buffer_size="0x40"
   code_memory_size="0x2000"
   data_memory_size="0x200"
   data_memory2_size="0x00"
   page_size="0x0040"
   pages_per_block="0x0000"
   chip_id="0x001e9307"
   voltages="0x0400"
   pulse_delay="0x0001"
   flags="0x00182630"
   chip_info="0x0081"
   pin_map="0x0025"
   package_details="0x1c000700"
   config="avr_15"
/>

<config name="avr_15" num_calibytes="4">
   <fuses count="2">
      <fuse name="lfuse">0x00ff,0x0062</fuse>
      <fuse name="hfuse">0x00ff,0x0099</fuse>
   </fuses>
   <locks count="1">
      <lock name="lock">0x003f,0x00ff</lock>
   </locks>
</config>

instead of this:

<ic chip_id="0x1e9307" chip_id_bytes_count="0x03" code_memory_size="0x2000" data_memory2_size="0x00" data_memory_size="0x200" fuses="avr2_fuses" name="ATMEGA8@DIP28" opts1="0x04" opts2="0x0040" opts3="0x0001" opts4="0x182630" opts5="0x0400" opts6="0x0000" opts7="0x0081" opts8="0x0c25" package_details="0x1c000700" protocol_id="0x1d" read_buffer_size="0x100" type="2" variant="0x43" write_buffer_size="0x40"/>

where avr2_fuses are hardcoded in dabase.c and other things but there's a lot of work to do.
So we must change the database model to be more flexible prior to any other programmer support implementation.

Also please keep the -k and -Q output as is. These commands are in use by some GUI software or when minipro is compiled as library. These are not intended for normal user; i personally know what programmer i use :), see issue #183 for this. Any extended information including the manufacturing date, firmware version and perhaps the mother name of that manufacturer :) should be printed by -V command.

Another thing is the manufacturer. I know, we want a nice opensource software to work with. He not. He knows that his products are used by many hobbyists due to the opensource software but don't want to contribute. I once asked why and he said that will not disclose any protocol/documentation because of the device cloners and counterfeit programmers, so he is defending his intellectual property. Instead from time to time he likes to change something into protocol/database/whatever to block the opensource software. So be prepared that code that you write today after so much digging and energy consumed, tomorrow after a firmware update might be useless.
That's why i don't personally agree blindly bumping the needed firmware version to last version because someone tested one chip and worked. This is not enough.

Sure, i encourage everyone with enough free time and energy to focus his energy into reverse engineering the protocol and database. And most important to report (here perhaps) his findings. Perhaps someone will reverse the schematic diagrams! (i did this for TL866A/CS/II+).

So please who want to contribute please focus your energy into hacking the protocol/database, disassemble the windows software client to see how they do this and that and don't waste your time and energy to fix some new compiler versions warnings and other compiler wet dreams like this. The last three merge requests are an example of this, no offence.

@emrickds can you tell me when the 3E 00 F7 F7 20 2D F7 F7 command is printed? when starting the xgpro software or when you hit the read button? I want to know if the command is part of the read command or the device identifying process.
Thanks!

In GitLab by @bert.vermeulen on Sep 9, 2022, 03:09

@radioman you are right on all fronts.

Also, I think the protocol differences are going to be substantial enough that a proper documentation effort is required here, starting with the existing TL866* and then the TL48/TL56 protocol. A start of this was made in tl866iiplus.md, but it's really just a summary. The only real documentation is the code, currently :-(

I would suggest using the gitlab wiki facility. I've had great success with documenting reverse-engineered protocols on a wiki, as collaboration is so easy.

I think the codebase is in rough shape wrt support for different hardware -- as you noticed there is lots of hardcoded stuff, and it really doesn't scale to any more hardware support. I've made a start on abstracting out some stuff, but I'd like @DavidGriffith's OK on this, so I've mailed him outlining my views. I hope he's ok with the refactoring that will be needed.

In GitLab by @radiomanV on Sep 9, 2022, 03:31

I would like to see that outlining also. Can you send me those?
Thanks.

In GitLab by @emrickds on Sep 9, 2022, 11:36

@radiomanV From what I can tell, the string in question does, indeed, appear just after clicking the "READ" button on the sub-window displaying the ZIF socket.

Interesting that I cannot repeat the same capture. Last night I erased a handful of EPROMs and apparently the test chip was in that batch. I've done a number of 2716 and 27C256 reads today but none produce the same 3E 00 F7 F7 20 2D F7 F7 at the READ button point. I'm wondering if the chip type/content can influence the line.

I'll but together a few samples along with chip descriptions and send along soon.

In GitLab by @emrickds on Sep 9, 2022, 13:17

@radiomanV I read a number of different chips and none produced the command string you asked about. Not only that, but three successive reads of the same chip produced three different command strings.

Here is that info for an INTEL M2716. After UV erase chip still had random data so probably no longer useful. Here are the command strings in any case.

3E 00 F2 F7 20 ED F2 F7 3E 00 EE F7 20 FD EE F7 3E 00 F1 F7 20 1D F2 F7

For each test I restarted Xgpro. For the last one I removed the chip and went through the selection process before re-inserting and reading. It appears I got the same data each time (though no exact comparison) but different command strings.

Will continue efforts as time permits.

In GitLab by @emrickds on Sep 9, 2022, 13:21

Sorry about the format mistake. Each of the three separate commands begin with 3E

In GitLab by @radiomanV on Sep 10, 2022, 24:34

Ok, thanks for your captures!

Let me try to get back up to speed on this. What are the practical differences between the T48 and T56? Sure, I'd love to have both supported.

In GitLab by @tbejos on Oct 5, 2022, 13:57

Not sure if this is helpful or not but I just opened up my T56 and it looks like it has a PIC32 MZ1024EFH 144 microcontroller in it but it also has a SPARTAN-6 X6SLX9 FPGA as well.

I can take some pictures of the T56 board's or try and identify additional components on the board if that would be helpful

Yes please!

In GitLab by @tbejos on Oct 10, 2022, 13:53

Here are some pictures I took of the boards. Sorry there are some shadows in a couple of them. I had to put my light on an angle in order to get the laser etched text to show up. Let me know if there is anything else you'd like or if you want me to try and identify any markings that aren't clear from the pictures

Here is the top board which is mostly just the actual IO expansion top_brd-top_side top_brd-bot_side

Here is the bottom board with most of the components on it bot_brd-top_side bot_brd-bot_side

In GitLab by @JohnDMcMaster on Nov 10, 2022, 24:28

FYI open-tl866 is taking a stab at T48 right now. A few quick takes:

Detailed board images: https://proghq.org/media/xgecu/t48/
Someone is working on schematic
I'm not aware of anyone hooking up a debugger to the PCB yet, but we suspect it will be locked
Host software(s) have been disassembled and various analysis done on firmware encryption (not broken yet)
A (brute force) hardware firmware extraction attempt: https://twitter.com/johndmcmaster/status/1590617416455065600
sipr0n discord has a dedicated t48 channel that is quite active right now. e-mail me if you want a join link (johndmcmaster at gmail.com)

In GitLab by @JohnDMcMaster on Nov 16, 2022, 23:50

FYI we have made significant progress on this and expect to have the ability to update and load our own software soon. We don't have any immediate plans for minipro cli support, but it is on our radar

In GitLab by @gkdavids57 on Dec 10, 2022, 09:22

@JohnDMcMaster - is your team trying to produce your own firmware for the programmer? And if you succeed, are you planning to produce a GUI, as well? And finally, assuming you are creating a GUI, will your GUI operate in a macOS environment?

In GitLab by @JohnDMcMaster on Dec 21, 2022, 13:17

We are making our own firmware for projects like mega866, but I'm sure there will be some benefit to this project as well as we are creating schematics, firmware updater, etc. Ex: both this project and open-tl866 might be interested in the firmware updater

FYI the updater dev is here: https://github.com/JohnDMcMaster/libxgecu/

We have all of the primitives in place now to do firmware updates (demonstrated firmware update, encrypt / decrypt, etc). Working on packaging into nicer scripts and I might also look at some stuff like native firmware bitbang support

If you are adventuresome there is also version.py to collect some meatadata. If people can run that and send me the resulting .bin would be helpful. You'll need to "sudo pip3 install libusb1" and then run "python3 version.py my.bin"

In GitLab by @bmx1 on Jan 22, 2023, 03:28

the 3E mystery:

starting xgpro, with a t48 plugged in:

Read normal 65 bytes on endpoint 1
00 01 30 00 11 01 07 00 32 30 32 32 2D 30 39 2D   ..0.....2022-09-
32 31 30 38 3A 30 31 00 32 39 43 30 34 36 39 39   2108:01.29C04699
...

that's regular, my fw version, date, serial, blah blah

Write normal 8 bytes on endpoint 1
3E 00 00 00 00 00 00 00                           >.......

Read normal 16 bytes on endpoint 1
3E 00 30 00 11 01 07 00 FF FF 00 FF FF 00 00 00   >.0.............
^^ wtf my system_info still partially in that buffer, merged with previous cmd buffer

then


39 request status => 0x00*32
01 read id => 0x00*21, my eprom id DA 0B
04 end tran
03 begin tran
39 req status => 0x00*32
0d read code => mydata * 4096
39 req status
0d read code => next 4k data
0d read code => next 4k data
0d read code => next 4k
....
0d read code => last 4k
39 req status => 0x00*32
04 end tran```

In GitLab by @jfceklosky on Feb 2, 2023, 18:06

I also got a T48 thinking it was supported.
Here is the output from the version.py from the unit I have:

/version.py

Scanning for devices...

Found device

Bus 001 Device 055: ID a466:0a53

Read 63 bytes from USB

00000000 00 01 30 00 14 01 07 00 32 30 32 32 2D 31 31 2D |..0.....2022-11-|

00000010 30 37 31 30 3A 31 36 00 32 42 43 30 37 35 34 30 |0710:16.2BC07540|

00000020 48 47 53 39 51 35 49 51 52 45 47 44 37 55 32 4C |HGS9Q5IQREGD7U2L|

00000030 48 34 46 57 34 32 30 33 01 06 00 00 01 00 00 |H4FW4203....... |

model: t48

Dev code: 2BC07540

Serial: HGS9Q5IQREGD7U2LH4FW4203

FW version: 1.20

Manufacture date: 2022-11-0710:16

res00: 00000000 00 01 30 00 |..0. |

res56: 00000000 01 06 00 00 01 00 00 |....... |

I would be willing to help in any way as well

In GitLab by @bmx1 on Feb 5, 2023, 01:01

T48 BEGIN TRAN:

byte0: 0x03

byte1: protocol_id, same as II+

byte2: variant, same as II+

byte3: icsp mode, same as II+

byte4: vpp (8bits) same values as II+ but with 21V (0xf2) and 25V (0xf1), 9V as 0x10, 9.5V as 0x20, etc.

byte5: vdd/vcc bits 7-4 vdd, 3-0 vcc

byte6: chip_info same as II+

byte7: pin_map same as II+

byte8-9: data_memory_size same a II+ so far, NAND excluded

byte10-11: page_size same a II+ so far, NAND excluded

byte12-13: pulse delay as is

byte14-15: data_memory2_size same a II+ so far, NAND excluded

byte16-19: code_memory_size same a II+ so far, NAND excluded

byte28: spi clock (NEW?) 0x00: 4MHz, 0x01: 8MHz, 0x02: 15MHz, 0x03: 30MHz

byte52-53: imax bytes as is

delay {
        25      19
        50      32
        100     64
        200     c8
        500     1f4
        1000    3e8
}

NAND custom params:

byte 44: vcc +0:03, +0.1:04, +0.2:05, +0.3:06 -0.3:00, -0.2:01, -0.1:02
byte 48: vio +0:03, +0.1:04 ...

byte 63.0: 0 old 1 new
byte 17-18: page size, 512:xx01, 1024:xx02, ... 16384:xx20
            spare size, 16:08xx, 64:20xx, 112:38xx, 128:40xx, 224:70xx, 232:74xx, 256:80xx, 448:e0xx, 576:20x1??, 744:74x1
                         1024:00x2, 1280: 80x2 (need more investigation on how page and spare are merged in)
            page per block: ??

that's because i chose to check every value on one list, then kept the last item of the 1st one, and check every values of the 2nd one, and so on.

Anyway, if you want to contribute, don't plug anything in your T48, select a device, uncheck pin check, run a command and read you 03 usb packet. Maybe faking the t48 detect in the dll could even be more usefull for those who don't own a T48 yet ;-)

Edit: full list of byte17-18 for nand custom sizes, it's nuts, lots marked as duplicate T48_NAND_Custom_params_log_BEGIN_TRAN_list.txt

In GitLab by @bmx1 on Feb 5, 2023, 01:36

also, new command Read ONFI 0x24

In GitLab by @bmx1 on Feb 18, 2023, 22:14

found it, 0x3E is the new pin-detect command on the T48

In GitLab by @smdjeff on Jul 16, 2023, 10:43

I also picked up a T48 recently because I needed it's higher VPP support for older eeproms. Is there a fork with the latest developments? I'd be interested in seeing if I can push it further.

In GitLab by @soxrok2212 on Jul 25, 2023, 11:06

Tossing in my request for T48 support here! @DavidGriffith anything you need?

In GitLab by @anarsoul on Aug 31, 2023, 14:19

What is the current status for T48 support? Has anyone written any code?

All I found is https://github.com/JohnDMcMaster/libxgecu.git which looks like an attempt to RE firmware update, but I don't really care about custom firmware as long as stock works.

@bmx1 looks like you did some reverse engineering of the protocol, has it materialized in any code?

In GitLab by @anarsoul on Sep 1, 2023, 16:58

Since no one replied, I started working on T48 support from scratch. I'm not aiming for a complete implementation, programming some PIC MCUs and EEPROMs is sufficient for me.

The code will be living at https://gitlab.com/anarsoul/minipro/-/tree/t48-wip?ref_type=heads

Currently it's just able to enumerate T48 and I just added stubs for the callbacks to check what generic code expects.

I'm slowly working on adding support for reading/writing/erasing EEPROMs and for programming PIC MCUs.

In GitLab by @anarsoul on Sep 1, 2023, 17:03

For now I'm assuming that T48 shares IC database with TL866II+. I tried dumping InfoIC2Plus.dll using dump-infoic2plus-dll.c and it looks like it matches. At least struct size returned by GetMfcStru matches, which makes sense since the software supports TL866II+ along with T48.

In GitLab by @anarsoul on Sep 18, 2023, 22:27

I'm at the point where basic read/write/erase works for EEPROMs and AT25 SPI flashes. Tested with AM29F040B, AT28C256 and W25Q64.

So far the only major difference is how payload is written or read, it's always over endpoint 2 regardless of payload size. I've never seen windows software using endpoint 3 for anything.

More or less command set is compatible for T866II+, with minor adjustments for response size here and there.

DavidGriffith / minipro-import-test

Support for XGECU T48 aka TL866-3G ? #270

starting xgpro, with a t48 plugged in: