TSDZ2 firmware flashing issues (and when to give up!)

wayfarer_boy

10 µW
Joined
Jan 9, 2022
Messages
5
Hi all

3 weeks ago I installed my new TSDZ2 kit and experienced an issue where the motor would cut out once I reached a high cadence. Reading that flashing the OSF (the emmebrusa firmware as I'm using the stock display) might solve this issue, I set off ordering my STLinkV2 and installing the necessary applications on my Windows machine.

Once I had everything I needed, I found that I couldn't start up the JavaConfigurator (Java would crash on opening) so I built and installed stm8flash on my Linux machine. After repeatedly failing to flash the OSF (an unknown 'SWIM ERROR' kept occurring) I reconnected the power and found the motor controller wasn't responding (no battery readout, no light control etc). Something had been partially written or the installation had borked partway through, either way, something had gone wrong.

Returning to my Windows machine, I used the JavaConfigurator (which now started up thanks to running Jarfix to fix my Java) to try to flash the OSF, but this failed on the option bytes. I then used STVP, and after repeated attempts of it complaining of 'swim errors' it finally flashed and successfully verified the option bytes. Running JavaConfigurator again to compile and flash the remaining files kept failing (again, with swim errors) so in desperation I ordered another STLinkV2 in case that was at fault.

I've now tried two STLinkV2s, and I'm still repeatedly getting SWIM errors. I've occasionally managed to flash the compiled JavaConfigurator ihx files from the src/controller directory with STVP, but the display still isn't controlling the motor or lights, and pedalling doesn't start the motor.

Right now, what I really want to do is send my motor to a place that can either a) flash the firmware for a fee, or b) tell me if I've bricked my motor and sell me a replacement. Does such a place exist in the UK? I feel like I've tried everything short of buying a new motor, and right now I could really do with a weekend that ends with me not feeling like a failure!
 
wayfarer_boy said:
....

Returning to my Windows machine, I used the JavaConfigurator (which now started up thanks to running Jarfix to fix my Java) to try to flash the OSF, but this failed on the option bytes. I then used STVP, and after repeated attempts of it complaining of 'swim errors' it finally flashed and successfully verified the option bytes. Running JavaConfigurator again to compile and flash the remaining files kept failing (again, with swim errors) so in desperation I ordered another STLinkV2 in case that was at fault.
...
It is not exactly clear what was wrong.
But for easy flashing Mbrusa OSF with the java configurator, STVP and SDCC MUST be installed in the root of a Windows system.
Also the Windows graphical version of STVP may NOT run, because Java configurator runs a CMD script for flashing, which can conflict if the graphical version runs also.

If you still have problems it is possible to go back to stock FW with the graphical STVP version
First flash optionbyte, then the program memory and data memory
If you haven't made a backup before:
See the eco-cycles site for stock FW versions
 
Elinx said:
....

But for easy flashing Mbrusa OSF with the java configurator, STVP and SDCC must be installed in the root of a Windows system.
Also the Windows graphical version of STVP may NOT run, because Java configurator runs a CMD script for flashing, which can conflict if the graphical version runs also.
...

I followed these instructions, so everything's definitely installed correctly and in the correct location in Windows. I've done the same in Linux via these instructions. I've also made sure any other apps are closed before starting the configurator or stvp.

Elinx said:
....
If you still have problems it is possible to go back to stock FW with the graphical STVP version
First flash optionbyte and then the data and program
If you haven't made a backup before:
See the eco-cycles site for stock FW versions
...

I've devoted this weekend to flashing the original stock firmware, first from the backup I originally made using stm8flash in Linux, and when that didn't work, from the eco-ebike google drive files. I've also been trying to flash multiple times until it succeeds, as suggested here and in several other pages in that thread. Early on this weekend I had an occasional success with flashing the option byte with stm8flash, but this evening I've tried flashing the option byte s19 file well over 200 times in a row and they've all failed with one of the following errors:

Code:
127 bytes at 0x4800... SWIM error 0x04
127 bytes at 0x4800... SWIM error 0x05
127 bytes at 0x4800... Tries exceeded

All errors I've seen throughout this whole process. I'm becoming convinced I've done something terminal to my motor. Anyone had this kind of error before? Any idea what it might be pertaining to?
 
wayfarer_boy said:
....

I've devoted this weekend to flashing the original stock firmware,....

All errors I've seen throughout this whole process. ....
imho Swim errors have to do with a lost or bad connection.
Some had more succes using 3.3V instead of 5V

I never had problems with flashing stock or the use of java configurator, so don't know of these errors.
With Javaconfigurator everything is done by the CMD script but with STVP you must be carefull with the settings.
If you use STVP, for backup and flashing the controller, there is a difference with the settings for stock FW and OSF.
For stock FW you must setup STM8S105x4 and for OSF STM8S105x6.
For restore the backup files the sequence of the 3 files is important. Optionbyte/data/program

I always use javaconfigurator to flash OSF, but before I check the connection with STVP.
Only if STVP reads the Tsdz2 without errors, I close STVP and start the Java configurator for flashing.
Otherwise I look first at the connections.

Another reason for the errors maybe could be the lenght of the cable, which must be short.
Personally I use the bare short cable with socks (added shrinktube), that came with the STlinkV2 and an extention USB cable to the laptop.
3 socks for +5V/Swim/Gnd directly to the tsdz2 and the not used wires to Gnd on the STlink.
 
Since my last post I've ordered a new motor. I figured I can at least start with a fresh slate and keep the other motor for parts or perhaps replace the bricked controller later on down the line. I'd done almost everything you mentioned in your last post (which was extremely helpful, thankyou)... apart from:

Elinx said:
I always use javaconfigurator to flash OSF, but before I check the connection with STVP.
Only if STVP reads the Tsdz2 without errors, I close STVP and start the Java configurator for flashing.
Otherwise I look first at the connections.

I didn't make the appropriate checks (or rather, I didn't know what I was looking for) when I first read and backed up the existing firmware. I have a feeling I was getting errors from the outset and didn't understand the output on the cmd line.

At least with this fresh motor I have a really good idea of how to go about safely flashing from a working Windows setup. Should make things a lot easier.

Elinx said:
3 socks for +5V/Swim/Gnd directly to the tsdz2 and the not used wires to Gnd on the STlink.

I hadn't thought of connecting the not used wire like that. These are great tips, thanks so much for taking the time to help. I'll post an update once I've successfully flashed the new motor. Positive thinking, eh!
 
It's very very unlikely that you've 'bricked' or damaged the controller, so don't dismantle the original motor for spares quite yet.

When I program mine, I have the TSDZ2 battery disconnected, I'm letting the STLINK-V2 5v and GND provide the power. Is that what you're doing? Perhaps it would help if you show a photo of your programming lead, from STLINK to the speed sensor cable?
 
-Pete- said:
It's very very unlikely that you've 'bricked' or damaged the controller, so don't dismantle the original motor for spares quite yet.

When I program mine, I have the TSDZ2 battery disconnected, I'm letting the STLINK-V2 5v and GND provide the power. Is that what you're doing? Perhaps it would help if you show a photo of your programming lead, from STLINK to the speed sensor cable?

That's given me a bit of hope! Here's the lead I'm using, along with one of the STLINK-V2s (I bought 2 just in case the first was faulty).

AM-JKLXx3t6xY6D4ZJjrxfDNQM5oVWbGjNflgJJW4_2NgPG1T8deScgp4ouUGu0oyQVIosT_1hauM-JN5-zy6GUHUkkqZYct3fiK3oEwMeVRyug1Bi3UOnrQd8ejZUfAMz-Y7MDYBNN7GlN_8tQYpux2cpd5wQ=w391-h695-no


and closeups:

AM-JKLWigm0npqyDO_HXaeFO2GAYS7WNQJtGdty4zVhgjXmn-AanNZR5pEZoVo_-B2Le5pu3GcQEiR1DKoyxcA54DcyfkQVm3nst3Wio1x1R3jp8NXHmGEUt4zjX0-svWR-ghhACTDaAt71KOisn_EaOQZFCeg=s695-no


I read on one of the posts in the TSDZ2 firmware thread that removing the housing for the STLINK-V2 may help reduce the possibility of shorting. I've also been disconnecting the battery and battery wires every time I've flashed from the start. I did, however, read on an eco cycles page that it may help to connect up the battery and switch on the display if the 5v isn't delivering enough power. That has been something that's crossed my mind - what if it's my laptop's underpowered USB socket?
 
My STLINK pinout is different, SWIM and GND are the other way round. With the STLINK unconnected, check the resistance between the outside of the USB plug and SWIM, mine is around 88K ohms. And obviously to the GND pins it’s almost zero.
 

Attachments

  • AAA280A3-F743-47D3-A8DD-C99BC42F5F64.jpeg
    AAA280A3-F743-47D3-A8DD-C99BC42F5F64.jpeg
    2.5 MB · Views: 753
-Pete- said:
My STLINK pinout is different, SWIM and GND are the other way round. With the STLINK unconnected, check the resistance between the outside of the USB plug and SWIM, mine is around 88K ohms. And obviously to the GND pins it’s almost zero.

Yes, I can see it's a slightly different configuration to mine. Had I not just successfully flashed my new motor, I'd be inclined to order in yet another STLINK! Flashing the new motor resulted in zero errors, successful first time, so I'm now sure I've done something irreparable to my old motor through user error rather than hardware error.

I've just ridden the bike around the streets for a while and it was really smooth with no cut-out (an issue I had with the stock firmware). Very happy/relieved!

Let's say I have bricked the old motor - would it just be a case of ordering in a new controller, or is it a little more complicated than that?

I'll still take some readings on the STLINK anyway and get back to you.
 
It seems there are different versions of STLINK copies, with different pinouts. How confusing.
https://forums.adafruit.com/viewtopic.php?f=19&t=139902

I'm no expert, but worst case you could change the controller. But if you open up the motor and look at the controller, perhaps you'll find a loose wire, PCB short or bad track? I think it'd be impossible to damage an STM8 by connecting only an STLINK, whatever you do. The inputs have protection against ESD and +/-5V won't hurt it.
 
Yes there are different models of such nice colored STlink adapters. Dependent of the used components on PCB
Sometimes they sell such STlink adapters with a wrong printed aluminium housing
So always check the pins on PCB after recieving it from the seller, before you connect the USB to PC
Never believe what is printed on the housing

About leaving the alumium housing away when flashing, I have some doubts
Because the STlink connection is very sensitive for interferention or picking up external signals,
I prefer that housing as a shield and short wires with not-used wires to gnd

Personally I think your (old) controller isn't damaged, but what went wrong with flashing I don't know
I always flash without battery, because you never know what happens with different power connections
What could help sometime is use the 3.3V instead of the 5V
If you still use the battery for power, don't connect the STlink power also, but just swim and gnd

It isn't that difficult to replace the controller and they aren't that expensive too.
 
On some motors the only way they will program is to use 3 volts, definately seems to work better if you have the bike battery disconnected and definately reload the option byte file using only the STLink software.
 
Another thing that works much more reliably (even over a bit longer cable lengths) is flashing using a slower stm8flash instead of
STVP_CmdLine. (At least on Windows - see example).

But last time it got so bad for me after failed flashing over a longer cable that I needed to use the 3.3V method. - It is strange because once it fails mid-flash and the controller is no longer talking to display, it seems it become "impossible" to flash with the previous method and you need a better one - in this case going down to 3.3V.
 
Back
Top