bn880 Posted December 4, 2020 Posted December 4, 2020 (edited) On 10/4/2020 at 10:49 AM, Osita said: Wow... is there no warranty for this stuff? Yes, there is warranty, until it runs out. Yes it still can happen. One of these days if I get enough time I might start selling something to fix the issue. I have already started plans on it and done work but it's not a top priority because right now TM are still providing warranty services and do sell replacements (usually slowly) if your warranty is out. And the replacement is not the cost of a new throttle. (and of course I offer the repair service for less) If shit hits the fan I will be there (and was when TM closed doors due to COVID for a bit). Edited December 4, 2020 by bn880 [sIGPIC][/sIGPIC]
Osita Posted December 23, 2020 Posted December 23, 2020 Good to know, BN880. I would certainly be happy to pay you for repairs if I get into a situation where the repairs are needed. 1
HannesMy Posted February 28, 2021 Posted February 28, 2021 (edited) Another dead Warthog Throttle here it seems, to say that I am pissed is an understatement. I wont go through the hassle of getting another error-prone PCB from TM, but I am rather thinking about rewiring the whole internals to an Arduino (or multiple if necessary) using the Arduino Joystick Library. In the end its all just switches and potentiometers, right? I am still researching before actually pulling the trigger and wanted to check if anybody here has some wiring diagrams or other Info of the throttle? Or anybody with more experience sees some blockers for this project? Edited February 28, 2021 by HannesMy
Victory103 Posted April 15, 2021 Posted April 15, 2021 Good info so far and thanks for keeping this thread alive. After years of play with a powered USB hub, I finished a flight and noticed something was wrong with my stick TMS Up button in the F-16 despite checking button bindings. Decided to fire up TARGET for some reason even though I never use it. Found out my stick FW was out of date as well as the TARGET software. Off to the TM site to download both. During the FW update to the stick, somehow my throttle got flashed. Working through the "bootleg method" and firing up an old ASUS gaming laptop to see if I can push the throttle firmware there. Combo has worked for years, and I even managed to not pinch any wires during the mini-stick update to the throttles. Kind of like Nvidia drivers, if it's not broke don't fix it.
bn880 Posted April 25, 2021 Posted April 25, 2021 (edited) On 4/15/2021 at 5:11 PM, Victory103 said: Good info so far and thanks for keeping this thread alive. After years of play with a powered USB hub, I finished a flight and noticed something was wrong with my stick TMS Up button in the F-16 despite checking button bindings. Decided to fire up TARGET for some reason even though I never use it. Found out my stick FW was out of date as well as the TARGET software. Off to the TM site to download both. During the FW update to the stick, somehow my throttle got flashed. Working through the "bootleg method" and firing up an old ASUS gaming laptop to see if I can push the throttle firmware there. Combo has worked for years, and I even managed to not pinch any wires during the mini-stick update to the throttles. Kind of like Nvidia drivers, if it's not broke don't fix it. Yeah, it's not really a great idea to flash the controller firmware if it's working. It definitely doesn't prevent bricking as we now know full well. Edited April 26, 2021 by bn880 [sIGPIC][/sIGPIC]
kam Posted May 2, 2021 Posted May 2, 2021 Throttle #00179 bricked this week after 11 years of flawlessness ! trying to get in touch with TM support. Intel 5820k | Asus X-99A | Crucial 16GB | Powercolor Devil RX580 8GB | Win 10 x64 | Oculus Rift | https://gallery.ksotov.co.uk Patiently waiting for: DCS: Panavia Tornado, DCS: SA-2 Guideline, DCS: SA-3 Goa, DCS: S-300 Grumble
speed-of-heat Posted June 22, 2021 Posted June 22, 2021 Throttle #83219 passed away peacefully last night.... SYSTEM SPECS: Hardware AMD 9800X3D, 64Gb RAM, 4090 FE, Virpil T50CM3 Throttle, WinWIng Orion 2 & F-16EX + MFG Crosswinds V2, Varjo Aero SOFTWARE: Microsoft Windows 11, VoiceAttack & VAICOM PRO YOUTUBE CHANNEL: @speed-of-heat
walmis Posted June 28, 2021 Posted June 28, 2021 (edited) Hey guys, I have managed to dump the firmware from the PSOC chip using open source tools, sadly it is from a faulty throttle and it appears the first part of flash is corrupt. It appears the memory is not read protected, so it should be possible to dump a working image. If someone does have a bluepill STM32F103 board at hand and is willing dump firmware from a working throttle, let me know. Firmware for the STM32 programmer: https://github.com/walmis/arduino_hssp psocdude: https://github.com/walmis/psocdude Also some useful hacking tools: https://github.com/trou/cypress_psoc_tools Once you have the firmware running on the bluepill, avrdude port called psocdude can be used to dump and write firmware on the PSOC. Ubuntu machine (or VM) is recommended to easily build the required tools. dumped flash file: warthog_throttle_dump.bin For comparison firmware file dumped from the TH windows utility: HA10T_PSOC_USB_v23.tmf The ISP header is conveniently placed on the PCB. Pinout on the BluePill board: SDATA_PIN -> PB15 SCLK_PIN -> PB14 XRES_PIN -> PB13 Flash read command (ubuntu): $ ./psocdude -C psocdude.conf -p CY8C24894 -c arduino -P /dev/ttyACM0 -b 115200 -U flash:r:out.bin:r psocdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.00s psocdude: Device signature = 0x001f psocdude: reading flash memory: Reading | ################################################## | 100% 3.09s psocdude: writing output file "out.bin" psocdude done. Thank you. Flash security configuration on chip: Spoiler Flash security settings: block 00 : Disable internal write block 01 : Disable internal write block 02 : Disable internal write block 03 : Disable internal write block 04 : Disable internal write block 05 : Disable internal write block 06 : Disable internal write block 07 : Disable internal write block 08 : Disable internal write block 09 : Disable internal write block 0a : Disable internal write block 0b : Disable internal write block 0c : Disable internal write block 0d : Disable internal write block 0e : Disable internal write block 0f : Disable internal write block 10 : Disable internal write block 11 : Disable internal write block 12 : Disable internal write block 13 : Disable internal write block 14 : Disable internal write block 15 : Disable internal write block 16 : Disable internal write block 17 : Disable internal write block 18 : Disable internal write block 19 : Disable internal write block 1a : Disable internal write block 1b : Disable internal write block 1c : Disable internal write block 1d : Disable internal write block 1e : Disable internal write block 1f : Disable internal write block 20 : Disable internal write block 21 : Disable internal write block 22 : Disable internal write block 23 : Disable internal write block 24 : Disable internal write block 25 : Disable internal write block 26 : Disable internal write block 27 : Disable internal write block 28 : Disable internal write block 29 : Disable internal write block 2a : Disable internal write block 2b : Disable internal write block 2c : Disable internal write block 2d : Disable internal write block 2e : Disable internal write block 2f : Disable internal write block 30 : Disable internal write block 31 : Disable internal write block 32 : Disable internal write block 33 : Disable internal write block 34 : Disable internal write block 35 : Disable internal write block 36 : Disable internal write block 37 : Disable internal write block 38 : Disable internal write block 39 : Disable internal write block 3a : Disable internal write block 3b : Disable internal write block 3c : Disable internal write block 3d : Disable internal write block 3e : Disable internal write block 3f : Disable internal write block 40 : Disable internal write block 41 : Disable internal write block 42 : Disable internal write block 43 : Disable internal write block 44 : Disable internal write block 45 : Disable internal write block 46 : Disable internal write block 47 : Disable internal write block 48 : Disable internal write block 49 : Disable internal write block 4a : Disable internal write block 4b : Disable internal write block 4c : Disable internal write block 4d : Disable internal write block 4e : Disable internal write block 4f : Disable internal write block 50 : unprotected block 51 : Disable internal write block 52 : Disable internal write block 53 : Disable internal write block 54 : unprotected block 55 : unprotected block 56 : unprotected block 57 : unprotected block 58 : unprotected block 59 : unprotected block 5a : unprotected block 5b : unprotected block 5c : unprotected block 5d : unprotected block 5e : unprotected block 5f : unprotected block 60 : unprotected block 61 : unprotected block 62 : unprotected block 63 : unprotected block 64 : unprotected block 65 : unprotected block 66 : unprotected block 67 : unprotected block 68 : unprotected block 69 : unprotected block 6a : unprotected block 6b : unprotected block 6c : unprotected block 6d : unprotected block 6e : unprotected block 6f : unprotected block 70 : unprotected block 71 : unprotected block 72 : unprotected block 73 : unprotected block 74 : unprotected block 75 : unprotected block 76 : unprotected block 77 : unprotected block 78 : unprotected block 79 : unprotected block 7a : unprotected block 7b : unprotected block 7c : unprotected block 7d : unprotected block 7e : unprotected block 7f : unprotected Edited June 28, 2021 by walmis 2
walmis Posted June 28, 2021 Posted June 28, 2021 I have an update. I resoldered the Cypress chip with hot air with new solder and flux and the throttle magically sprung back to life. Very weird...
Sideburns Posted June 28, 2021 Posted June 28, 2021 Good research regardless! Thanks for sharing, might help me fix my broken board. Ryzen 5800x@5Ghz | 96gb DDR4 3200Mhz | Asus Rx6800xt TUF OC | 500Gb OS SSD + 1TB Gaming SSD | Asus VG27AQ | Trackhat clip | VPC WarBRD base | Thrustmaster stick and throttle (Deltasim minijoystick mod). F14 | F16 | AJS37 | F5 | Av8b | FC3 | Mig21 | FW190D9 | Huey Been playing DCS from Flanker 2.0 to present
_Hoss Posted August 31, 2021 Posted August 31, 2021 On 6/28/2021 at 7:31 AM, walmis said: I have an update. I resoldered the Cypress chip with hot air with new solder and flux and the throttle magically sprung back to life. Very weird... Did the original solder joints look gray and mealy?........... Care needs to be taken that you do not use too high a wattage iron, use one designed for fine electronic circuitry. I've seen crap loads of videos online of guys soldering new parts into their warthog, I wanted to cringe at what I saw. If you have some type of magnification device inspect your solder joints, for that dull gray finish, with a mealy texture. You would hope from the factory they would be nice bright, shiny, concave fillets that last a good long time. Also if you use any type of liquid flux to assist in soldering clean it all up with alcohol, FLUX is your friend when soldering, and your enemy if you don't get it all off. and a little dab will do you. Your computer should be on a very good surge protector or UPS. Power companies are not the most stable electrical sources, power spikes in the summer when they switch loads will fry electronics if strong enough. I have one of these on both of my Entertainment set ups if you can't afford a really good UPS. https://www.showmecables.com/10-outlet-home-theater-surge-protector-7-ft-cord?gclid=Cj0KCQjwg7KJBhDyARIsAHrAXaFlHZd-fwgyHoB_LVf4rzGHpdc-deqaNXD16Xufz2feQrepedB2oTsaAkGkEALw_wcB And I have a UPS on my computer. Cheers and good luck Hoss Sempre Fortis
walmis Posted August 31, 2021 Posted August 31, 2021 5 hours ago, BeoWolf_57 said: Did the original solder joints look gray and mealy? The original soldering looked fine, therefore I was surprised resoldering the chip actually worked. Maybe heat corrected some fault inside the chip, similar how old GPUs in laptops were fixed by heating them. The throttle still works fine to this day. 5 hours ago, BeoWolf_57 said: Care needs to be taken that you do not use too high a wattage iron, use one designed for fine electronic circuitry. I've seen crap loads of videos online of guys soldering new parts into their warthog, I wanted to cringe at what I saw. If you have some type of magnification device inspect your solder joints, for that dull gray finish, with a mealy texture. You would hope from the factory they would be nice bright, shiny, concave fillets that last a good long time. Also if you use any type of liquid flux to assist in soldering clean it all up with alcohol, FLUX is your friend when soldering, and your enemy if you don't get it all off. and a little dab will do you. Your computer should be on a very good surge protector or UPS. Power companies are not the most stable electrical sources, power spikes in the summer when they switch loads will fry electronics if strong enough. I have one of these on both of my Entertainment set ups if you can't afford a really good UPS. https://www.showmecables.com/10-outlet-home-theater-surge-protector-7-ft-cord?gclid=Cj0KCQjwg7KJBhDyARIsAHrAXaFlHZd-fwgyHoB_LVf4rzGHpdc-deqaNXD16Xufz2feQrepedB2oTsaAkGkEALw_wcB And I have a UPS on my computer. Actually a hot air station is required to perform this procedure. Iron only does not suffice here. As for the iron, I can't recommend TS-100 enough - last iron you'll ever need https://eleshop.eu/ts100.html (also lots of options available on aliexpress, banggood etc.) This video shows how the procedure looks like:
Dannyvandelft Posted September 16, 2021 Posted September 16, 2021 Everything on my throttle works, except the left throttle (Z-rotation) isn't anymore. Anybody got any fixes? I recently did the slew upgrade and ever since then it stopped working. I updated the throttle as the instructions said, is that what did it? Sent from my SM-G960U using Tapatalk
Wood Posted December 23, 2021 Posted December 23, 2021 (edited) So flying the other day. My joystick started to act up by activating every switch on it without touching them. Looking into the windows controller I found that the as soon as I moved the stick on either y or x axis would activate all switches. First thing that I thought was WT#@. All my flight controls are plugged into a separate usb 3 powered hub. So I thought I would update the firmware/ drivers and still nothing. Now the stick would even register in windows as a controller. It will appear in the hardware but not as a controller. Tried researching anything on this and nothing that really helps. The only reference i found was from TM indicating the problem could come from the throttle a base connection. Not sure why but hours of trying to repair this and nothing. The only good thing about this is me taking the stick completely apart and giving it a good cleaning with regressing it and now it moves like it was new except that it does work. Frustrating to say the least. my concern is if I pick up a new one will it happen again to the throttle next and have to go through the same crap. I believe it was page 5 a post from Tie that I’ll try before purchasing another one. Thanks for continuing this thread. wood Edited December 23, 2021 by Wood Cheers Wood Windows 10, Intel i7-6700 CPU @3.40GHz, 32GB ram , GTX 4060Ti
DutchCoolHand Posted December 24, 2021 Posted December 24, 2021 Serial number 10375 bricked tonight after 15+ years of flawless operation. Just when I am off for a week and was getting ready to fly a lot, ugh Peter AMD RYZEN 7 2700 / 32GB / RTX2070 / 500GB M.2 with Windows and DCS / 2 - 500GB SSD / Rift S/ TM Warthog with F18 stick and Virpil WarBRD / Foxx Mounts/ MFG Crosswind rudders + 3 MFD's | Now enjoying VR with PointCTRL controllers + Gamematrix JetSeat
Janssen Posted December 28, 2021 Posted December 28, 2021 (edited) Mine (Member No. 94959) bricked too, just after 2-years and 3 weeks. Just before Christmas I powered down my pc completely with the switch on the powersupply. After 2 days switched it back on and the throttles' 5 LEDs only flash for a brief moment and 'USB device not recognized' appears in Windows 10. I'm in the process of repairing it myself, why not, Canada is just a bit too far away. I'm pretty sure I can swap out this QFN chip and have all the stuff needed except for the replacement chip and the firmware, so I wanted to ask @walmis if you succeeded in flashing or reading the chip by any chance? I see you managed to repair it by reflowing, but maybe you managed to get a working dump from the chip as well? Already oredered a bunch of these CY8C24894-24LTXI chips and have a few Arduinos laying around. Parallel to this I wrote TM an email about ordering a new motherboard, I live in the Netherlands, so shouldn't take that long. Just in case. Edited December 28, 2021 by Janssen
Janssen Posted December 28, 2021 Posted December 28, 2021 (edited) Never mind, I'm able to read the chip as well now At first I compiled the wrong Psocdude. My dumpfile is identical to yours @walmis I used an Arduino Leonardo with this program -> https://github.com/miracoli/arduino_hssp SDATA_PIN -> 9 SCLK_PIN -> 8 XRES_PIN -> 4 5V -> to the 5V pin on the Arduino GND -> to the GND pin on the Arduino Furhtermore I used VM Workstation 16 and loaded an Ubuntu 20.04.3LTS server (headless) on it. Bind comX, for X look into device manager where your Arduino resides. In my case COM8. Installed the needed tools (autotools-dev automake gcc) and compiled Walmis' psocdude. psocdude -C psocdude.conf -p CY8C24894 -c arduino -P /dev/ttyS1 -b 115200 -U flash:r:out.bin:r And I got my bin file. Edit: tried to write the BIN file back to the Cypress chip. In the end I get a verficiation error: psocdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% 0.01s psocdude: Device signature = 0x001f psocdude: NOTE: "flash" memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. psocdude: erasing chip psocdude: reading input file "TMWarthog.bin" psocdude: writing flash (16384 bytes): Writing | ################################################## | 100% 17.65s psocdude: 16384 bytes of flash written psocdude: verifying flash memory against TMWarthog.bin: psocdude: load data flash data from input file TMWarthog.bin: psocdude: input file TMWarthog.bin contains 16384 bytes psocdude: reading on-chip flash data: Reading | ################################################## | 100% 7.63s psocdude: verifying ... psocdude: verification error, first mismatch at byte 0x0000 0x51 != 0x00 psocdude: verification error; content mismatch psocdude done. Thank you. Guess I bricked it because the first 8k is not there in the .BIN. Edited December 29, 2021 by Janssen
walmis Posted December 29, 2021 Posted December 29, 2021 On 12/28/2021 at 2:02 PM, Janssen said: Mine (Member No. 94959) bricked too, just after 2-years and 3 weeks. Just before Christmas I powered down my pc completely with the switch on the powersupply. After 2 days switched it back on and the throttles' 5 LEDs only flash for a brief moment and 'USB device not recognized' appears in Windows 10. I'm in the process of repairing it myself, why not, Canada is just a bit too far away. I'm pretty sure I can swap out this QFN chip and have all the stuff needed except for the replacement chip and the firmware, so I wanted to ask @walmis if you succeeded in flashing or reading the chip by any chance? I see you managed to repair it by reflowing, but maybe you managed to get a working dump from the chip as well? Already oredered a bunch of these CY8C24894-24LTXI chips and have a few Arduinos laying around. Parallel to this I wrote TM an email about ordering a new motherboard, I live in the Netherlands, so shouldn't take that long. Just in case. Sadly I scrapped the idea after realizing the bootloader part is read protected. I tried various stuff like disassembling existing TM firmware, trying to compile a hello world image using the PSoC designer and comparing the vector table structure to TM firmware, trying HSSP commands. This post is interesting and a good reference https://syscall.eu/blog/2018/03/12/aigo_part2/
Janssen Posted December 30, 2021 Posted December 30, 2021 (edited) Ouch I might have wiped that part by flashing without the -D option… Good info, I might give it a try with Python with the new board. Not sure how to proceed after that… Edit: just ordered the new board, €45,37 (51USD) shipping included. The part number is: "5090084 HOTAS WARTHOG THROTTLE MAIN PCB" just in case you want to speed things up. Edited December 30, 2021 by Janssen
acidwise Posted January 2, 2022 Posted January 2, 2022 (edited) Bought #28658 broken with the same problem: device not recognized. Initially had 3.2V at D+, 0V at D-. Measured the resistance and voltage drop (diode test mode) at D+ and D-: about 20 MOhm, 0.76V. Observed no activity with the oscilloscope. After the measurements got 0V at D+ too and no recognition from the system whatsoever, respectively. I guess, this CY8C24894-24LTXI is really succeptible to ESD... This is the first IC I managed to further damage this way. Reworking the chip did not help (as actually expected), so walmis was lucky. By the way, don't even bother to replace it without a preheater (board temperature about 140° C). Let's see if I get something out of HSSP. Waiting for ICs from China. @Janssen: do you have the replacement chips on hand? Could you please try to measure the resistance and voltage drop (with reversed probe polarity) of the D+/D- lines of your chip and the replacement one? The latter may go bad after the measurement... upd1: If somebody in Europe can donate a broken PCB, please let me know. In case of success the firmware will be available publicly. upd2: Managed to dump the firmware (see attachment). There are some difference with the file from walmis. For example, everything up to 0h14BF is completely empty. Need to think about it. out.bin upd3: Trying to understand the original firmware. Found v20 version from 2011 (see attachment). Looking for 2010_TWHM_1.exe driver pack, which should include HA10T_PSOC_USB_v18.tmf HA10T_PSOC_USB_v20.tmf upd4: Working on a vector attack. Current problem: arduino_hssp from trou does not work, but seems to be necessary. There is quite a number of differences to the version by miracoli, trying to locate the issue. @walmis, how far have you got with the vector attack using the blue pill? Can someone with a working board dump and share the firmware by using the Thrustmaster utility FlashSpaceReader? This may be a faster way. A copy is attached, original at ftp://ftp.thrustmaster.com/accessories/pc/hotas/exe/HOTAS_Warthog/TMHW_FSR.zip TMHW_FSR.zip Edited January 3, 2022 by acidwise Dump added. Firmware v20 added. Status update.
walmis Posted January 4, 2022 Posted January 4, 2022 (edited) On 1/2/2022 at 1:14 PM, acidwise said: upd4: Working on a vector attack. Current problem: arduino_hssp from trou does not work, but seems to be necessary. There is quite a number of differences to the version by miracoli, trying to locate the issue. @walmis, how far have you got with the vector attack using the blue pill There's also my fork https://github.com/walmis/arduino_hssp/commits/master based on miracoli. I've made a few changes you can see in the commit list. I didn't proceed with the the vector attack. Since resoldering the chip magically worked, I decided not to waste more time on this. But this is interesting nonetheless and hope something comes out of it. On 1/2/2022 at 1:14 PM, acidwise said: upd2: Managed to dump the firmware (see attachment). There are some difference with the file from walmis. For example, everything up to 0h14BF is completely empty. Need to think about it. I think first ~6K of flash is the read protected bootloader. On 1/2/2022 at 1:14 PM, acidwise said: Can someone with a working board dump and share the firmware by using the Thrustmaster utility FlashSpaceReader? This may be a faster way. A copy is attached, original at ftp://ftp.thrustmaster.com/accessories/pc/hotas/exe/HOTAS_Warthog/TMHW_FSR.zip TMHW_FSR.zip Doubt it will dump the bootloader, but worth a try. One attack I could think of would be to load an app using existing app structure (see .tmf). I did not manage to find the correct entry point jump address, btw. The rogue app would dump the data of the bootloader using ROMX instruction. It shouldn't be too difficult (I guess) to patch in a loop which would bitbang data to gpio. Sadly the PSoC1 tools are quite old. Maybe some cmdline utilities might be useful from the PSoC1 designer software. I did install that on WinXP virtual machine, LOL. BTW, I did manage to reflash the same dump using arduino_hssp and psocdude (but without erasing chip ! ) and that firmware worked after resoldering the chip. So that confirms the arduino_hssp should work (my fork). Info dump: CY8C24894 datasheet AN2100 Bootloader: PSoC® 1 Infineon-Assembler.book-UserManual-v01_00-EN.pdf PSoC® USB HID Bootloader Getting Started With PSoC® 1 https://github.com/steve-m/m8cutils https://www.mikekohn.net/micro/naken_asm.php - powerful disassembler/assembler/simulator Edited January 5, 2022 by walmis add info dump
acidwise Posted January 4, 2022 Posted January 4, 2022 (edited) @walmis could you please try the FSR tool? In case it bricks your board I will buy it for the price of the replacement part, so it is fair. Anyhow, thank you for sharing. I am new to the PSoC and the links you provided are valuable. Will see how far can I get. I guess you have much more experience in that topic and I would appreciate any advice. However, at this point I am skeptical about the romx approach, looking back at the Aigo hack. 1. By just looking at the dump I have noticed, that the sections 14C0h - 1FFFh and 34C0h - 3FFFh are identical. That seems weird: I see no reason to duplicate the code in the flash. There might be a problem with the data read (i.e. wrong bank). 2. According to AN2100, the bootloader should be in 3600h - 3FFFh. Why would it land into 0h - 14BFh? Maybe we do already have it from tmf? Or is the address space reversed somehow? 3. If block checksum verification are used, which should be the case (found some comments mentioning automatic entering the bootloader mode with a corrupted flash), there must be a checksum section. Again according to AN2100, in 3500h-3600h. In addition, the bootloader checksum section should be also in the application space: 35D8h - 35FFh, I guess. This provides some good starting information. 4. The 64-byte blocks in 2000h-34BEh are identical, which is again strange at the first glance. Hopefully the disassembler will provide a better insight... Should we spin off the hack thread? upd1: 5. A few posts ago you have shared the security configuration. There are only 128 blocks out of 256 listed. Is it a cut citation or an incomplete read? upd2: Set up Win7 VM with PSoC Designer. Checked the datasheet of the BootLdrUSBFSe_5 module. It is somewhat different to AN2700. It looks like there is no checksum block in the application area, which is pity. The bootloader should actually be protected and expected to be in the first part of the address space together with the read-only interrupt vectors part, which is always write-protected. It seems that the address space in AN2700 is "inverted" and the bootloader is missing in the dump. Analyzed v23.tmf a bit further. Will update if something more becomes obvious. 0x0: header "FWFG" 0x04: 80h - application code offset? 0x68: 17h - version (23) 0x6C: firmware date 0x70: firmware compilation time 0x6BA: 4F 04 04 04 00 01 - USB IDs (VID 044F, DEV 0404, REV 0100) 0x538: USB device name string Unfortunately, VID 044F, DEV 0403 for "bulk" throttle (bootloader mode) is not in the file. Hence, the bootloader is not provided with the .tmf as well (unless encrypted / compressed). Edited January 4, 2022 by acidwise
walmis Posted January 5, 2022 Posted January 5, 2022 (edited) 16 hours ago, acidwise said: However, at this point I am skeptical about the romx approach, looking back at the Aigo hack It might work if code will be executed from flash.[1] We just need to find the entry point, assemble a simple dumper program and patch the existing code and flash it using psoc dude. My guess it would be easiest to just bit-bang using any output pin and capture it using a logic analyzer. 16 hours ago, acidwise said: 4. The 64-byte blocks in 2000h-34BEh are identical, which is again strange at the first glance. Hopefully the disassembler will provide a better insight... Yeah, there was a bug which should be fixed in my arduino_hssp fork. 16 hours ago, acidwise said: I guess you have much more experience in that topic Ha. Not really, just read the same stuff out there I have attached the last *correct* dump. I used this one to reflash the chip using psocdude. And since it didn't brick, I assume it's correct Regarding the bootloader, let's not assume TM is using this bootloader implementation from the app note. Maybe they spinned their own BL which sits in front of flash. What's interesting is the vector table starting at 000014c0 which should provide some insight. There appear to be some maybe valid jump addresses. naken_util -m8c -disasm -address 0x0 warthog_throttle_dump.bin 0x14e0: 7d 1b e6 ljmp 0x1be6 7 0x14e3: 7e reti 10 0x14e4: 7e reti 10 0x14e5: 30 halt 9 0x14e6: 30 halt 9 0x14e7: 30 halt 9 0x14e8: 7d 1b e9 ljmp 0x1be9 7 0x14eb: 7e reti 10 0x14ec: 7e reti 10 0x14ed: 30 halt 9 0x14ee: 30 halt 9 0x14ef: 30 halt 9 0x14f0: 30 halt 9 0x14f1: 30 halt 9 0x14f2: 30 halt 9 0x14f3: 30 halt 9 0x14f4: 30 halt 9 0x14f5: 30 halt 9 0x14f6: 30 halt 9 0x14f7: 30 halt 9 0x14f8: 30 halt 9 0x14f9: 30 halt 9 0x14fa: 30 halt 9 0x14fb: 30 halt 9 0x14fc: 30 halt 9 0x14fd: 30 halt 9 0x14fe: 30 halt 9 0x14ff: 30 halt 9 0x1500: 7d 1a c2 ljmp 0x1ac2 7 0x1503: 7e reti 10 0x1504: 7e reti 10 0x1505: 30 halt 9 0x1506: 30 halt 9 0x1507: 30 halt 9 0x1508: 7d 03 c7 ljmp 0x03c7 7 0x150b: 7e reti 10 0x150c: 7d 1a 82 ljmp 0x1a82 7 0x150f: 7e reti 10 0x1510: 7d 1a 92 ljmp 0x1a92 7 0x1513: 7e reti 10 0x1514: 7d 1a a2 ljmp 0x1aa2 7 0x1517: 7e reti 10 0x1518: 7d 1a b2 ljmp 0x1ab2 7 0x151b: 7e reti 10 0x151c: 7d 1a f1 ljmp 0x1af1 7 I attached full assembly dump for convenience. EDIT: Did a diff with HA10T_PSOC_USB_v23 Only change is here, I'd assume it's the calibration data stored in last 64 byte page . Hmm, wonder If we could squeeze a little dumper program there and jump to it using HSSP. [1] Infineon-AN2015_PSoC_1_Getting_Started_with_Flash_&_E2PROM-ApplicationNotes-v10_00-EN.pdf section 3.3. "A running program is never prevented from performing internal reads. The romx and index assembly instructions enable the M8C processor to read from flash for any protection level. " So there IS a chance to read the bootloader! warthog_throttle_dump.hex.txt warthog_throttle_dump.asm.txt warthog_throttle_dump.bin Edited January 5, 2022 by walmis
walmis Posted January 5, 2022 Posted January 5, 2022 (edited) Well, I'll be damned. The FSR utility actually dumped the whole ROM! tmThrottleFlashEeprom There you go guys, flash away! One thing to note, you need to save calibration data from the old chip from the last 64 byte sector. USB might not work, but HSSP should. That will save the hassle of having to recalibrate the device. I have a few spare chips, If some of you want a board fixed, let me know via PM. I'm in Europe/Lithuania. out of chips Edited January 5, 2022 by walmis
acidwise Posted January 5, 2022 Posted January 5, 2022 (edited) Nice! Thank you very much! Total euphoria! Thank you very much for trying FSR, was about to order a new board for tests. Unfortunately my chip seems to be damaged at the USB side. Nevertheless, to finish the topic, I have a couple of questions regarding your hssp routines and flashing without erase (which shouldn't actually happen). Expect a follow-up. Props for sharing! upd1: Identical 180-byte section in bootloader (1E69h and E32h). Does not necessarily an error, but interesting. Calibration is not a big loss anyway, since there is a tool available: TM Joystick Calibration tool 1.13.rar FSR seems to omit the last 32 bytes (half a section). Weird. Flashing via HSSP will require full 16K dump. What bothers me somewhat is 7Dh (LJMP) at 0 offset. @Janssen had 51h (MOV A). psocdude: verification error, first mismatch at byte 0x0000 0x51 != 0x00 It is also interesting, that this section was not wiped after flashing the dump with an empty bootloader. There should have been a locked interrupt table. Did not expect it much to change. Both opcodes seem to make sense though. upd2: Meld arduino_hssp from trou und walmis to work with Leonardo. Now the dump looks much better. The bank selection, as I assumed, was the reason. The patch by walmis (see arduino_hssp.ino) solves the issue. I don't see a point in forking once again, @walmiscould you maybe submit a pull request? The correct dump is here: out_v2.bin The version can be read at 1700h (00 17 00 01 -> v.23). It seems the entire last block contains calibration data. Is dumping a half of the section a bug or a feature of FSR - who knows. Really important is that it dumps the protected part of the flash. I would expect, that flashing the FSR dump will restore the device functionality, but misalign the axes, unless the remaining 32 bytes are extracted via hssp beforehand and added to the dump. A recalibration will probably be necessary, if the section remains missing (agreed with @walmis). The ready-to-flash firmware is here: TM_Warthog_Throttle_v23.binNot tested yet, waiting for blanks. Edited January 6, 2022 by acidwise Total euphoria! Calibration tool added. Dump added. Full firmware added.
Recommended Posts