Improving original firmware - TongSheng TSDZ2 mid drive motor

[casainho]

Wish list of improvements:
- send motor/battery current to LCD
- send the pedal cadence

With LCD3, I started to develop the firmware for it and I then can measure battery voltage, with battery current we can see on LCD battery power being used.

With pedal cadence and torque, we can see on LCD human/user power.


Here is the original firmware after being disassembled with out comments:

https://docs.google.com/spreadsheets/d/1Zuv3ELZCQJf2eksGHNJ1gKZ7Hxlrk2OHaV0mXiXQ5Hs

Some notes of what will be our working:

Here is a function that is called to set ADC start read bit and waits for the end of reading:

0xb983: c7 54 00 ld $5400,A cycles=1
0xb986: 72 10 54 01 bset $5401, #0 cycles=1
0xb98a: 72 0f 54 00 fb btjf $5400, #7, $b98a (offset=-5) cycles=2-3
0xb98f: 81 ret cycles=4

And here the function that reads ADC 5, battery/motor current:

0x85bd: a6 12 ld A, #$12 cycles=1
0x85bf: b7 31 ld $31,A cycles=1
0x85c1: cd b9 90 call $b990 cycles=4
0x85c4: a6 05 ld A, #$05 cycles=1
0x85c6: cd b9 83 call $b983 cycles=4
0x85c9: c6 54 04 ld A, $5404 cycles=1
0x85cc: a1 3f cp A, #$3f cycles=1
0x85ce: 24 07 jrnc $85d7 (offset=7) cycles=1-2
0x85d0: 48 sll A cycles=1
0x85d1: 48 sll A cycles=1
0x85d2: ca 54 05 or A, $5405 cycles=1
0x85d5: 20 02 jra $85d9 (offset=2) cycles=2
0x85d7: a6 ff ld A, #$ff cycles=1
0x85d9: 97 ld XL, A cycles=1
0x85da: b6 31 ld A, $31 cycles=1
0x85dc: a1 12 cp A, #$12 cycles=1
0x85de: 26 dd jrne $85bd (offset=-35) cycles=1-2
0x85e0: 9f ld A, XL cycles=1
0x85e1: b7 d0 ld $d0,A cycles=1
0x85e3: b7 d1 ld $d1,A cycles=1
0x85e5: 81 ret cycles=4

Maybe we just need on our UART send code, to read that ADC motor current channel, get the value and send it to us

 

[casainho]

Here is the TSDZ2 original firmware with an improvement to send motor current to LCD (still original LCD does not read motor current). This is mostly for developers/advanced users that may want to use LCD3 instead of the original LCD or some Arduino, etc.

View attachment TSDZ2_original_firmware-Flexible.zip

After disassembling we got good insights of some parts of the firmware do work. We could understand how data is sent to LCD and we could add our own function with the needed changes to send the current to the LCD.

Here is current disassembled file with our knowledge: https://docs.google.com/spreadsheets/d/1Zuv3ELZCQJf2eksGHNJ1gKZ7Hxlrk2OHaV0mXiXQ5Hs/edit?usp=sharing

 

[hurzhurz]

I have checked it as you asked me to. Didn't notice any error, but that was to hasty
I tried it and it didn't work, so I debugged while sitting in the garage next to my bike.

I got it working... but $68 is unfortunately not the one we are looking for... doesn't behave like it should for motor current.
But at least we can now easily try out other bytes!

You can lookup my changes in the spreadsheet (besides one little other mistake you made while editing the bin file).
Here is the modified file, but in Intel HEX format to directly use it with STVP.

 

[casainho]

I have checked it as you asked me to. Didn't notice any error, but that was to hasty
I tried it and it didn't work, so I debugged while sitting in the garage next to my bike.

I got it working... but $68 is unfortunately not the one we are looking for... doesn't behave like it should for motor current.
But at least we can now easily try out other bytes!

You can lookup my changes in the spreadsheet (besides one little other mistake you made while editing the bin file).
Here is the modified file, but in Intel HEX format to directly use it with STVP.

Thank you testing!!

That is also great to know that firmware keeps working well.

On the limit, we can try read motor adc on our function. But anyway, let's see if we find the correct address. As you may know, I identified were motor current is being reading: at timer1 PWM cycle inerrupt, just at begin. Can you please give a look? Maybe I did any small mistake...

 

[casainho]

Although for some reason the controller I have seems to not startup well the motor, I already flashed with original firmware and our improved firmware. I also put LCD3 printing the current value and it works for what I can see!! Because although the motor don't rotates well, it asks current from the lab power supply and I can see on the LCD the value.

I changed my file with your corrections to my previous file. I also did forget the change the address for the call to our function. After this changes, I am pretty sure it is working!!

View attachment TSDZ2_original_firmware-Flexible.zip

 

[hurzhurz]

If your motor doesn't start, check the EEPROM and maybe recover from your dump.
I had wrong values there from testing before I finaly had fixed everything.

 

[casainho]

If your motor doesn't start, check the EEPROM and maybe recover from your dump.
I had wrong values there from testing before I finaly had fixed everything.

Got motor working now... had to reconnect the hall sensors cable.

And now that is does work, I can't see any value, sometimes just changes 1 unit at startup... I wounder if it only stores high currents values..

 

[casainho]

It should work...

I exchanged $68 for $5B and I got what I expected: real time value of throttle!!

So, 0x85bd is called at startup, only once. I think it is for storing of motor ADC value offset value, at startup when ADC has a value for 0 current. The function stores the values on: %d0 and %d1. I think they both stored the offset value as a 16 bits variable.

Well, and %d0 and %d1 are also printed as zero. I know the offset should be zero has this hardware has 0 volts ADC when motor is stopped... this hardware can't measure negative/regen current.

Can you please try the latest file I posted?? maybe for the value to show up, it needs some high current, more than the 1.5A my motor takes without load.

 

[casainho]

It kind of works, but while riding the ebike the read value is always 0. What does the current value means?? Sometimes I quickly saw values like 20 or 30, as seen on the video. But this is only at startup with the wheel blocked....

Maybe we should try read ADC 5 by our own and done!

[youtube]ulfpUQFU3Pc[/youtube]

 

[casainho]

Got it!!!!!

It is register $1d!!

[youtube]LmT9hLkoHAs[/youtube]

 

[hurzhurz]

Great, congratulations!

 

[casainho]

Great, congratulations!

Congratulations for you too!!

 

[casainho]

I pushed the firmware files, including the calc sheet, to here: https://github.com/OpenSource-EBike-firmware/TongSheng_TSDZ2_motor_controller_firmware

 

[John and Cecil]

What is that number, the current amp draw of the motor?

 

[casainho]

What is that number, the current amp draw of the motor?

I hope in a few hours to do a real ride and then I will say.

I need to have assist level working before doing that ride...

 

[casainho]

Assist level now works. I wanted to show the brake symbol on LCD but turns out that TSDZ2 motor control don't send the brake state to LCD :-( -- yes, I am using brakes and I really can't live with brakes connected.

0 assist level is the same as motor turned off.

NOTE: the values shown on LCD are twice of the real value due to a small mistake I did on the code.

[youtube]lGd828Sk7tk[/youtube]

 

[casainho]

I did some quick tests on an accentuated climb.
Assist level 1: max around 6 amps
Assist level 2: max around 12 amps
Assist level 3: max around 18.4 amps
Assist level 4: max around 18.4 amps

Maybe the difference between 3 and 4 is speed limit and not current limit.

 

[hurzhurz]

I have done a bit of work to send the original message unmodified and to send an own custom message right after it instead.
That should also make it easier to test yet unknown registers / variables, It is prepared for 10 bytes of data (can be increased easy if needed).

I did successfully test it a bit, but can not go on with testing at the moment.
I must have broken something while I flashed another version with more variables (maybe 5v regulator or/and torque sensor, probably not firmware related).
The motor still sends the messages correctly, but I think it doesn't make sense to check values if the motor hums and doesn't run very well...

Here is my latest version with about 9 bytes where I had the hope to find something related to the PAS sensor.
And I also made a spreadsheet as a helper for easier assembler/opcode editing (jump address adjustment etc.):
https://docs.google.com/spreadsheets/d/1Zd2CQJKm7IopjqLz5JxIgySIFSY2SehPrXzffIbaVwM/edit?usp=sharing

Oh and about the PAS sensor, I think it has two hall sensors to detect the rotation direction...

 

[casainho]

I have done a bit of work to send the original message unmodified and to send an own custom message right after it instead.
That should also make it easier to test yet unknown registers / variables, It is prepared for 10 bytes of data (can be increased easy if needed).

I did successfully test it a bit, but can not go on with testing at the moment.
I must have broken something while I flashed another version with more variables (maybe 5v regulator or/and torque sensor, probably not firmware related).
The motor still sends the messages correctly, but I think it doesn't make sense to check values if the motor hums and doesn't run very well...

Here is my latest version with about 9 bytes where I had the hope to find something related to the PAS sensor.
And I also made a spreadsheet as a helper for easier assembler/opcode editing (jump address adjustment etc.):
https://docs.google.com/spreadsheets/d/1Zd2CQJKm7IopjqLz5JxIgySIFSY2SehPrXzffIbaVwM/edit?usp=sharing

Oh and about the PAS sensor, I think it has two hall sensors to detect the rotation direction...

Good that you doing the things in structured way, I must say I probably could not do that but I understand it is really important.

Why not put the content of that new file on the same previous file, on another sheet? I think would be easier to track changes. By the way, tell me your github id so I can add you write access, where I am storing the file, etc.

Good to have 10 bytes, I think we can implement much more features. Recently I found that original package don't send brake state and I would like to have it. It is nice for user/technician installer to debug for a working brakes.

See that last time my motor was not working and I had to shake the wires on the board, for the hall sensors.

 

[hurzhurz]

Yeah, it's not my strength either. But I think it's helpful here.

Well, I started it as a separate document because I was just playing around at first.
But I don't mind if you prefer to include it in the other one...

My username on github is the same

And yeah, some additional data could be helpful. I'm mostly interested in the PAS sensor at the moment, but there are more interesting things for sure.

I wonder if I manage to find out whats wrong with my motor...

 

[casainho]

I wonder if I manage to find out whats wrong with my motor...

Can you wire a throttle and try run the motor with it?

What happens when you try to run? Does it makes any small sound when trying to start?

What if you rotate a bit by hand before try to make it run?

 

[casainho]

My username on github is the same

And yeah, some additional data could be helpful. I'm mostly interested in the PAS sensor at the moment, but there are more interesting things for sure.

Added you to github, you should had received a notification by e-mail.

Why are you interested on PAS?

And by the way, the LCD3 firmware is going forward, right now the needed variables are now stored on EEPROM like assist level and so persist over power cycle of the LCD

 

[hurzhurz]

No, I can't try via throttle...

I can't try with a throttle, but here are some symptoms:
- I can here a humming if the motor it is powered on
- When I measure at the speed sensor plug, I don't get proper 5V, more like 4,4V
- The XH18LCD turns on as soon as I connect the battery (I think it should stay of first)
- The torque value in the data message is strange, e.g. "FF 00"
- I can't really power off the display. It shuts down but stays on and reakts, but the "layout" is broken.
- I can get the motor running if I supply 5V from external via the speed sensor plug:
-- Humming gets louder
-- A bit rotation of the pedals without force is enough to let it spin somewhat fast... maybe because the strange torque value, that is interpreted as "high torque -> high assist"
-- 6kmh function does also somewhat work to let it spin

So, I will probably unmount and open the motor when I have some time...

Added you to github, you should had received a notification by e-mail.

Why are you interested on PAS?

Yes, I received it, thanks!

I'm interested in the PAS because I think the cadence could be a valuable information...

 

[casainho]

So, If you think the LCD is the problem, just run without LCD!!

For my experience, without LCD it runs at max assist level and without the speed sensor it runs without speed limit.

I was looking at Brake signal on the code, I could identify the code but don't understand what is being done.

Good, I also want the cadence value but I think will be hard to understand the code. On my code, I do some cals like 16bits division/sums/multiplication.

 

[hurzhurz]

I forgot to mention, I already tried without the LCD. Didn't chance much.
The weird behavior of it could be a side effect of a broken ground or backfeed problem... have to check...

I had a quick look at the brake code.
I guess $6b is used as a counter to debounce the input and the effective state is saved in $92 bit #4. Maybe you can try this one out?

Yeah, cadence looks hard... I already tried to understand it (that's why I said something about direction detection).
I had the hope it is somewhat similar to the speed...