EasyDIY OpenSource display for EVs: TSDZ2 and Bafang M500/M600 EBike motors

[casainho]

I just bought a Bafang M500 for a new MTB EBike I will build. The display that comes with motor is a black / while only and kind of small. The visual interface is not much advanced compared to the older black white displays:

 

[gfmoore]

I think this is the pinout, but awaiting some push buttons to check and test.





I think that 1 is green (+ up), 2 is yellow (- down), 3 (common) is black an 4 is red (power)

I am hoping to arrange buttons around the hood on the left hand which controlled the now defunct middle derailleur.



Man it was fiddly trying to do this.

doh, forgot about image size.

 

[kaziq]

Hi, recently I started to build this display, and I ran into a problem. I have the nRF module and the DC-DC converter connected only for now. There is 5V on VBUS, and 3.0V on VDD_out (it's the same if I connect 5V from a lab supply to VBUS, so perhaps it's normal).

The problem is that I don't see any signals on the SPI bus, TSDZ2_RX and on P1.00 pin. I checked with an oscilloscope and there is nothing. U have flashed bootloader, the nRF board shows up in the nRF Connect app, I have flashed the 1.3_SPI firmware through DFU. I can only see the pulses on the keypad pins, positive pulses on the POWER pin, and negative pulses on the UP/DOWN pins, so the module seems to be working. But on the other pins there is nothing (low logic level on all of them). I tried soldering a 2.2k pullup resistor to the SCL pin, but the level just goes high, and still no waveform - like the pin was not configured at all.

I didn't try to connect the display or the motor, but I don't see how that could help, since the motor enable pin (P1.00) is dead too.

I tried to short the POWER button pin to GND for a short time and for a long time - it didn't change anything.

How can I verify the software actually works? The red led on the module is constantly lit.

 

[casainho]

Hi, recently I started to build this display, and I ran into a problem. I have the nRF module and the DC-DC converter connected only for now. There is 5V on VBUS, and 3.0V on VDD_out (it's the same if I connect 5V from a lab supply to VBUS, so perhaps it's normal).

The problem is that I don't see any signals on the SPI bus, TSDZ2_RX and on P1.00 pin. I checked with an oscilloscope and there is nothing. U have flashed bootloader, the nRF board shows up in the nRF Connect app, I have flashed the 1.3_SPI firmware through DFU. I can only see the pulses on the keypad pins, positive pulses on the POWER pin, and negative pulses on the UP/DOWN pins, so the module seems to be working. But on the other pins there is nothing (low logic level on all of them). I tried soldering a 2.2k pullup resistor to the SCL pin, but the level just goes high, and still no waveform - like the pin was not configured at all.

I didn't try to connect the display or the motor, but I don't see how that could help, since the motor enable pin (P1.00) is dead too.

I tried to short the POWER button pin to GND for a short time and for a long time - it didn't change anything.

How can I verify the software actually works? The red led on the module is constantly lit.

I think the firmware will for instance, block at startup, if can not initialize the display. The best would be for you to use the debugger and run the code step by step.

At least you could add to firmware some pin on/off to follow with oscilloscope the initialization sequence, because at the end, you should see image on the display / SPI data on the lines.

 

[gfmoore]

I think this is the pinout, but awaiting some push buttons to check and test.

[images]

I think that 1 is green (+ up), 2 is yellow (- down), 3 (common) is black an 4 is red (power)

I am hoping to arrange buttons around the hood on the left hand which controlled the now defunct middle derailleur.



Man it was fiddly trying to do this.

doh, forgot about image size.

I can confirm that this all worked fine

 

[casainho]

I moved to the Bafang M500 motor, which is very different than TSDZ2, it uses CAN communication instead of UART. The way to turn on/off the motor controller is also different.

Here is the adapted schematic. I am really happy to reuse this display!!

 

[kaziq]

I think the firmware will for instance, block at startup, if can not initialize the display. The best would be for you to use the debugger and run the code step by step.

At least you could add to firmware some pin on/off to follow with oscilloscope the initialization sequence, because at the end, you should see image on the display / SPI data on the lines.

I would like to try to debug the firmware, but I don't know how. I have very little experience with Visual Studio (none with the newest version).
I managed to install VS Code, install the nRF recommended addons, and windows-arm-none-eabi.
In the nRF for VSCode configuration I need to select the nRF Connect SDK, but it won't accept the nRF_SDK_16.0.0 directory from the firmware release ("invalid NCS installation").
When I try to add the application to the NRF Connect, I'm getting the message: "The directory "(...)EV_Display_Bluetooth_Ant-0.10.0\firmware\display does not contain a prj.conf file."
Also when I run VSCode I get the message "Coudn't find Zephyr root. Source: nRF device tree".

How can I get this to work?

 

[casainho]

I think the firmware will for instance, block at startup, if can not initialize the display. The best would be for you to use the debugger and run the code step by step.

At least you could add to firmware some pin on/off to follow with oscilloscope the initialization sequence, because at the end, you should see image on the display / SPI data on the lines.

I would like to try to debug the firmware, but I don't know how. I have very little experience with Visual Studio (none with the newest version).
I managed to install VS Code, install the nRF recommended addons, and windows-arm-none-eabi.
In the nRF for VSCode configuration I need to select the nRF Connect SDK, but it won't accept the nRF_SDK_16.0.0 directory from the firmware release ("invalid NCS installation").
When I try to add the application to the NRF Connect, I'm getting the message: "The directory "(...)EV_Display_Bluetooth_Ant-0.10.0\firmware\display does not contain a prj.conf file."
Also when I run VSCode I get the message "Coudn't find Zephyr root. Source: nRF device tree".

How can I get this to work?

Give me some time (1 or 2 days) and I will write some notes with screenshots on how I do it.

 

[kaziq]

Give me some time (1 or 2 days) and I will write some notes with screenshots on how I do it.

Thank you.

 

[casainho]

Give me some time (1 or 2 days) and I will write some notes with screenshots on how I do it.

Thank you.

See here the page Configure Code Studio IDE for firmware development, flash and debug: https://opensourceebike.github.io/development/

 

[kaziq]

Thank you for the guide. I tried to follow it on Windows, but got stuck on task reported errors like "Error: the task 'build' neither specifies a command nor a dependsOn property. The task will be ignored."

So I set up an Ubuntu VM, and I have some remarks to improve your guide for people installing this from scratch:
1. 'buld' task complains about missing make command, add 'sudo apt install make'.
2. Running the 'build' task results in a buch of errors like "./ssd1306_driver/SSD1306.c:238:2: error: #error MUST define DISPLAY_I2C or DISPLAY_SPI". I suppose one needs to uncomment #define DEVELOPMENT in main.h, and update the #ifdef DEVELOPMENT clause to match his diaplay.
3. "make[1]: nrfutil: Command not found". I found and installed nrfutil for myself, but I don't think my method is recommendable. An official instruction would be welcome.

I managed to solve these problems and compile the firmware, but I have trouble debugging it. When I start OpenOCD task I get this:

Info : No device selected, using first device.
Error: No J-Link device found.

I am trying to use ST-link dongle. I have installed the udev rules as per your guide.
Perhaps it's a VM issue, but the ST-link seems to be detected by the kernel. Here is dmesg output:

[  572.326821] usb 1-2: new full-speed USB device number 3 using ohci-pci
[  572.887619] usb 1-2: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
[  572.887629] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  572.887632] usb 1-2: Product: STM32 STLink
[  572.887634] usb 1-2: Manufacturer: STMicroelectronics
[  572.887636] usb 1-2: SerialNumber: 8

I also tried flashing the compilked firmware through DFU, but the result is the same (no waveforms on SPI). Next I will try to add some line toggle to find out what the program does, but It would be much easier if I could run it through the debugger.

 

[casainho]

Thank you for the guide. I tried to follow it on Windows, but got stuck on task reported errors like "Error: the task 'build' neither specifies a command nor a dependsOn property. The task will be ignored."

So I set up an Ubuntu VM, and I have some remarks to improve your guide for people installing this from scratch:
1. 'buld' task complains about missing make command, add 'sudo apt install make'.
2. Running the 'build' task results in a buch of errors like "./ssd1306_driver/SSD1306.c:238:2: error: #error MUST define DISPLAY_I2C or DISPLAY_SPI". I suppose one needs to uncomment #define DEVELOPMENT in main.h, and update the #ifdef DEVELOPMENT clause to match his diaplay.
3. "make[1]: nrfutil: Command not found". I found and installed nrfutil for myself, but I don't think my method is recommendable. An official instruction would be welcome.

I managed to solve these problems and compile the firmware, but I have trouble debugging it. When I start OpenOCD task I get this:

Info : No device selected, using first device.
Error: No J-Link device found.

I am trying to use ST-link dongle. I have installed the udev rules as per your guide.
Perhaps it's a VM issue, but the ST-link seems to be detected by the kernel. Here is dmesg output:

[  572.326821] usb 1-2: new full-speed USB device number 3 using ohci-pci
[  572.887619] usb 1-2: New USB device found, idVendor=0483, idProduct=3748, bcdDevice= 1.00
[  572.887629] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  572.887632] usb 1-2: Product: STM32 STLink
[  572.887634] usb 1-2: Manufacturer: STMicroelectronics
[  572.887636] usb 1-2: SerialNumber: 8

I also tried flashing the compilked firmware through DFU, but the result is the same (no waveforms on SPI). Next I will try to add some line toggle to find out what the program does, but It would be much easier if I could run it through the debugger.

You did very well!! Can you improve the documentation with all the notes (that I clearly understand, but as I installed that tools on already my PC, I did not saw it). For instance, nrfutill I install with pip3 install nrfutil.
Can you improve the documentation and make a pull request? then I will accept that changes.

Your only small issue is that you started the debug for JLink and not for STLinkV2 - on this project I only use JLink!! Grab here on this other project, the configurations for STLinkV2: https://github.com/EBiCS/EBiCS_motor_FOC/blob/main/example/.vscode/tasks.json
You can also add it and submit a pull request.

Yes, the build should be configured to call "make -DDEVELOPMENT"...

 

[kaziq]

You did very well!! Can you improve the documentation with all the notes (that I clearly understand, but as I installed that tools on already my PC, I did not saw it). For instance, nrfutill I install with pip3 install nrfutil.
Can you improve the documentation and make a pull request? then I will accept that changes.

Your only small issue is that you started the debug for JLink and not for STLinkV2 - on this project I only use JLink!! Grab here on this other project, the configurations for STLinkV2: https://github.com/EBiCS/EBiCS_motor_FOC/blob/main/example/.vscode/tasks.json
You can also add it and submit a pull request.

Yes, the build should be configured to call "make -DDEVELOPMENT"...

That's what I supposed, that you don't remember all the steps, as you already have the environment set up. My intention was to fill the gaps

You mentioned STLink-V2 udev rule update, so I thought it would run with STLink as well. I guess that part needs to be improved too

By the way, I've heard that you could convert STLink to Jlink just by updating the firmware in the STLink built into the ST Nucleo boards: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
I remember trying it a long time ago, but gave up because Jlink didn't support the built-in UART port, that I frequently use for debugging. Do you think the cheap STLink dongles could be converted too and would be more stable with the nRF development?

I will improve the documentation once debugging works for me. I'm out of my home right now, and didn't take the hardware with me, so I test the when I'm back.

 

[casainho]

I will improve the documentation once debugging works for me. I'm out of my home right now, and didn't take the hardware with me, so I test the when I'm back.

What I prefer on JLink is the hardware that seems more robust. On the software side, I see no differences.

 

[afzal]

By the way, I've heard that you could convert STLink to Jlink just by updating the firmware in the STLink built into the ST Nucleo boards: https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/
I remember trying it a long time ago, but gave up because Jlink didn't support the built-in UART port, that I frequently use for debugging. Do you think the cheap STLink dongles could be converted too and would be more stable with the nRF development?

Standalone ST Link original or cheap cannot be converted to Jlink.

There is a provision in discovery board to disconnect target processor from on-board ST Link & connect it to an external target, but once Jlink'ed that too will not work, only the on-board target can then be connected.

 

[kaziq]

Your only small issue is that you started the debug for JLink and not for STLinkV2 - on this project I only use JLink!! Grab here on this other project, the configurations for STLinkV2: https://github.com/EBiCS/EBiCS_motor_FOC/blob/main/example/.vscode/tasks.json
You can also add it and submit a pull request.

I managed to add the STLink OpenOCD task (the one from your link needs to be modified to use the original configuration files, instead of the ones from the source, otherwise OpenOCD complains about invalid commands, perhaps some OpenOCD version mismatch).

Bu then OpenOCD will not connect to the nRF dongle (unable to connect to target). I even tried to flash the bootloader again from Windows using the same dongle - it doesn't work. Checked the dongle with an ST CPU - works fine.

There are some waveforms on the SWDIO and SWDCLK lines, but I can't tell if they are correct. I tried to hold the Reset button on the nRF, but it didn't help, however the SWDIO waveform was slightly different - there were some dents after some pulse groups, like nRF tried to drive the line down, but couldn't for a reason.

Anyone tried to flash the nRF bootloader with the STLinkV2 dongle, and could tell if that should work or not?

If not, then debugging will not work too, but that is strange. Even if the lines are reused as GPIO in the software, it should still work under reset.

 

[casainho]

If not, then debugging will not work too, but that is strange. Even if the lines are reused as GPIO in the software, it should still work under reset.

I just can say that I flashed many times and on good maybe different 20 boards and works well. BUT one or two boards stopped to respond but anyway I did some short with them.

I would recommend you to test with another board!!

It is just 4 wires to connect/solder: GND and 5/3.3V from the STLink and the other 2. On a new board without anything more connected, it must work!!

Look, you can try the same on a board with STM32 like the famous Bluepill, it must work!!

 

[kaziq]

I just can say that I flashed many times and on good maybe different 20 boards and works well. BUT one or two boards stopped to respond but anyway I did some short with them.

I would recommend you to test with another board!!

I don't have another board. You know, I only wanted to build a nice display for my TSDZ2, didn't expect it to be such a hard time

I found out I had broken the SWDCLK trace when cutting off the USB plug part of the nRF board. I fixed it and debugging now seems to work fine. But I have problem with flashing. I see this in the terminal:

invalid command name "nrf5"
invalid subcommand "write_image erase /home/kazik/EV_Display_Bluetooth_Ant/firmware/display/_build/display_firmware_combined.hex"

I had similar problem before, when OpenOCD have complained about the 'adapter driver hla' line from the stlink-v2.cfg file from your code. I found out that OpenOCD has some command incompatibility between different versions - the official 0.10.0 (which I have installed) doesn't understand 'adapter' for example. I have fixed this by using the stlink-v2.cfg and nrf52.cfg from the OpenOCD installed on my system.
Now the problem just moved to another place. Could you fix this please? I don't know enough about OpenOCD to do it for myself. I don't even know which version of OpenOCD I should use or how to install it instead of the official one.

For the main issue. I am not 100% sure, but it looks like the software lands in the app_error_fault_handler function when calling eeprom_init() in the main, because the fds_init in epprom.c on line 271 returns FDS_ERR_NO_PAGES. Could you look into that?

Perhaps the nRF chip needs to have the eeprom initialized somehow before the program can run, and you didn't experience this problem because your board has been initialized before.

 

[casainho]

For the main issue. I am not 100% sure, but it looks like the software lands in the app_error_fault_handler function when calling eeprom_init() in the main, because the fds_init in epprom.c on line 271 returns FDS_ERR_NO_PAGES. Could you look into that?

Perhaps the nRF chip needs to have the eeprom initialized somehow before the program can run, and you didn't experience this problem because your board has been initialized before.

I am not on computer.

You can see on OpenOCD if there are commands to fully erase the flash memory! The eeprom uses the flash memory. So you should make sure it is fully flashed.

On OpenOCD terminal, you can execute commands to write any value on all the memory, like maybe all 0 or all 1.

Anyway, an OpenOCD command to fully erase the memory should the the solution.

 

[kaziq]

You can see on OpenOCD if there are commands to fully erase the flash memory! The eeprom uses the flash memory. So you should make sure it is fully flashed.

I tried to do the full erase on Windows (using the same method I flashed the bootloader with), but the command was failing ('failed to erase sector 0'), then I tried to do the same from Linux VM, but looks like the OpenOCD 0.10.0 doesn't even have the nRF support ('invalid command nrf52'). Then I struggled to update the OpenOCD on Linux to 0.11.0 (it's not in the Ubuntu repo), and after I managed to do that it turned out it had the similar problems as 0.10.0, but more. At least it understood the erase and program commands, but the erase failed every time on different sectors. Then I tried to use the Nucleo STLink, and while it worked on Windows, Linux stopped detecting it at all. Same when I switched back to the dongle.

Then I tried the dongle with Windows again, and it started to work fine somehow. It managed to do the full erase, so I flashed the bootloader, and did the RFU again, and this time the software works fine, woohooo! I have the blue/red led blinking, and there are waveforms on the display lines. Tomorrow I will be able to continue building the display.

Some remarks and observations:
1. I didn't manage to flash the software from the VSCode, but I did some notes how to improve your guide (including OpenOCD 0.11.0 installation). I will commit it for others' benefit, when I have some time.
2. I guess my problem raised because there was some data in the nRF's flash when I flashed the bootloader, and flashing itself didn't erase the remaining memory. It would be nice to add the erase step to the bootloader flashing guide.
3. The software could be more informative in this area. Let's imagine there is some byte error in the flash coming for example from power disconnection in mid-write. The software will hang forever on the next run, and the user will be left with bricked sealed display. He won't even have any indication what happened, because the screen is blank. I think the software should erase the flash if it cannot initialize it properly to avoid such lockup. If this means erasing the user settings, that's still better than bricked display.
4. The display should initialize first, and show such errors, so the user will know what is happening. I see there are log prints in the code, but I don't know if they can be viewed without access to the pins?

Thanks for the help, and for great project!

 

[casainho]

but looks like the OpenOCD 0.10.0 doesn't even have the nRF support ('invalid command nrf52').

The guide should have an section about using using OpenOCD terminal, because you can get an help and see and test every command available - I think the command is now "nrf5 erase" or something, that works for NRF51, 52, etc.
[/quote]

At least it understood the erase and program commands, but the erase failed every time on different sectors.

There are commands to unlock specific sectors, if they are locked, can't be erased.

Then I tried the dongle with Windows again, and it started to work fine somehow. It managed to do the full erase, so I flashed the bootloader, and did the RFU again, and this time the software works fine, woohooo! I have the blue/red led blinking, and there are waveforms on the display lines.

So, in end the the issue was only because incorrect erase before flashing the firmware.

Some remarks and observations:
1. I didn't manage to flash the software from the VSCode, but I did some notes how to improve your guide (including OpenOCD 0.11.0 installation). I will commit it for others' benefit, when I have some time.
2. I guess my problem raised because there was some data in the nRF's flash when I flashed the bootloader, and flashing itself didn't erase the remaining memory. It would be nice to add the erase step to the bootloader flashing guide.
3. The software could be more informative in this area. Let's imagine there is some byte error in the flash coming for example from power disconnection in mid-write. The software will hang forever on the next run, and the user will be left with bricked sealed display. He won't even have any indication what happened, because the screen is blank. I think the software should erase the flash if it cannot initialize it properly to avoid such lockup. If this means erasing the user settings, that's still better than bricked display.
4. The display should initialize first, and show such errors, so the user will know what is happening. I see there are log prints in the code, but I don't know if they can be viewed without access to the pins?

Thanks for the help, and for great project!

I agree with every point.

If you can, please improve the documentation that is here: https://github.com/OpenSourceEBike/OpenSourceEBike.github.io/blob/main/development/development-flash_and_debug_firmware.md

And we are starting developing for the Bafang M500/M600, and I wish there was a way the code could be shared easily between the projects...

I will take your suggestions and see if I can improve next time I will work on this firmware.

I hope to see pictures of your display!!

 

[kaziq]

So, in end the the issue was only because incorrect erase before flashing the firmware.

There was no erase before flashing the firmware. I have followed this instruction: https://opensourceebike.github.io/windows.html and it doesn't mention erase. I didn't know it was necessary.

I hope to see pictures of your display!!

Okay
I used a much cheaper DC converter (a bit larger and needs a capacitor replacement), so will post the pictures before assembly too.

 

[kaziq]

Hi again, I updated the manual, and would like to commit the changes to your repo. How do I do that? (I'm not well-versed in git). I committed my changes to my local branch, what next? For a pull request I would have to push my branch to an online repo, right? I tried to push the branch to your repo with

git push . HEAD

but the answer was

Everything up-to-date

 

[casainho]

Hi again, I updated the manual, and would like to commit the changes to your repo. How do I do that? (I'm not well-versed in git). I committed my changes to my local branch, what next? For a pull request I would have to push my branch to an online repo, right? I tried to push the branch to your repo with

git push . HEAD

but the answer was

Everything up-to-date

Thanks.

What repository? Please give the address of it.

You need to make a pull request. Please see on google on how to do it on github repositories.

 

[kaziq]

The official one: https://github.com/OpenSourceEBike/OpenSourceEBike.github.io