https://proghq.org/wiki/api.php?action=feedcontributions&user=Elemecca&feedformat=atom Proghq - User contributions [en] 2024-03-28T21:23:24Z User contributions MediaWiki 1.31.1 https://proghq.org/wiki/index.php?title=TL866_II_PLUS&diff=673 TL866 II PLUS 2020-02-03T08:35:16Z <p>Elemecca: /* Pinouts */ add IO expander pin mappings</p> <hr /> <div>[[Category:TL866]]<br /> [[Category:Hardware]]<br /> [[Category:Programmer]]<br /> <br /> The TL866 II PLUS is '''NOT''' compatible with the [[TL866|TL866 A / TL866 CS]] models. The microcontroller has been changed from a PIC18 to a PIC24F and there are other significant schematic changes. The plastic enclosure for the TL866 II PLUS is identical to the TL866A / TL866CS.<br /> <br /> = Hardware =<br /> <br /> The TL866II PLUS is driven by a Microchip [https://www.microchip.com/wwwproducts/en/PIC24FJ256GB110 PIC24FJ256GB110] microcontroller which connects directly to the USB.<br /> <br /> [[:Media:TL866II_Schematic.pdf|Reverse-Engineered Schematic]]<br /> <br /> == Pinouts ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;float: right; margin-left: 10px; text-align: center;&quot;<br /> |+ ZIF40 Pinout<br /> ! V&lt;sub&gt;PP&lt;/sub&gt; !! V&lt;sub&gt;DD&lt;/sub&gt; !! GND !! IO !! !! !! IO !! GND !! V&lt;sub&gt;DD&lt;/sub&gt; !! V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | RF1 || 0.00 || 0.0 || RD10<br /> ! 01 !! 40<br /> | RD0 || 3.7 || 1.15 || 0.15<br /> |-<br /> | RF0 || 0.01 || 0.1 || RD9<br /> ! 02 !! 39<br /> | RD11 || 3.6 || 1.14 || 0.14<br /> |-<br /> | RD7 || 0.02 || 0.2 || RD8<br /> ! 03 !! 38<br /> | RD1 || 3.5 || 1.13 || 0.13<br /> |-<br /> | RD6 || 0.03 || 0.3 || RF8<br /> ! 04 !! 37<br /> | RD2 || 3.4 || 1.12 || 0.12<br /> |-<br /> | RD13 || 0.04 || 0.4 || RF2<br /> ! 05 !! 36<br /> | RD3 || 3.3 || 1.11 || 0.11<br /> |-<br /> | 0.00 || 0.05 || 0.5 || RF5<br /> ! 06 !! 35<br /> | RD4 || 3.2 || 1.10 || 0.10<br /> |-<br /> | 0.01 || 0.06 || 0.6 || RF4<br /> ! 07 !! 34<br /> | RD5 || 3.1 || 1.09 || 0.09<br /> |-<br /> | 0.02 || 0.07 || 0.7 || RD15<br /> ! 08 !! 33<br /> | RG14 || 3.0 || 1.08 || 0.08<br /> |-<br /> | 0.03 || 0.08 || 1.0 || RD14<br /> ! 09 !! 32<br /> | RG12 || 2.7 || 1.07 || 0.07<br /> |-<br /> | 0.04 || 0.09 || 1.1 || RA1<br /> ! 10 !! 31<br /> | RG13 || 2.6 || 1.06 || 0.06<br /> |-<br /> | || 0.10 || 1.2 || RA15<br /> ! 11 !! 30<br /> | RG15 || 2.5 || 1.05 || 0.05<br /> |-<br /> | || 0.11 || 1.3 || RA14<br /> ! 12 !! 29<br /> | RE7 || 2.4 || 1.04 ||<br /> |-<br /> | || 0.12 || 1.4 || RE0<br /> ! 13 !! 28<br /> | RE6 || 2.3 || 1.03 ||<br /> |-<br /> | || 0.13 || 1.5 || RE1<br /> ! 14 !! 27<br /> | RE5 || 2.2 || 1.02 ||<br /> |-<br /> | || 0.14 || 1.6 || RE2<br /> ! 15 !! 26<br /> | RE4 || 2.1 || 1.01 ||<br /> |-<br /> | || 0.15 || 1.7 || RE9<br /> ! 16 !! 25<br /> | RE3 || 2.0 || 1.00 ||<br /> |-<br /> | || || || RE8<br /> ! 17 !! 24<br /> | RD12 || || ||<br /> |-<br /> | || || || RF12<br /> ! 18 !! 23<br /> | RA5 || || ||<br /> |-<br /> | || || || RF13<br /> ! 19 !! 22<br /> | RA4 || || ||<br /> |-<br /> | || || RB2 || RA2<br /> ! 20 !! 21<br /> | RA3 || RB3 || ||<br /> |}<br /> <br /> The primary interface to the target device is a 40 pin ZIF (zero insertion force) socket. Digital IO at LVCMOS3.3 levels is supported direct to the MCU on every pin. Inputs above +3.3V will be clamped. The V&lt;sub&gt;DD&lt;/sub&gt; bus can be switched to pins 1-16 and 25-40. The V&lt;sub&gt;PP&lt;/sub&gt; bus can be switched to pins 1-10 and 30-40. The ground bus can be switched to pins 1-16, 20, 21, and 25-40.<br /> <br /> &lt;div style=&quot;clear: both;&quot;&gt;&lt;/div&gt;<br /> <br /> == Original research ==<br /> <br /> * [[TL866_II_PLUS/Bootloader]]<br /> <br /> = Photos =<br /> == TL866 II PLUS photos ==<br /> Photos of a TL866 II PLUS bought April 2018 from eBay seller goldenchipset.&lt;br/&gt;<br /> Red and yellow LEDs were desoldered from mainboard to allow separation of the two PCBs.&lt;br/&gt;<br /> [[File:TL866 II PLUS socketboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS socketboard bottom scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard bottom scan 1200dpi.jpg|160px]]</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS&diff=672 TL866 II PLUS 2020-02-03T08:16:30Z <p>Elemecca: /* Pinouts */ add actual MCU pinouts to table</p> <hr /> <div>[[Category:TL866]]<br /> [[Category:Hardware]]<br /> [[Category:Programmer]]<br /> <br /> The TL866 II PLUS is '''NOT''' compatible with the [[TL866|TL866 A / TL866 CS]] models. The microcontroller has been changed from a PIC18 to a PIC24F and there are other significant schematic changes. The plastic enclosure for the TL866 II PLUS is identical to the TL866A / TL866CS.<br /> <br /> = Hardware =<br /> <br /> The TL866II PLUS is driven by a Microchip [https://www.microchip.com/wwwproducts/en/PIC24FJ256GB110 PIC24FJ256GB110] microcontroller which connects directly to the USB.<br /> <br /> [[:Media:TL866II_Schematic.pdf|Reverse-Engineered Schematic]]<br /> <br /> == Pinouts ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;float: right; margin-left: 10px; text-align: center;&quot;<br /> |+ ZIF40 Pinout<br /> ! V&lt;sub&gt;PP&lt;/sub&gt; !! V&lt;sub&gt;DD&lt;/sub&gt; !! GND !! IO !! !! !! IO !! GND !! V&lt;sub&gt;DD&lt;/sub&gt; !! V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | RF1 || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RD10<br /> ! 01 !! 40<br /> | RD0 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | RF0 || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RD9<br /> ! 02 !! 39<br /> | RD11 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | RD7 || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RD8<br /> ! 03 !! 38<br /> | RD1 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | RD6 || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RF8<br /> ! 04 !! 37<br /> | RD2 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | RD13 || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RF2<br /> ! 05 !! 36<br /> | RD3 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RF5<br /> ! 06 !! 35<br /> | RD4 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RF4<br /> ! 07 !! 34<br /> | RD5 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RD15<br /> ! 08 !! 33<br /> | RG14 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RD14<br /> ! 09 !! 32<br /> | RG12 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RA1<br /> ! 10 !! 31<br /> | RG13 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RA15<br /> ! 11 !! 30<br /> | RG15 || GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RA14<br /> ! 12 !! 29<br /> | RE7 || GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RE0<br /> ! 13 !! 28<br /> | RE6 || GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RE1<br /> ! 14 !! 27<br /> | RE5 || GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RE2<br /> ! 15 !! 26<br /> | RE4 || GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND || RE9<br /> ! 16 !! 25<br /> | RE3 || GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || || || RE8<br /> ! 17 !! 24<br /> | RD12 || || ||<br /> |-<br /> | || || || RF12<br /> ! 18 !! 23<br /> | RA5 || || || ||<br /> |-<br /> | || || || RF13<br /> ! 19 !! 22<br /> | RA4 || || ||<br /> |-<br /> | || || RB2 || RA2<br /> ! 20 !! 21<br /> | RA3 || RB3 || ||<br /> |}<br /> <br /> The primary interface to the target device is a 40 pin ZIF (zero insertion force) socket. Digital IO at LVCMOS3.3 levels is supported direct to the MCU on every pin. Inputs above +3.3V will be clamped. The V&lt;sub&gt;DD&lt;/sub&gt; bus can be switched to pins 1-16 and 25-40. The V&lt;sub&gt;PP&lt;/sub&gt; bus can be switched to pins 1-10 and 30-40. The ground bus can be switched to pins 1-16, 20, 21, and 25-40.<br /> <br /> &lt;div style=&quot;clear: both;&quot;&gt;&lt;/div&gt;<br /> <br /> == Original research ==<br /> <br /> * [[TL866_II_PLUS/Bootloader]]<br /> <br /> = Photos =<br /> == TL866 II PLUS photos ==<br /> Photos of a TL866 II PLUS bought April 2018 from eBay seller goldenchipset.&lt;br/&gt;<br /> Red and yellow LEDs were desoldered from mainboard to allow separation of the two PCBs.&lt;br/&gt;<br /> [[File:TL866 II PLUS socketboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS socketboard bottom scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard bottom scan 1200dpi.jpg|160px]]</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS&diff=671 TL866 II PLUS 2020-02-02T03:50:54Z <p>Elemecca: add prose pinout description</p> <hr /> <div>[[Category:TL866]]<br /> [[Category:Hardware]]<br /> [[Category:Programmer]]<br /> <br /> The TL866 II PLUS is '''NOT''' compatible with the [[TL866|TL866 A / TL866 CS]] models. The microcontroller has been changed from a PIC18 to a PIC24F and there are other significant schematic changes. The plastic enclosure for the TL866 II PLUS is identical to the TL866A / TL866CS.<br /> <br /> = Hardware =<br /> <br /> The TL866II PLUS is driven by a Microchip [https://www.microchip.com/wwwproducts/en/PIC24FJ256GB110 PIC24FJ256GB110] microcontroller which connects directly to the USB.<br /> <br /> [[:Media:TL866II_Schematic.pdf|Reverse-Engineered Schematic]]<br /> <br /> == Pinouts ==<br /> <br /> {| class=&quot;wikitable&quot; style=&quot;float: right; margin-left: 10px;&quot;<br /> |+ ZIF40 Pinout<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 01 !! 40<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 02 !! 39<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 03 !! 38<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 04 !! 37<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 05 !! 36<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 06 !! 35<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 07 !! 34<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 08 !! 33<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 09 !! 32<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 10 !! 31<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 11 !! 30<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 12 !! 29<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 13 !! 28<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 14 !! 27<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 15 !! 26<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 16 !! 25<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || ||<br /> ! 17 !! 24<br /> | || ||<br /> |-<br /> | || ||<br /> ! 18 !! 23<br /> | || ||<br /> |-<br /> | || ||<br /> ! 19 !! 22<br /> | || ||<br /> |-<br /> | || || GND<br /> ! 20 !! 21<br /> | GND || ||<br /> |}<br /> <br /> The primary interface to the target device is a 40 pin ZIF (zero insertion force) socket. Digital IO at LVCMOS3.3 levels is supported direct to the MCU on every pin. Inputs above +3.3V will be clamped. The V&lt;sub&gt;DD&lt;/sub&gt; bus can be switched to pins 1-16 and 25-40. The V&lt;sub&gt;PP&lt;/sub&gt; bus can be switched to pins 1-10 and 30-40. The ground bus can be switched to pins 1-16, 20, 21, and 25-40.<br /> <br /> &lt;div style=&quot;clear: both;&quot;&gt;&lt;/div&gt;<br /> <br /> == Original research ==<br /> <br /> * [[TL866_II_PLUS/Bootloader]]<br /> <br /> = Photos =<br /> == TL866 II PLUS photos ==<br /> Photos of a TL866 II PLUS bought April 2018 from eBay seller goldenchipset.&lt;br/&gt;<br /> Red and yellow LEDs were desoldered from mainboard to allow separation of the two PCBs.&lt;br/&gt;<br /> [[File:TL866 II PLUS socketboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS socketboard bottom scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard bottom scan 1200dpi.jpg|160px]]</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS&diff=670 TL866 II PLUS 2020-02-02T03:37:39Z <p>Elemecca: add pinout table</p> <hr /> <div>[[Category:TL866]]<br /> [[Category:Hardware]]<br /> [[Category:Programmer]]<br /> <br /> The TL866 II PLUS is '''NOT''' compatible with the [[TL866|TL866 A / TL866 CS]] models. The microcontroller has been changed from a PIC18 to a PIC24F and there are other significant schematic changes. The plastic enclosure for the TL866 II PLUS is identical to the TL866A / TL866CS.<br /> <br /> = Hardware =<br /> <br /> The TL866II PLUS is driven by a Microchip [https://www.microchip.com/wwwproducts/en/PIC24FJ256GB110 PIC24FJ256GB110] microcontroller which connects directly to the USB.<br /> <br /> [[:Media:TL866II_Schematic.pdf|Reverse-Engineered Schematic]]<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+ ZIF40 Pinout<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 01 !! 40<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 02 !! 39<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 03 !! 38<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 04 !! 37<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 05 !! 36<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 06 !! 35<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 07 !! 34<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 08 !! 33<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 09 !! 32<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | V&lt;sub&gt;PP&lt;/sub&gt; || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 10 !! 31<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 11 !! 30<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; || V&lt;sub&gt;PP&lt;/sub&gt;<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 12 !! 29<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 13 !! 28<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 14 !! 27<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 15 !! 26<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || V&lt;sub&gt;DD&lt;/sub&gt; || GND<br /> ! 16 !! 25<br /> | GND || V&lt;sub&gt;DD&lt;/sub&gt; ||<br /> |-<br /> | || ||<br /> ! 17 !! 24<br /> | || ||<br /> |-<br /> | || ||<br /> ! 18 !! 23<br /> | || ||<br /> |-<br /> | || ||<br /> ! 19 !! 22<br /> | || ||<br /> |-<br /> | || || GND<br /> ! 20 !! 21<br /> | GND || ||<br /> |}<br /> <br /> <br /> == Original research ==<br /> <br /> * [[TL866_II_PLUS/Bootloader]]<br /> <br /> = Photos =<br /> == TL866 II PLUS photos ==<br /> Photos of a TL866 II PLUS bought April 2018 from eBay seller goldenchipset.&lt;br/&gt;<br /> Red and yellow LEDs were desoldered from mainboard to allow separation of the two PCBs.&lt;br/&gt;<br /> [[File:TL866 II PLUS socketboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS socketboard bottom scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard bottom scan 1200dpi.jpg|160px]]</div> Elemecca https://proghq.org/wiki/index.php?title=File:TL866II_Schematic.pdf&diff=669 File:TL866II Schematic.pdf 2020-02-02T03:00:27Z <p>Elemecca: Reverse-engineered schematic of the TL866 II PLUS universal programmer.</p> <hr /> <div>== Summary ==<br /> Reverse-engineered schematic of the TL866 II PLUS universal programmer.</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=516 TL866 II PLUS/Bootloader 2018-08-28T22:13:34Z <p>Elemecca: /* Write Block */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == USB Protocol ==<br /> <br /> The bootloader and the stock firmware communicate with the host via a simple custom USB protocol. It uses three bidirectional bulk endpoints on Interface 0. Endpoint 1 Out is used to send commands and Endpoint 1 In is used to read status responses. For commands that transfer large amounts of data the payload is split evenly between Endpoint 2 and Endpoint 3, presumably to increase transfer speed.<br /> <br /> When sending a command, the first 8 bytes are always the command header and are written to Endpoint 1. The behavior for the payload &amp;mdash; the data, if any, to be sent after the command header &amp;mdash; depends on its size. If the payload plus the 8-byte header fit in a single 64-byte packet, the payload is sent in the same packet as the header on Endpoint 1. If the payload is exactly 64 bytes, it's sent in a single packet on Endpoint 2. Otherwise, the payload is split between Endpoint 2 and Endpoint 3. If the total size of the payload is less than 128 bytes, each endpoint gets exactly half, with Endpoint 2 first. Otherwise, the data is split into 64-byte blocks. The first half of the blocks are sent to Endpoint 2 and the other half to Endpoint 3. If there are an odd number of whole blocks Endpoint 3 gets the extra one. If the final block is partial, it is always sent to Endpoint 3.<br /> <br /> === Reset ===<br /> <br /> The reset command asks the device to reboot. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset. If this command isn't sent first, the reset command appears to succeed but the device reboots to the stock firmware, not the bootloader.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || &lt;tt&gt;01&lt;/tt&gt; || no longer used?<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}<br /> <br /> In versions of the TL866 A/CS firmware 03.2.82 and earlier, the &lt;tt&gt;bStatus&lt;/tt&gt; field was used to indicate whether the device was currently running the stock firmware (value &lt;tt&gt;01&lt;/tt&gt;) or the bootloader (value &lt;tt&gt;02&lt;/tt&gt;). A/CS firmware 03.2.85 and the TL866II-Plus appear to always return &lt;tt&gt;01&lt;/tt&gt;. The only difference in the report output between the stock firmware and the bootloader on the TL866II-Plus is the version number, for which the bootloader always returns 1.0.<br /> <br /> === Erase ===<br /> <br /> The erase command erases the firmware area of the internal flash (i.e. everything but the bootloader).<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with an 8-byte acknowledgement.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || ''unknown'' || 7 || ||<br /> |}<br /> <br /> === Write Block ===<br /> <br /> The write block command receives an encrypted data block, decrypts it, and writes the cleartext to the flash. As with all commands, it has an 8-byte header. The encrypted data is sent after the command header.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3B&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || &lt;tt&gt;bKeyOffset&lt;/tt&gt; || 1 ||<br /> | An offset into the XOR table used for decryption by the bootloader.<br /> |-<br /> | 2 || &lt;tt&gt;wBlockSize&lt;/tt&gt; || 2 ||<br /> | The size in bytes of the encrypted data to be sent.<br /> |-<br /> | 4 || &lt;tt&gt;dAddress&lt;/tt&gt; || 4 ||<br /> | The program memory address of the start of the block.<br /> |}<br /> <br /> The device does not send a response to the write block command. Instead, another command is sent to retrieve the status.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;39&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with a 32-byte packet. The unknown parts of the structure have only ever been observed to be all zeroes.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || ''unknown'' || 1 || ||<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 ||<br /> | &lt;tt&gt;00&lt;/tt&gt; on success; any other value indicates error<br /> |-<br /> | 2 || ''unknown'' || 30 || ||<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=514 TL866 II PLUS/Bootloader 2018-08-27T00:10:20Z <p>Elemecca: /* Write Block */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == USB Protocol ==<br /> <br /> The bootloader and the stock firmware communicate with the host via a simple custom USB protocol. It uses three bidirectional bulk endpoints on Interface 0. Endpoint 1 Out is used to send commands and Endpoint 1 In is used to read status responses. For commands that transfer large amounts of data the payload is split evenly between Endpoint 2 and Endpoint 3, presumably to increase transfer speed.<br /> <br /> When sending a command, the first 8 bytes are always the command header and are written to Endpoint 1. The behavior for the payload &amp;mdash; the data, if any, to be sent after the command header &amp;mdash; depends on its size. If the payload plus the 8-byte header fit in a single 64-byte packet, the payload is sent in the same packet as the header on Endpoint 1. If the payload is exactly 64 bytes, it's sent in a single packet on Endpoint 2. Otherwise, the payload is split between Endpoint 2 and Endpoint 3. If the total size of the payload is less than 128 bytes, each endpoint gets exactly half, with Endpoint 2 first. Otherwise, the data is split into 64-byte blocks. The first half of the blocks are sent to Endpoint 2 and the other half to Endpoint 3. If there are an odd number of whole blocks Endpoint 3 gets the extra one. If the final block is partial, it is always sent to Endpoint 3.<br /> <br /> === Reset ===<br /> <br /> The reset command asks the device to reboot. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset. If this command isn't sent first, the reset command appears to succeed but the device reboots to the stock firmware, not the bootloader.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || &lt;tt&gt;01&lt;/tt&gt; || no longer used?<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}<br /> <br /> In versions of the TL866 A/CS firmware 03.2.82 and earlier, the &lt;tt&gt;bStatus&lt;/tt&gt; field was used to indicate whether the device was currently running the stock firmware (value &lt;tt&gt;01&lt;/tt&gt;) or the bootloader (value &lt;tt&gt;02&lt;/tt&gt;). A/CS firmware 03.2.85 and the TL866II-Plus appear to always return &lt;tt&gt;01&lt;/tt&gt;. The only difference in the report output between the stock firmware and the bootloader on the TL866II-Plus is the version number, for which the bootloader always returns 1.0.<br /> <br /> === Erase ===<br /> <br /> The erase command erases the firmware area of the internal flash (i.e. everything but the bootloader).<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with an 8-byte acknowledgement.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || ''unknown'' || 7 || ||<br /> |}<br /> <br /> === Write Block ===<br /> <br /> The write block command receives an encrypted data block, decrypts it, and writes the cleartext to the flash. As with all commands, it has an 8-byte header. The encrypted data is sent after the command header.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3B&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || &lt;tt&gt;bUnknown1&lt;/tt&gt; || 1 ||<br /> | Copied from the block in the update file. Purpose unknown.<br /> |-<br /> | 2 || &lt;tt&gt;wBlockSize&lt;/tt&gt; || 2 ||<br /> | The size in bytes of the encrypted data to be sent.<br /> |-<br /> | 4 || &lt;tt&gt;dUnknown2&lt;/tt&gt; || 4 ||<br /> | Some kind of checksum? Computed from the block in the update file and a key from the file header.<br /> |}<br /> <br /> The device does not send a response to the write block command. Instead, another command is sent to retrieve the status.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;39&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with a 32-byte packet. The unknown parts of the structure have only ever been observed to be all zeroes.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || ''unknown'' || 1 || ||<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 ||<br /> | &lt;tt&gt;00&lt;/tt&gt; on success; any other value indicates error<br /> |-<br /> | 2 || ''unknown'' || 30 || ||<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=513 TL866 II PLUS/Bootloader 2018-08-27T00:09:10Z <p>Elemecca: /* USB Protocol */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == USB Protocol ==<br /> <br /> The bootloader and the stock firmware communicate with the host via a simple custom USB protocol. It uses three bidirectional bulk endpoints on Interface 0. Endpoint 1 Out is used to send commands and Endpoint 1 In is used to read status responses. For commands that transfer large amounts of data the payload is split evenly between Endpoint 2 and Endpoint 3, presumably to increase transfer speed.<br /> <br /> When sending a command, the first 8 bytes are always the command header and are written to Endpoint 1. The behavior for the payload &amp;mdash; the data, if any, to be sent after the command header &amp;mdash; depends on its size. If the payload plus the 8-byte header fit in a single 64-byte packet, the payload is sent in the same packet as the header on Endpoint 1. If the payload is exactly 64 bytes, it's sent in a single packet on Endpoint 2. Otherwise, the payload is split between Endpoint 2 and Endpoint 3. If the total size of the payload is less than 128 bytes, each endpoint gets exactly half, with Endpoint 2 first. Otherwise, the data is split into 64-byte blocks. The first half of the blocks are sent to Endpoint 2 and the other half to Endpoint 3. If there are an odd number of whole blocks Endpoint 3 gets the extra one. If the final block is partial, it is always sent to Endpoint 3.<br /> <br /> === Reset ===<br /> <br /> The reset command asks the device to reboot. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset. If this command isn't sent first, the reset command appears to succeed but the device reboots to the stock firmware, not the bootloader.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || &lt;tt&gt;01&lt;/tt&gt; || no longer used?<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}<br /> <br /> In versions of the TL866 A/CS firmware 03.2.82 and earlier, the &lt;tt&gt;bStatus&lt;/tt&gt; field was used to indicate whether the device was currently running the stock firmware (value &lt;tt&gt;01&lt;/tt&gt;) or the bootloader (value &lt;tt&gt;02&lt;/tt&gt;). A/CS firmware 03.2.85 and the TL866II-Plus appear to always return &lt;tt&gt;01&lt;/tt&gt;. The only difference in the report output between the stock firmware and the bootloader on the TL866II-Plus is the version number, for which the bootloader always returns 1.0.<br /> <br /> === Erase ===<br /> <br /> The erase command erases the firmware area of the internal flash (i.e. everything but the bootloader).<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with an 8-byte acknowledgement.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || ''unknown'' || 7 || ||<br /> |}<br /> <br /> === Write Block ===<br /> <br /> The write block command receives an encrypted data block, decrypts it, and writes the cleartext to the flash. As with all commands, it has an 8-byte header. The encrypted data is sent after the command header.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3B&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || &lt;tt&gt;bUnknown1&lt;/tt&gt; || 1 ||<br /> | Copied from the block in the update file. Purpose unknown.<br /> |-<br /> | 2 || &lt;tt&gt;wBlockSize&lt;/tt&gt; || 2 ||<br /> | The size in bytes of the encrypted data to be sent.<br /> |-<br /> | 4 || &lt;tt&gt;bUnknown2&lt;/tt&gt; || 4 ||<br /> | Some kind of checksum? Computed from the block in the update file and a key from the file header.<br /> |}<br /> <br /> The device does not send a response to the write block command. Instead, another command is sent to retrieve the status.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;39&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with a 32-byte packet. The unknown parts of the structure have only ever been observed to be all zeroes.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || ''unknown'' || 1 || ||<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 ||<br /> | &lt;tt&gt;00&lt;/tt&gt; on success; any other value indicates error<br /> |-<br /> | 2 || ''unknown'' || 30 || ||<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=512 TL866 II PLUS/Bootloader 2018-08-27T00:05:40Z <p>Elemecca: </p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == USB Protocol ==<br /> <br /> The bootloader and the stock firmware communicate with the host via simple custom USB protocol. It uses three bidirectional bulk endpoints on Interface 0. Endpoint 1 Out is used to send commands and Endpoint 1 In is used to read status responses. For commands that transfer large amounts of data the payload is split evenly between Endpoint 2 and Endpoint 3, presumably to increase transfer speed.<br /> <br /> When sending a command, the first 8 bytes are always the command header and are written to Endpoint 1. The behavior for the payload &amp;mdash; the data, if any, to be sent after the command header &amp;mdash; depends on its size. If the payload plus the 8-byte header fit in a single 64-byte packet, the payload is sent in the same packet as the header on Endpoint 1. If the payload is exactly 64 bytes, it's sent in a single packet on Endpoint 2. Otherwise, the payload is split between Endpoint 2 and Endpoint 3. If the total size of the payload is less than 128 bytes, each endpoint gets exactly half, with Endpoint 2 first. Otherwise, the data is split into 64-byte blocks. The first half of the blocks are sent to Endpoint 2 and the other half to Endpoint 3. If there are an odd number of whole blocks Endpoint 3 gets the extra one. If the final block is partial, it is always sent to Endpoint 3.<br /> <br /> === Reset ===<br /> <br /> The reset command asks the device to reboot. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset. If this command isn't sent first, the reset command appears to succeed but the device reboots to the stock firmware, not the bootloader.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || &lt;tt&gt;01&lt;/tt&gt; || no longer used?<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}<br /> <br /> In versions of the TL866 A/CS firmware 03.2.82 and earlier, the &lt;tt&gt;bStatus&lt;/tt&gt; field was used to indicate whether the device was currently running the stock firmware (value &lt;tt&gt;01&lt;/tt&gt;) or the bootloader (value &lt;tt&gt;02&lt;/tt&gt;). A/CS firmware 03.2.85 and the TL866II-Plus appear to always return &lt;tt&gt;01&lt;/tt&gt;. The only difference in the report output between the stock firmware and the bootloader on the TL866II-Plus is the version number, for which the bootloader always returns 1.0.<br /> <br /> === Erase ===<br /> <br /> The erase command erases the firmware area of the internal flash (i.e. everything but the bootloader).<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with an 8-byte acknowledgement.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || ''unknown'' || 7 || ||<br /> |}<br /> <br /> === Write Block ===<br /> <br /> The write block command receives an encrypted data block, decrypts it, and writes the cleartext to the flash. As with all commands, it has an 8-byte header. The encrypted data is sent after the command header.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3B&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || &lt;tt&gt;bUnknown1&lt;/tt&gt; || 1 ||<br /> | Copied from the block in the update file. Purpose unknown.<br /> |-<br /> | 2 || &lt;tt&gt;wBlockSize&lt;/tt&gt; || 2 ||<br /> | The size in bytes of the encrypted data to be sent.<br /> |-<br /> | 4 || &lt;tt&gt;bUnknown2&lt;/tt&gt; || 4 ||<br /> | Some kind of checksum? Computed from the block in the update file and a key from the file header.<br /> |}<br /> <br /> The device does not send a response to the write block command. Instead, another command is sent to retrieve the status.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;39&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with a 32-byte packet. The unknown parts of the structure have only ever been observed to be all zeroes.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || ''unknown'' || 1 || ||<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 ||<br /> | &lt;tt&gt;00&lt;/tt&gt; on success; any other value indicates error<br /> |-<br /> | 2 || ''unknown'' || 30 || ||<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=511 TL866 II PLUS/Bootloader 2018-08-26T23:45:26Z <p>Elemecca: /* Reset */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset. If this command isn't sent first, the reset command appears to succeed but the device reboots to the stock firmware, not the bootloader.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || &lt;tt&gt;01&lt;/tt&gt; || no longer used?<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}<br /> <br /> In versions of the TL866 A/CS firmware 03.2.82 and earlier, the &lt;tt&gt;bStatus&lt;/tt&gt; field was used to indicate whether the device was currently running the stock firmware (value &lt;tt&gt;01&lt;/tt&gt;) or the bootloader (value &lt;tt&gt;02&lt;/tt&gt;). A/CS firmware 03.2.85 and the TL866II-Plus appear to always return &lt;tt&gt;01&lt;/tt&gt;. The only difference in the report output between the stock firmware and the bootloader on the TL866II-Plus is the version number, for which the bootloader always returns 1.0.<br /> <br /> === Erase ===<br /> <br /> The erase command erases the firmware area of the internal flash (i.e. everything but the bootloader).<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with an 8-byte acknowledgement.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || ''unknown'' || 7 || ||<br /> |}<br /> <br /> === Write Block ===<br /> <br /> The write block command receives an encrypted data block, decrypts it, and writes the cleartext to the flash. As with all commands, it has an 8-byte header. The encrypted data is sent after the command header.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3B&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || &lt;tt&gt;bUnknown1&lt;/tt&gt; || 1 ||<br /> | Copied from the block in the update file. Purpose unknown.<br /> |-<br /> | 2 || &lt;tt&gt;wBlockSize&lt;/tt&gt; || 2 ||<br /> | The size in bytes of the encrypted data to be sent.<br /> |-<br /> | 4 || &lt;tt&gt;bUnknown2&lt;/tt&gt; || 4 ||<br /> | Some kind of checksum? Computed from the block in the update file and a key from the file header.<br /> |}<br /> <br /> The device does not send a response to the write block command. Instead, another command is sent to retrieve the status.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;39&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with a 32-byte packet. The unknown parts of the structure have only ever been observed to be all zeroes.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || ''unknown'' || 1 || ||<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 ||<br /> | &lt;tt&gt;00&lt;/tt&gt; on success; any other value indicates error<br /> |-<br /> | 2 || ''unknown'' || 30 || ||<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=510 TL866 II PLUS/Bootloader 2018-08-26T23:42:53Z <p>Elemecca: /* Commands */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || &lt;tt&gt;01&lt;/tt&gt; || no longer used?<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}<br /> <br /> In versions of the TL866 A/CS firmware 03.2.82 and earlier, the &lt;tt&gt;bStatus&lt;/tt&gt; field was used to indicate whether the device was currently running the stock firmware (value &lt;tt&gt;01&lt;/tt&gt;) or the bootloader (value &lt;tt&gt;02&lt;/tt&gt;). A/CS firmware 03.2.85 and the TL866II-Plus appear to always return &lt;tt&gt;01&lt;/tt&gt;. The only difference in the report output between the stock firmware and the bootloader on the TL866II-Plus is the version number, for which the bootloader always returns 1.0.<br /> <br /> === Erase ===<br /> <br /> The erase command erases the firmware area of the internal flash (i.e. everything but the bootloader).<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with an 8-byte acknowledgement.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || ''unknown'' || 7 || ||<br /> |}<br /> <br /> === Write Block ===<br /> <br /> The write block command receives an encrypted data block, decrypts it, and writes the cleartext to the flash. As with all commands, it has an 8-byte header. The encrypted data is sent after the command header.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3B&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || &lt;tt&gt;bUnknown1&lt;/tt&gt; || 1 ||<br /> | Copied from the block in the update file. Purpose unknown.<br /> |-<br /> | 2 || &lt;tt&gt;wBlockSize&lt;/tt&gt; || 2 ||<br /> | The size in bytes of the encrypted data to be sent.<br /> |-<br /> | 4 || &lt;tt&gt;bUnknown2&lt;/tt&gt; || 4 ||<br /> | Some kind of checksum? Computed from the block in the update file and a key from the file header.<br /> |}<br /> <br /> The device does not send a response to the write block command. Instead, another command is sent to retrieve the status.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;39&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with a 32-byte packet. The unknown parts of the structure have only ever been observed to be all zeroes.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || ''unknown'' || 1 || ||<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 ||<br /> | &lt;tt&gt;00&lt;/tt&gt; on success; any other value indicates error<br /> |-<br /> | 2 || ''unknown'' || 30 || ||<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=509 TL866 II PLUS/Bootloader 2018-08-26T23:42:01Z <p>Elemecca: /* Report */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || &lt;tt&gt;01&lt;/tt&gt; || no longer used?<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}<br /> <br /> In versions of the TL866 A/CS firmware 03.2.82 and earlier, the &lt;tt&gt;bStatus&lt;/tt&gt; field was used to indicate whether the device was currently running the stock firmware (value &lt;tt&gt;01&lt;/tt&gt;) or the bootloader (value &lt;tt&gt;02&lt;/tt&gt;). A/CS firmware 03.2.85 and the TL866II-Plus appear to always return &lt;tt&gt;01&lt;/tt&gt;. The only difference in the report output between the stock firmware and the bootloader on the TL866II-Plus is the version number, for which the bootloader always returns 1.0.<br /> <br /> === Erase ===<br /> <br /> The erase command erases the firmware area of the internal flash (i.e. everything but the bootloader).<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with an 8-byte acknowledgement.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || ''unknown'' || 7 || ||<br /> |}<br /> <br /> <br /> === Write Block ===<br /> <br /> The write block command receives an encrypted data block, decrypts it, and writes the cleartext to the flash. As with all commands, it has an 8-byte header. The encrypted data is sent after the command header.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3B&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || &lt;tt&gt;bUnknown1&lt;/tt&gt; || 1 ||<br /> | Copied from the block in the update file. Purpose unknown.<br /> |-<br /> | 2 || &lt;tt&gt;wBlockSize&lt;/tt&gt; || 2 ||<br /> | The size in bytes of the encrypted data to be sent.<br /> |-<br /> | 4 || &lt;tt&gt;bUnknown2&lt;/tt&gt; || 4 ||<br /> | Some kind of checksum? Computed from the block in the update file and a key from the file header.<br /> |}<br /> <br /> The device does not send a response to the write block command. Instead, another command is sent to retrieve the status.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;39&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with a 32-byte packet. The unknown parts of the structure have only ever been observed to be all zeroes.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || ''unknown'' || 1 || ||<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 ||<br /> | &lt;tt&gt;00&lt;/tt&gt; on success; any other value indicates error<br /> |-<br /> | 2 || ''unknown'' || 30 || ||<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=508 TL866 II PLUS/Bootloader 2018-08-26T23:33:57Z <p>Elemecca: /* Commands */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || <br /> | which firmware is running: &lt;tt&gt;01&lt;/tt&gt; is the stock firmware, &lt;tt&gt;02&lt;/tt&gt; is the bootloader<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}<br /> <br /> <br /> === Erase ===<br /> <br /> The erase command erases the firmware area of the internal flash (i.e. everything but the bootloader).<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with an 8-byte acknowledgement.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3C&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || ''unknown'' || 7 || ||<br /> |}<br /> <br /> <br /> === Write Block ===<br /> <br /> The write block command receives an encrypted data block, decrypts it, and writes the cleartext to the flash. As with all commands, it has an 8-byte header. The encrypted data is sent after the command header.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;3B&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || &lt;tt&gt;bUnknown1&lt;/tt&gt; || 1 ||<br /> | Copied from the block in the update file. Purpose unknown.<br /> |-<br /> | 2 || &lt;tt&gt;wBlockSize&lt;/tt&gt; || 2 ||<br /> | The size in bytes of the encrypted data to be sent.<br /> |-<br /> | 4 || &lt;tt&gt;bUnknown2&lt;/tt&gt; || 4 ||<br /> | Some kind of checksum? Computed from the block in the update file and a key from the file header.<br /> |}<br /> <br /> The device does not send a response to the write block command. Instead, another command is sent to retrieve the status.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;39&lt;/tt&gt; || the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device responds with a 32-byte packet. The unknown parts of the structure have only ever been observed to be all zeroes.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || ''unknown'' || 1 || ||<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 ||<br /> | &lt;tt&gt;00&lt;/tt&gt; on success; any other value indicates error<br /> |-<br /> | 2 || ''unknown'' || 30 || ||<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=507 TL866 II PLUS/Bootloader 2018-08-26T21:16:05Z <p>Elemecca: /* Report */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 41-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || <br /> | which firmware is running: &lt;tt&gt;01&lt;/tt&gt; is the stock firmware, &lt;tt&gt;02&lt;/tt&gt; is the bootloader<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=506 TL866 II PLUS/Bootloader 2018-08-26T20:07:07Z <p>Elemecca: /* Report */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 64-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || <br /> | which firmware is running: &lt;tt&gt;01&lt;/tt&gt; is the stock firmware, &lt;tt&gt;02&lt;/tt&gt; is the bootloader<br /> |-<br /> | 2 || ''unknown'' || 2 || ||<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || <br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || <br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 7 || ''unknown'' || 1 || ||<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || <br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 36 || ''unknown'' || 4 || ||<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || <br /> | firmware version device part: xx.0.00<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=505 TL866 II PLUS/Bootloader 2018-08-26T19:54:09Z <p>Elemecca: /* Report */</p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 64-byte structure (unknown fields omitted):<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || ??<br /> | which firmware is running: &lt;tt&gt;01&lt;/tt&gt; is the stock firmware, &lt;tt&gt;02&lt;/tt&gt; is the bootloader<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || ??<br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || ??<br /> | firmware version major part: 00.x.00<br /> |-<br /> | 6 || &lt;tt&gt;bModel&lt;/tt&gt; || 1 || &lt;tt&gt;05&lt;/tt&gt;<br /> | device model: &lt;tt&gt;05&lt;/tt&gt; is the TL866II-Plus, &lt;tt&gt;06&lt;/tt&gt; is the XGecu T500<br /> |-<br /> | 8 || &lt;tt&gt;sDeviceCode&lt;/tt&gt; || 8 || ??<br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 16 || &lt;tt&gt;sSerialNumber&lt;/tt&gt; || 20 || ??<br /> | ISO 8859-1 string (no zero terminator)<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || ??<br /> | firmware version device part: xx.0.00<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=504 TL866 II PLUS/Bootloader 2018-08-26T19:20:04Z <p>Elemecca: </p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}<br /> <br /> <br /> === Report ===<br /> <br /> The report command requests that the firmware identify itself.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> The device will respond with a 64-byte structure:<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || &lt;tt&gt;bCommand&lt;/tt&gt; || 1 || &lt;tt&gt;00&lt;/tt&gt; || the command, echoed<br /> |-<br /> | 1 || &lt;tt&gt;bStatus&lt;/tt&gt; || 1 || ??<br /> | which firmware is running: &lt;tt&gt;01&lt;/tt&gt; is the stock firmware, &lt;tt&gt;02&lt;/tt&gt; is the bootloader<br /> |-<br /> | 4 || &lt;tt&gt;bFwVersionMinor&lt;/tt&gt; || 1 || ??<br /> | firmware version minor part: 00.0.xx<br /> |-<br /> | 5 || &lt;tt&gt;bFwVersionMajor&lt;/tt&gt; || 1 || ??<br /> | firmware version major part: 00.x.00<br /> |-<br /> | 40 || &lt;tt&gt;bDeviceVersion&lt;/tt&gt; || 1 || ??<br /> | firmware version device part: xx.0.00<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=503 TL866 II PLUS/Bootloader 2018-08-26T18:11:25Z <p>Elemecca: </p> <hr /> <div><br /> The [[TL866 II PLUS]] has a bootloader installed at the start of the internal flash which is used to update the firmware. The hardware reset vector (the instruction at &lt;tt&gt;0000h&lt;/tt&gt;) points to the bootloader. On each boot the bootloader inspects various state (TBD) and determines whether it should execute itself to allow firmware updates or jump into the main firmware.<br /> <br /> The process of reverse engineering the bootloader is still ongoing.<br /> <br /> == Commands ==<br /> <br /> === Reset ===<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=502 TL866 II PLUS/Bootloader 2018-08-26T18:00:28Z <p>Elemecca: </p> <hr /> <div><br /> == Reset ==<br /> <br /> Command &lt;tt&gt;3F&lt;/tt&gt; seems to be used to reset the device. When used from the stock firmware the device resets into the bootloader, and when used from the bootloader the device resets to the stock firmware.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3F&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 7 || 0 || reserved, set to zero<br /> |}<br /> <br /> When resetting from the stock firmware, another command is transmitted first. This may be some kind of key required to permit reset? Unknown until the firmware is dumped and analyzed.<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Offset || Field || Size || Value || Description<br /> |-<br /> | 0 || command || 1 || &lt;tt&gt;3D&lt;/tt&gt;<br /> | the command identifier<br /> |-<br /> | 1 || ''reserved'' || 3 || 0 || reserved, set to zero<br /> |-<br /> | 4 || key? || 4 || &lt;tt&gt;86 B9 78 A5&lt;/tt&gt;<br /> | unknown, maybe just a fixed key? Set statically in the official client.<br /> |}</div> Elemecca https://proghq.org/wiki/index.php?title=File:TSOP48_Adapter_Schematic.svg&diff=490 File:TSOP48 Adapter Schematic.svg 2018-08-25T18:26:05Z <p>Elemecca: Elemecca uploaded a new version of File:TSOP48 Adapter Schematic.svg</p> <hr /> <div></div> Elemecca https://proghq.org/wiki/index.php?title=TL866_TSOP48_adapter&diff=487 TL866 TSOP48 adapter 2018-08-25T18:04:33Z <p>Elemecca: add schematic</p> <hr /> <div>[[Category:TL866]]<br /> [[Category:Accessories]]<br /> <br /> The tl866 has a 40 pin ZIF socket, but that means that it can't talk to all the pins of a 44 or 48 pin chip without more pin muxes. There is an ATTiny13A that is being used as a rudimentary bit of DRM, and it has started causing problems. As of MiniPro version 6.0 certain counterfeit TSOP48 adapters have some flaw that can be detected. The solution would be to either upload Radioman's reverse engineered firmware from here: [https://github.com/radiomanV/TL866/tree/master/TSOP_Encryption Link], or to revert to MiniPro version 5.19 and Firmware 3.2.61. This rollback can be done with the [[Firmware Updater Tool]]. You can check if your adapter is fake by going to &quot;help/about/tsop48detect&quot;. <br /> <br /> <br /> [http://www.autoelectric.cn/MiniPro/TSOP48_identification.htm Autoelectric counterfeit page]<br /> <br /> <br /> [[File:TSOP48.jpg|200px]]<br /> [[File:TSOP48_Adapter_Schematic.svg]]<br /> <br /> == Rollback Fix ==<br /> <br /> Ok. you don't have the 5.91 version, download it here: [http://minipro.txt.si/index.php?title=Original_Windows_Software Minipro V5.91] and unzip it somewhere in a folder.<br /> <br /> then download my firmware updater here: [http://bit.ly/YaJYDq TL866 firmware updater] and unzip it.<br /> In my firmware updater folder you will find a exe file called TL866.exe; run it!<br /> Once the firmware updater starts, browse for a file called update.dat in the above downloaded 5.91 minipro folder.<br /> Click the reflash button!<br /> Done. You should have now the 3.2.61 firmware version. Just use minipro.exe from the 5.91 folder to work.<br /> If you will later want to use the 6.0 version of minipro you will be asked to reflash the firmware and obviously the minipro 6.0 version will upgrade the firmware again to 3.2.62 version.<br /> <br /> == Re-flash Fix ==<br /> <br /> Verified by Evan Allen to work, simply clone the git repository from here: [https://github.com/radiomanV/TL866/tree/master/TSOP_Encryption Link] and open the .cproj file in minipro, program the attiny13 @soic8 from the fake adapter in minipro and resolder. This changes the tsop48detect result from 'fake' to 'V3'.<br /> <br /> [http://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/msg936055/#msg936055 Alternate method]</div> Elemecca https://proghq.org/wiki/index.php?title=File:TSOP48_Adapter_Schematic.svg&diff=486 File:TSOP48 Adapter Schematic.svg 2018-08-25T18:04:09Z <p>Elemecca: </p> <hr /> <div></div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS/Bootloader&diff=467 TL866 II PLUS/Bootloader 2018-08-24T17:20:11Z <p>Elemecca: Created page with &quot; To reset from firmware: 3D 00 00 00 86 B9 78 A5 3F 00 00 00 00 00 00 00 To reset from bootloader: 3F 00 00 00 00 00 00 00&quot;</p> <hr /> <div><br /> <br /> To reset from firmware:<br /> 3D 00 00 00 86 B9 78 A5<br /> 3F 00 00 00 00 00 00 00<br /> <br /> To reset from bootloader:<br /> 3F 00 00 00 00 00 00 00</div> Elemecca https://proghq.org/wiki/index.php?title=TL866_II_PLUS&diff=464 TL866 II PLUS 2018-08-22T17:24:56Z <p>Elemecca: add more specific info on the micro</p> <hr /> <div>[[Category:TL866]]<br /> [[Category:Hardware]]<br /> [[Category:Programmer]]<br /> <br /> The TL866 II PLUS is '''NOT''' compatible with the [[TL866|TL866 A / TL866 CS]] models. The microcontroller has been changed from a PIC18 to a PIC24F and there are other significant schematic changes. The plastic enclosure for the TL866 II PLUS is identical to the TL866A / TL866CS.<br /> <br /> = Hardware =<br /> <br /> The TL866II PLUS is driven by a Microchip [https://www.microchip.com/wwwproducts/en/PIC24FJ256GB110 PIC24FJ256GB110] microcontroller which connects directly to the USB.<br /> <br /> = Photos =<br /> == TL866 II PLUS photos ==<br /> Photos of a TL866 II PLUS bought April 2018 from eBay seller goldenchipset.&lt;br/&gt;<br /> Red and yellow LEDs were desoldered from mainboard to allow separation of the two PCBs.&lt;br/&gt;<br /> [[File:TL866 II PLUS socketboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS socketboard bottom scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard top scan 1200dpi.jpg|160px]]<br /> [[File:TL866 II PLUS mainboard bottom scan 1200dpi.jpg|160px]]</div> Elemecca