Chinese RT809H programmer under Linux

Xaver wrote:

but so far, I haven't found any project addressing this.

Because there is no sense do perform a re-engineering under the given circumstances. It's much easier to do the whole work self again.

The major part of the work is to collect the details of the programming strategies for the several targets. It's a job für cheap practicants (but not to cheap).

The remainder (create hard- and software for the programmer itself) is a trivial task for any expirienced embedded developer team.

If you want tu circumvent this: -use windows -use the provided software
-and die

While the PC application is well protected, the USB channel seems like an easier starting point. Using Wireshark, I captured a .pcapng file that contains the entire process, from connecting the programmer to the USB port to closing the application.

The capture includes the following steps: connecting the programmer to the USB port, launching the RT809H.exe application, selecting the memory type (NM27C512), which triggers the transfer of configuration data to the FPGA, inserting a blank memory chip (all 0xFF) into the socket, reading the memory chip's content, and finally closing the application.

The communication is extensive, consisting of 28,754 USB packets in total. I am sharing this capture for analysis. Interesting activity occurs on endpoints 1.3.0, 1.3.1, 1.3.2, and 1.3.3. The FTDI chip switches into MPSSE mode, possibly emulating JTAG.

The process becomes particularly interesting around packet 8867, which seems to be a query from the application to the programmer, with the response in packet 8869, possibly identifying an unprogrammed FPGA. Other noteworthy packets include 8949, 8951, and 8953, though their purpose remains unclear. Similarly, packets 9021, 9023, 9303, 9305, and 9307 are worth investigating further. Packets 9375 and 9377 appear to be similar to 8867, likely forming another query-response pair, while packets 9441 and 9443 also stand out.

The transfer of the FPGA configuration occurs in packets 9445, 9741, 9879, 10175, 10315, and 10605. I manually compared the beginning of the payload in packet 9445 with the start of the file ALGO_M27C512.DAT and the end of the payload in packet 10605 with the file's end, excluding padding bytes of 0xFF. The data matches, confirming the configuration transfer. Packets 10967, 10969, and 10971 are noteworthy but their purpose is unclear. Packets 11039, 11041, 11107, and 11109 likely involve identifying the loaded gateware. Packets 11175, 11177, and 11179 are also noteworthy.

At some point in the communication, the software detects memory insertion or contact. The application visually displays a bitmap of the memory socket with pins highlighted in red when there is no contact. This behavior could correspond to packets such as 12977, 12979, 12981, or 13245, which might represent a delayed response.

The commands to read the memory chip seem to be in packets 28537 and 28539, with the read data transferred in packet 28541 and completed by packets 28631 and 28633. The remainder of the capture involves closing the application.

I also tried replicating the USB communication using a Python script. The frame recordings are stored in separate .json files, and the FPGA configuration is identical to the file found in the RT809H.exe application's /LIB folder or extracted from the .pcapng file. This approach prevents the code from becoming unnecessarily large. The script is still in its early stages and currently lacks a proper reset sequence, so I need to power cycle the programmer before each launch. Receiving and writing data to the M27C512 is not yet functional, but Wireshark shows that a significant amount of 0xFF data is being transmitted, suggesting that data is being sent to the PC.

Xaver

Thank you so much for the info.