emmebrusa / TSDZ2-Smart-EBike-1

TSDZ2 Open Source Firmware adapted to VLCD5-VLCD6-XH18 displays
GNU General Public License v3.0
133 stars 35 forks source link

Motor gets stuck accelerating despite not pedaling #10

Open tobihan opened 3 years ago

tobihan commented 3 years ago

Hi,

I saw some reports about this problem on endless sphere and now I experienced it myself, so I suspect it is a bug in this firmware.

I am using a new TSDZ2 48V 6-pin (no throttle) with VLCD6 display. I first tried the bike for 30 km with the stock firmware without problem. Then I flashed the firmware, commit 64e4f37233c253d1460bd06920f598ab73a0b06a with the following settings and config.h using a Linux computer:

20210509-195351BST.ini.txt config.h.txt

On the first tour with this software after about 10 km the problem occurred that the motor kept running despite not pedaling at all. Changing assist level to 0 did not make the motor stop, only turning off at the display helped. At this moment I was using power assist mode, street mode and the light was on.

Let me know if I can provide any more information or help to debug this issue.

InanZen commented 3 years ago

Happened to me on my first tour (after first flashing the firmware) as well: at about 15km I was at the stop and when I let go of the brakes the bike wanted to go forward. Indeed only turning off the display helped. Before the stop I was using max power assist for a short bit. On another bike it also happened at about 15km after the first firmware flashing. I don't know the specifics because I wasn't driving it. Both bikes are TSDZ2 48V (500W) 8-pin with throttle and VLCD5 display. My bike made 1200+km with stock firmware before and no problems. The other bike was flashed on the new TSDZ2 motor (after ~3km test drive).

tobihan commented 3 years ago

One thing that several people seem to have in common is that it happens only once, after about 10-15 km. Could it be related to a specific odometer or trip counter state?

emmebrusa commented 3 years ago

The problem should be fixed with v20.1C.3 version.

InanZen commented 3 years ago

That is great news. I should mention that it happened to me again (I did re-flash it a few times since it first happened, so I'm not sure if it counts as happening "only once" (after flash) or not). This time it didn't happen after 10-15km (it was much more, but no idea how many). The way it happened was: I was stopped and had power assist lvl 1, I was resting my foot on the pedal with a bit too much weight so the bike wanted to start moving but it couldn't since I was sitting on it. Usually the motor gives up at this point, but this time it might have tried again after giving up once (not really sure if it was only once), and than it went into this error state where the motor keeps going regardless of input.

tobihan commented 3 years ago

That's great! So what was the fix? I had a look at the commit but it wasn't obvious to me and it is not mentioned in the changelog.

emmebrusa commented 3 years ago

In the changelog it is not mentioned because it is a guess. In the ebike_app.c file, there was a bug at line: if (ui8_rx_counter > UART_RX_BUFFER_LEN) which had to be: if (ui8_rx_counter > = UART_RX_BUFFER_LEN). Writing beyond the size of the array to a memory area dedicated to something else has an unpredictable effect. There is no certainty that this was the cause of the problem, but it is very likely.

tobihan commented 3 years ago

I see, thanks for the explanation!

apolselli commented 3 years ago

Hi, since v20.1C.3 is "suspended", could be nice to add the fix of this bug in a v20.1C mantainance branch. Thank you for the great work on this wonderful firmware!

InanZen commented 3 years ago

Just change the line in the "src/ebike_app.c" file, like emmebrusa wrote (but without space between > and = ). As I understand the firmware gets compiled every time you flash so any changes made to those source files will be in the final firmware.

emmebrusa commented 3 years ago

Salve, poiché la v20.1C.3 è "sospesa", potrebbe essere utile aggiungere la correzione di questo bug in un ramo di manutenzione v20.1C. Grazie per l'ottimo lavoro su questo meraviglioso firmware!

Infatti c'è già la versione v20.1C.1 pronta, è la v20.1C con aggiornamenti di sicurezza.

mja43 commented 2 years ago

Hi, I already have a falsh modified version "20.1C.1" with the modification "if(ui8_rx_counter >= UART_RX_BUFFER_LEN)" and I first noticed the problem of engine acceleration without pedaling yesterday. Version 8pin tsdz2 without throttle and barke sensor. When switching from second to third level of assist, the engine started accelerating hard and could not be stopped even by level 0 without assist. I turned off the battery. I had previously driven about 300km on the original firmware and the problem did not occur. On the modified FW it was the 3rd ride after about 25km it happened. I don't even have a brake sensor so I don't know if it would help. Is anyone else having this problem even with version "20.1C.1"?

InanZen commented 2 years ago

Can confirm, it also happened to me once on 20.1C.1 More often there is a problem where there is no motor assist on any level until restart. (this has also been around since previous versions)

mja43 commented 2 years ago

Can confirm, it also happened to me once on 20.1C.1 More often there is a problem where there is no motor assist on any level until restart. (this has also been around since previous versions)

Thank you for the confirmation. Do you have the barke sensor installed? If so will it help stop uncontrolled acceleration? I ride a lot of mountains and this behavior is quite dangerous...

InanZen commented 2 years ago

Yes the brake sensor will stop the motor.

tobihan commented 2 years ago

Since my initial report I left the firmware untouched and never had the issue again.

Yesterday I finally flashed a new firmware, now with the proposed ui8_rx_counter >= UART_RX_BUFFER_LEN change. Today, after about 50 km, I experienced the issue with the motor accelerating again. So I can also confirm that this change does not seem to fix it.

mja43 commented 2 years ago

Hi, I think it has something to do with the the lights on function (as Written by tobihan) . I had the lights on at the time and was checking the engine temperature.

tobihan commented 2 years ago

Yesterday when it happened the lights were off. A pattern I see is that it happens once after flashing and then not again. Did anyone have it happen repeatedly without flashing in between?

mja43 commented 2 years ago

I can confirm, it appeared once after a flash. Since then I have driven about 300 km and the problem has not occurred..

Paulgoodridge commented 2 years ago

My wife’s bike is running 36V with V20.1C.1. She had the problem with acceleration without pedaling the other day on a short ride. She turned the bike off to stop (has brake sensors installed) and started again OK, but it happened at least once more on the same ride. Although she has not experienced the problem again. Flashed 1C.1 about 2 months ago but only happened for the first time about a week ago. I was also talking to a guy today who I installed a 48V motor with 1C.1 and he said the problem had happened to him a couple of times. One thing to note which may be unrelated is that when my wife had the problem and turned off the bike, when she turned it back on again she got an ERROR 2 a few times (which I understand is a torque sensor error, and she did not have her feet on the pedals). After a couple of attempts it turned on OK. It seems strange because she has not had torque sensor problems before or since, only when she had the acceleration problem.

EU-YGAP commented 2 years ago

Hi everybody,

I have tsdz2 36v + xh18 since 8 month and find it perfectible.

I still have stock fw for the moment and feel insecure to flash 1c1 because of this issue of unwanted acceleration (even if I now have brake sensor). All other releases have a notice that asks not to use it...

Would it be safer to buy another screen version and flash both screen and motor with casainhio's or does it come as well with uncertainty?

Thanks for your help...

tobihan commented 2 years ago

For a confident rider who is aware of the issue and with good brakes (which you should have anyway) I don't think it's very dangerous. It rarely happens and your brakes can still slow you down even if the motor is running for a moment (until you turn it off).

But it's up to you to decide if that's safe enough for the way the bike will be used.

tobihan commented 2 years ago

According to @emmebrusa's comment here it seems that the problem only occurs with the opensource firmware for the stock displays:

This is a known, albeit rare, problem. If at level 0-OFF the motor does not stop, it does not depend on the torque sensor or on a wrong calibration. I make a history. The first reports of this problem were made with the versions of marcoq for stock displays. It is a problem that I have never had with my first 4500km motor, neither with the marcoq versions nor with my versions. With the second motor after a few kilometers it happened to me too, I was testing 20.1A. To check if the controller was blocked I had ordered the brake sensors immediately, but this never happened again in 1600km. About a year ago, on this forum the problem was discussed, almost all users who have had it say they have solved it by loading the stock option byte file, I have some doubts about its effectiveness, it is true that in the file option byte up at version 20.1B there was a bug but it was still rewritten correctly by the firmware. However you can try, it could be option byte corrupted. Difficult to understand the cause, I think it depends on the controller, I also read on this forum, about the same problem with the stock firmware. It would be interesting to know if it happened to someone with brake sensors installed and if the motor stops with them.

EU-YGAP commented 2 years ago

For a confident rider who is aware of the issue and with good brakes (which you should have anyway) I don't think it's very dangerous. It rarely happens and your brakes can still slow you down even if the motor is running for a moment (until you turn it off).

But it's up to you to decide if that's safe enough for the way the bike will be used.

Thanks for addressing my concern and for you advice which in the end was my own conclusion as well. I really like the Java tool approach of emmebrusa and the fact that I can keep my low profile XH18.

Nevertheless, I tried to flash but...unsuccessfully.. It seems that I have a V2 controller! https://endless-sphere.com/forums/viewtopic.php?f=30&t=111287

So I will dig around and try to find out what would be the best solution. Changing the controller, changing the screen, keep stock fw...

Thanks again for your help anyway.

tobihan commented 2 years ago

You can check which controller you have by measuring the voltage between the GND and SWIM pins of the speed sensor connector (see https://github.com/OpenSourceEBike/TSDZ2_wiki/wiki/Flash-the-firmware-on-TSDZ2). The old controller should have 5V, the new one 0V. Sometimes flashing just fails and you have to try a few times.

EU-YGAP commented 2 years ago

I have 0V. When flashing did not work I started searching and found out the possibility of a V2 controller. Checking voltage confirmed to me that I do have V2 (in addition to the fact that motor comes from Enerprof earlier this year).

TreadMTB commented 2 years ago

I also had this happen to me on the 20.1c.3 new. It happened to me after I turned on assist with sensor errors, because I didn't have my speed sensor magnet on at the time. It started twitching towards the wall, I had to hold the breaks till I could restart the screen. I have temperature sensor installed in place of the throttle and no brake sensors. I have the 8 pin version. It was barely twitching forward like as if I had a little bit of weight on the pedals only I wasn't even close to touching them.

dzid26 commented 3 months ago

@Thingamajigger Seems like a duplicate issue indeed. Was the speedometer still updating when this happened?

So motor task must be running probably while the duty cycle target command is frozen.

I think, for whatever reason ebike_control_motor() function is not updating the ui8_controller_duty_cycle_target. That big function runs n the background, so perhaps something is hogging all the CPU time and not allowing it to finish. One potential culprit could be the display spamming the UART and causing more calculation, but UART2_IRQHandler(void) is fairly simple so that's rather unlikely.

In any case, this scenario could be protected with a simple software watchdog - a rolling counter in the ebike_control_motor() function - to always check in the motor task if the background calculation is alive.

On top of that there are hardware watchdogs available for this purpose, but I feel no one will have time do anything with them.

emmebrusa commented 3 months ago

Lately I noticed that the UART IRQ priority level was not set. That's why I asked @Thingamajigger if he's using v20.1C.2-update-3.