Post MotherBoard Specs Of Bricked TM Warthogs Here Please

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).

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.

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?

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.

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.

Throttle #00179 bricked this week after 11 years of flawlessness ! trying to get in touch with TM support.

Throttle #83219 passed away peacefully last night....

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:

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

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...

Good research regardless! Thanks for sharing, might help me fix my broken board.

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

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:

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

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 

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

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.

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.

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/

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.

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

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

@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).

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

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

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.