KT motor controllers -- Flexible OpenSource firmware for BMSBattery S/Kunteng KT motor controllers (0.25kW up to 5kW)

Those windows binaries from your link need cygwin :shock: .
Have you ever worked with cygwin?! Please write an easy to understand tutorial how to make this version of SDCC running with windows.... It took me hours to make it work (for 3.6.0) and I think a "normal" Windows user will despair on it. A 32 bit windows version of 3.7.0 is not available at all :(

I strongly recommend to stay at revision 3.6.0 until a "one-click windows-installer" of revision 3.7.0 is available.

regards
stancecoke
 
stancecoke said:
casainho said:
Please update your master branch as I just update it with my most recent code.

The recent master branch throws an error while compiling with windows. :(

Code:
ebike_app.asm:366: Error: <a> machine specific addressing or addressing mode error
ebike_app.asm:403: Error: <a> machine specific addressing or addressing mode error

Can you fix that? Otherwise I have to start from an earlier commit...
Can you please verify again? maybe from a clean checkout?
Please look and compare with my sdcc version, a make clean and make:

Code:
cas@ubuntu:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ sdcc --version
SDCC : stm8 3.6.0 #9615 (Linux)
published under GNU General Public License (GPL)
cas@ubuntu:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ make -f Makefile_linux clean
Cleaning files...
Done.
cas@ubuntu:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$ make -f Makefile_linux
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_itc.c StdPeriphLib/src/stm8s_itc.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_clk.c StdPeriphLib/src/stm8s_clk.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_iwdg.c StdPeriphLib/src/stm8s_iwdg.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_gpio.c StdPeriphLib/src/stm8s_gpio.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_exti.c StdPeriphLib/src/stm8s_exti.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_uart2.c StdPeriphLib/src/stm8s_uart2.c
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp4. Please contact sdcc authors with source code to reproduce.
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_tim1.c StdPeriphLib/src/stm8s_tim1.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_tim2.c StdPeriphLib/src/stm8s_tim2.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_adc1.c StdPeriphLib/src/stm8s_adc1.c
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp1. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp1. Please contact sdcc authors with source code to reproduce.
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oStdPeriphLib/src/stm8s_flash.c StdPeriphLib/src/stm8s_flash.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -owatchdog.c watchdog.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -ogpio.c gpio.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -outils.c utils.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -ouart.c uart.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oadc.c adc.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -obrake.c brake.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -opas.c pas.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -owheel_speed_sensor.c wheel_speed_sensor.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -otimers.c timers.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -opwm.c pwm.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oeeprom.c eeprom.c
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -omotor.c motor.c
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp146. Please contact sdcc authors with source code to reproduce.
/home/cas/software/stm8-binutils/bin/sdcc -c -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  -oebike_app.c ebike_app.c
ebike_app.c:165: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp44. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp32. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp0. Please contact sdcc authors with source code to reproduce.
Warning: Non-connected liverange found and extended to connected component of the CFG:iTemp7. Please contact sdcc authors with source code to reproduce.
/home/cas/software/stm8-binutils/bin/sdcc -IStdPeriphLib/inc -I.  -mstm8 -Ddouble=float --std-c99 --nolospre --out-fmt-elf --debug  main.c StdPeriphLib/src/stm8s_itc.rel StdPeriphLib/src/stm8s_clk.rel StdPeriphLib/src/stm8s_iwdg.rel StdPeriphLib/src/stm8s_gpio.rel StdPeriphLib/src/stm8s_exti.rel StdPeriphLib/src/stm8s_uart2.rel StdPeriphLib/src/stm8s_tim1.rel StdPeriphLib/src/stm8s_tim2.rel StdPeriphLib/src/stm8s_adc1.rel StdPeriphLib/src/stm8s_flash.rel watchdog.rel gpio.rel utils.rel uart.rel adc.rel brake.rel pas.rel wheel_speed_sensor.rel timers.rel pwm.rel eeprom.rel motor.rel ebike_app.rel
main.c:131: warning 126: unreachable code
stm8-size main.elf -A
main.elf  :
section             size    addr
DATA                 107       1
INITIALIZED          335     108
SSEG                   3     443
HOME                 131   32768
GSINIT                30   32899
GSFINAL                3   32929
CODE               25136   32932
INITIALIZER          335   58068
.debug_line        26719       0
.debug_loc          6600       0
.debug_abbrev       2681       0
.debug_info        31291       0
.debug_pubnames    11646       0
.debug_frame         432       0
Total             105449


stm8-objcopy -O binary -R DATA -R INITIALIZED -R SSEG -R .debug_line -R .debug_loc -R .debug_abbrev -R .debug_info -R .debug_pubnames -R .debug_frame main.elf main.bin
cas@ubuntu:~/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/firmware$
 
casainho said:
Can you please verify again? maybe from a clean checkout?
Please look and compare with my sdcc version, a make clean and make:

Still the same :-(

Code:
C:\Users\admin>sdcc -v
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/h
c08/s08/stm8 3.6.0 #9615 (MINGW64)
published under GNU General Public License (GPL)

Code:
ebike_app.asm:366: Error: <a> machine specific addressing or addressing mode error
ebike_app.asm:403: Error: <a> machine specific addressing or addressing mode error

regards
stancecoke
 
So, since we are both using the same compiler version that we want strategically use, I suggest for you to go commit over commit backwards and try build. When we find the commit the gives problems, I can try look at the code -- I know for instance, that I can't do:
Code:
void function_name (void)
{
  static uint8_t var_name = 0;
}

The compiler fails with static variables that has an initial value... and that makes the current code to has a lot of local variables :-( -- even still fails with SDCC 3.7.0...
 
Or maybe you can try this most recent exe windows version: https://sourceforge.net/projects/sdcc/files/snapshot_builds/x86_64-w64-mingw32-setup/
- here also: https://qa.debian.org/watch/sf.php/sdcc
If they work for you, I can build for me on Linux. Also, if for some reason you decide to build version 3.7.0, we can them share the exe files on our project page, I think it will work.
 
the latest commit that compiles is the "WIP" from 7 days ago. All newer commits throw that error.

I think the problem is caused by the "Motor cool" switch in the ebike_app_state_machine function. If I comment this out, the compiling works.

regards
stancecoke
 
stancecoke said:
the latest commit that compiles is the "WIP" from 7 days ago. All newer commits throw that error.

I think the problem is caused by the "Motor cool" switch in the ebike_app_state_machine function. If I comment this out, the compiling works.
I just see regular and simple code on that commits. Also ebike_app_state_machine wasn't changed on that commits...
Some ideas:
- please make sure your Makefile has the some options for the compiler
- I can't replicate this issue so for me is very hard...
- maybe we are out of RAM memory??
- move to SDCC 3.7 and you build it and then we share the executable for others
- find SDCC 3.7 executable from someone...

I rode today my Q85 geared motor, torque sensor, 24V battery, with current master branch code and it works well, smooth.
 
casainho said:
- maybe we are out of RAM memory??

I think, that's the point. With commenting out some lines, even some certain single line, e.g. line 189

Code:
//ebike_app_set_error (EBIKE_APP_ERROR_06_SHORT_CIRCUIT);

it works.

So I think we have to use some optimizing compiler settings or rework the code and throw away unnecessary things...

But I will stop at this point, as I'm not that familiar with the code in the master branch.

I had a look to the linux/windows makefiles, the compiling options are the same except the -elf vs. -ihx option, but i get the same error with the -elf option. Deleting the --debug option doesn't help also.

regards
stancecoke
 
stancecoke said:
casainho said:
- maybe we are out of RAM memory??

I think, that's the point. With commenting out some lines, even some certain single line, e.g. line 189

Code:
//ebike_app_set_error (EBIKE_APP_ERROR_06_SHORT_CIRCUIT);

it works.

So I think we have to use some optimizing compiler settings or rework the code and throw away unnecessary things...

But I will stop at this point, as I'm not that familiar with the code in the master branch.

I had a look to the linux/windows makefiles, the compiling options are the same except the -elf vs. -ihx option, but i get the same error with the -elf option. Deleting the --debug option doesn't help also.
I must say I don't know how to see ram usage, I already tried but I didn't figured out. Also, strange that you are getting this issue but not me...

I need to know how to clear see ram usage, so we know when we need to reduce the features. I think I will try SDCC 3.7.0 and see if I can get ram usage, initialization of static variables inside functions. This will take time. I am sorry we can't follow together as I think most of the firmware runs very well and with advantages over original one. And this project will make 1 year on day 25 of this month April.
 
Has anybody successfully used the firmware compatible controllers on RC outrunner sensorless motors commonly seen on friction drives? Or maybe on sensored versions of the motor?

Quick searches seem to point to high rpms of these motors being a problem for ebike controllers, is this something that the firmware can overcome?
 
A small hint, when you want to find the commit that broke something, you can use git bisect. This way you don't have to test every single commit, only log2(commits)
 
royco said:
Has anybody successfully used the firmware compatible controllers on RC outrunner sensorless motors commonly seen on friction drives? Or maybe on sensored versions of the motor?

Quick searches seem to point to high rpms of these motors being a problem for ebike controllers, is this something that the firmware can overcome?
Must say I never owned an RC motor or controller, I don't know nothing about that world. But someone told me that yes, they run at very high rpms and because of that they only implement 6 steps/block commutation and not sinewave/FOC like motors of ebikes and motor cycles.
 
stancecoke said:
casainho said:
- maybe we are out of RAM memory??

I think, that's the point. With commenting out some lines, even some certain single line, e.g. line 189

Code:
//ebike_app_set_error (EBIKE_APP_ERROR_06_SHORT_CIRCUIT);

it works.
Maybe not RAM yet, because STM8S105C6T6 has:
- flash: 32kbytes
- RAM: 2kbytes
- EEPROM: 1kbytes

For what I found about SDCC, memory usage can be found on generated map file and RAM are DATA + INITIALIZED sections, and they start at 0 address and goes up to 0x1ba (on my compiled firmware), which is 436 bytes, so we are far from the 2048 bytes limit. Also I think there is other dynamic RAM usage that is stack and it should use RAM as needed when we call functions and I think compiler can't verify that usage because it is dynamic... but again, I think we are far from the 2048 limit.

Stancecoke, can you please verify on your compiled firmware? just to validate my analysis.
 
1N4001 said:
A small hint, when you want to find the commit that broke something, you can use git bisect. This way you don't have to test every single commit, only log2(commits)
Didn't know about that. Thanks!!
 
casainho said:
Stancecoke, can you please verify on your compiled firmware? just to validate my analysis.
I don't know how to do that analysis. I have attached two Hex- and Map-files (Master WIP commit and High Speed Motors fork), perhaps you can analyse them.

regards
stancecoke
 

Attachments

  • Hexfiles.zip
    151 KB · Views: 33
You need to look at main.map file. Will be easier for you to understand.
Sorry I am at home
 
Here is my main.map file:

 
stancecoke said:
casainho said:
Stancecoke, can you please verify on your compiled firmware? just to validate my analysis.
I don't know how to do that analysis. I have attached two Hex- and Map-files (Master WIP commit and High Speed Motors fork), perhaps you can analyse them.
So I looked at the map files of your zip file:
Master: 0x1c7 | 455 bytes
HighSpeedMotor: 0x1fb | 507 bytes

So, master even uses less RAM than HighSpeedMotor. So, the issue should not be because of RAM limitations.
 
casainho said:
So, the issue should not be because of RAM limitations.

Hm, I played around a little how to avoid the error, but I couldn't find a clue. :-(

regards
stancecoke
 
stancecoke said:
casainho said:
So, the issue should not be because of RAM limitations.
Hm, I played around a little how to avoid the error, but I couldn't find a clue. :-(
When I build, I get some warning that compiler gives, but something for compiler developers. Sometimes I think I have luck that the code works... :)
What I mean is that we should use most recent version, I think should be the best. I need to try SDCC 3.7.0. Can't you try a recent version to see if the issue disappears?
 
casainho said:
Can't you try a recent version to see if the issue disappears?

Sorry, I don't want to waste hours struggeling with cygwin again :shock:

A workaround is to comment out line 189 of the ebike_app.c, then it works, why ever and I can try to improve the PAS-processing

Code:
//ebike_app_set_error (EBIKE_APP_ERROR_06_SHORT_CIRCUIT);

regards
stancecoke
 
stancecoke said:
casainho said:
Can't you try a recent version to see if the issue disappears?
Sorry, I don't want to waste hours struggeling with cygwin again :shock:

A workaround is to comment out line 189 of the ebike_app.c, then it works, why ever and I can try to improve the PAS-processing

Code:
//ebike_app_set_error (EBIKE_APP_ERROR_06_SHORT_CIRCUIT);
The big issue is that I don't want to go back on the code, I think it is already most well structured and I see the end of this project soon (or at least I want to). Also because I want to move to TSDZ2 mid drive motors because I think they have great potential as being the cheapest mid drive motors, just like what Kunteng motor controllers are for geared and direct drive hub motors. And seems mid drive motors are also popular and seem to be a better solution for who rides on hills. And they use also same STM8S105 as Kunteng motor controllers, but the version with 16kbytes flash memory (half of the size of Kunteng motor controllers, although I think they don't implement sinewave/FOC due to high motor RPM needs, so, they need only half of flash memory).

So, seems I am the only one capable to build the firmware because for some reason the SDDC version on Linux builds ok the current firmware version. This is sad for every other users and seems they use Windows and so they will not be able to build the firmware anymore.
 
OK, no problem. If anyone want's to use the improved PAS- and regen- functions, he can switch to the High Speed Motor fork :wink:

I'm looking forward to the new project with the TSDZ2 :)

regards
stancecoke
 
stancecoke said:
Oh, I hope you weren't injured when the crank broke off....

I found a bug now: In the main.h you define

Code:
// *************************************************************************** //
// Throotle and PAS

#define EBIKE_THROTTLE_TYPE_THROTTLE_PAS		1
#define EBIKE_THROTTLE_TYPE_TORQUE_SENSOR		2
// *************************************************************************** //

with this, the #if statements in the ebike_app.c don't work properly....
I commented out these entries in the main.h, now the right #if statements are active in eclipse (not greyed in the code).
I verified with the following changes to a piece of code:
Code:
#if (EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_THROTTLE_PAS)
  // map throttle value from 0 up to 255 to global variable: ui8_throttle_value
  // setup ui8_is_throttle_released flag
  throttle_read ();
#error "EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_THROTTLE_PAS"
#elif (EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_TORQUE_SENSOR)
  torque_sensor_throttle_read ();
#error "EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_TORQUE_SENSOR"
#else
#error "none defined"
#endif

and I got the expected error while testing:
- #error "EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_THROTTLE_PAS"
- #error "EBIKE_THROTTLE_TYPE == EBIKE_THROTTLE_TYPE_TORQUE_SENSOR"
- #error "none defined"

Maybe you did some mistake, I hope.
 
If I set

Code:
#define EBIKE_THROTTLE_TYPE EBIKE_THROTTLE_TYPE_THROTTLE_PAS

in the config.h, this setting is ignored in the ebike_app.c, see eclipse screenshot.

If I comment out the two lines in the main.h, the settings in the ebike_app.c are OK....

regards
stancecoke
 

Attachments

  • right ifdefs.PNG
    right ifdefs.PNG
    9.9 KB · Views: 1,722
  • wrong ifdefs.PNG
    wrong ifdefs.PNG
    10.2 KB · Views: 1,722
Back
Top