TSDZ2 EBike wireless standard (like Specialized Turbo Levo) - OpenSource

[Filippods]

Doesn't work in what way? Can you paste the output...

c:\OpenOCD\bin>openocd.exe -f ../share/openocd/scripts/interface/stlink.cfg -f ../share/openocd/scripts/target/nrf52.cfg -c "program TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex verify" -c "exit"
Open On-Chip Debugger 0.10.0 (2020-12-28) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

nRF52 device has a CTRL-AP dedicated to recover the device from AP lock.
A high level adapter (like a ST-Link) you are currently using cannot access
the CTRL-AP so 'nrf52_recover' command will not work.
Do not enable UICR APPROTECT.

Info : clock speed 1000 kHz
Info : STLINK V2J35S7 (API v2) VIDID 0483:3748
Info : Target voltage: 3.208918
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000a80 msp: 0x20000400
** Programming Started **
Info : nRF52840-xxAA(build code: D0) 1024kB Flash, 256kB RAM
Info : Padding image section 0 at 0x00000b00 with 1272 bytes
Info : Flash write discontinued at 0x0002f740, next section at 0x000eb000
Warn : Adding extra erase range, 0x0002f740 .. 0x0002ffff
Error: Error waiting NVMC_READY: generic flash write/erase error (check protection etc...)
Error: Failed to enable read-only operation
Error: Failed to erase reg: 0x4001e508 val: 0x0002e000
Error: Error erasing sector 46
Error: failed erasing sectors 0 to 47
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

c:\OpenOCD\bin>

Not an error I've seen before - and looks like you're using the same version of openocd as I do 20201228 from here https://gnutoolchains.com/arm-eabi/openocd/ Do you have another nrf to try to eliminate a hardware problem?

I have seen errors like that when power is incorrectly applied to the programmer.
The 3.3 v line from the stink should ONLY be connected to vbus on the nrf52840 if there is no other 5v supply being used on vbus.

If you are powering the board with 5v from a dcdc converter or external power supply, please disconnect the stlink 3.3v line.

Then try reprogramming.

When i connect the nrf to stlink i disconnect it from psu.
NRF -> stlink
VBUS -> 3.3V
GND -> GND
SWDIO -> SWDIO
SWDCLIK -> SWCLK

 

[Filippods]

Yes, i use windows.
I've copied the file in the directory /openocd/bin so i've repeated the bootloader flashing... doesn't work.

Doesn't work in what way? Can you paste the output...

c:\OpenOCD\bin>openocd.exe -f ../share/openocd/scripts/interface/stlink.cfg -f ../share/openocd/scripts/target/nrf52.cfg -c "program TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex verify" -c "exit"
Open On-Chip Debugger 0.10.0 (2020-12-28) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

nRF52 device has a CTRL-AP dedicated to recover the device from AP lock.
A high level adapter (like a ST-Link) you are currently using cannot access
the CTRL-AP so 'nrf52_recover' command will not work.
Do not enable UICR APPROTECT.

Info : clock speed 1000 kHz
Info : STLINK V2J35S7 (API v2) VIDID 0483:3748
Info : Target voltage: 3.208918
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000a80 msp: 0x20000400
** Programming Started **
Info : nRF52840-xxAA(build code: D0) 1024kB Flash, 256kB RAM
Info : Padding image section 0 at 0x00000b00 with 1272 bytes
Info : Flash write discontinued at 0x0002f740, next section at 0x000eb000
Warn : Adding extra erase range, 0x0002f740 .. 0x0002ffff
Error: Error waiting NVMC_READY: generic flash write/erase error (check protection etc...)
Error: Failed to enable read-only operation
Error: Failed to erase reg: 0x4001e508 val: 0x0002e000
Error: Error erasing sector 46
Error: failed erasing sectors 0 to 47
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

c:\OpenOCD\bin>

Not an error I've seen before - and looks like you're using the same version of openocd as I do 20201228 from here https://gnutoolchains.com/arm-eabi/openocd/ Do you have another nrf to try to eliminate a hardware problem?

I think the hw is ok cause if i flash the remote firmware it works fine.
If you think is not i will desolder it from ebike to test.

 

[beemac]

c:\OpenOCD\bin>openocd.exe -f ../share/openocd/scripts/interface/stlink.cfg -f ../share/openocd/scripts/target/nrf52.cfg -c "program TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex verify" -c "exit"
Open On-Chip Debugger 0.10.0 (2020-12-28) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

nRF52 device has a CTRL-AP dedicated to recover the device from AP lock.
A high level adapter (like a ST-Link) you are currently using cannot access
the CTRL-AP so 'nrf52_recover' command will not work.
Do not enable UICR APPROTECT.

Info : clock speed 1000 kHz
Info : STLINK V2J35S7 (API v2) VIDID 0483:3748
Info : Target voltage: 3.208918
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000a80 msp: 0x20000400
** Programming Started **
Info : nRF52840-xxAA(build code: D0) 1024kB Flash, 256kB RAM
Info : Padding image section 0 at 0x00000b00 with 1272 bytes
Info : Flash write discontinued at 0x0002f740, next section at 0x000eb000
Warn : Adding extra erase range, 0x0002f740 .. 0x0002ffff
Error: Error waiting NVMC_READY: generic flash write/erase error (check protection etc...)
Error: Failed to enable read-only operation
Error: Failed to erase reg: 0x4001e508 val: 0x0002e000
Error: Error erasing sector 46
Error: failed erasing sectors 0 to 47
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

c:\OpenOCD\bin>

Not an error I've seen before - and looks like you're using the same version of openocd as I do 20201228 from here https://gnutoolchains.com/arm-eabi/openocd/ Do you have another nrf to try to eliminate a hardware problem?

I have seen errors like that when power is incorrectly applied to the programmer.
The 3.3 v line from the stink should ONLY be connected to vbus on the nrf52840 if there is no other 5v supply being used on vbus.

If you are powering the board with 5v from a dcdc converter or external power supply, please disconnect the stlink 3.3v line.

Then try reprogramming.

When i connect the nrf to stlink i disconnect it from psu.
NRF -> stlink
VBUS -> 3.3V
GND -> GND
SWDIO -> SWDIO
SWDCLIK -> SWCLK

I use the 5v from the stlink not 3.3v when flashing the controller. Try that instead?

 

[rananna]

Doesn't work in what way? Can you paste the output...

c:\OpenOCD\bin>openocd.exe -f ../share/openocd/scripts/interface/stlink.cfg -f ../share/openocd/scripts/target/nrf52.cfg -c "program TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex verify" -c "exit"
Open On-Chip Debugger 0.10.0 (2020-12-28) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

nRF52 device has a CTRL-AP dedicated to recover the device from AP lock.
A high level adapter (like a ST-Link) you are currently using cannot access
the CTRL-AP so 'nrf52_recover' command will not work.
Do not enable UICR APPROTECT.

Info : clock speed 1000 kHz
Info : STLINK V2J35S7 (API v2) VIDID 0483:3748
Info : Target voltage: 3.208918
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000a80 msp: 0x20000400
** Programming Started **
Info : nRF52840-xxAA(build code: D0) 1024kB Flash, 256kB RAM
Info : Padding image section 0 at 0x00000b00 with 1272 bytes
Info : Flash write discontinued at 0x0002f740, next section at 0x000eb000
Warn : Adding extra erase range, 0x0002f740 .. 0x0002ffff
Error: Error waiting NVMC_READY: generic flash write/erase error (check protection etc...)
Error: Failed to enable read-only operation
Error: Failed to erase reg: 0x4001e508 val: 0x0002e000
Error: Error erasing sector 46
Error: failed erasing sectors 0 to 47
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

c:\OpenOCD\bin>

Not an error I've seen before - and looks like you're using the same version of openocd as I do 20201228 from here https://gnutoolchains.com/arm-eabi/openocd/ Do you have another nrf to try to eliminate a hardware problem?

I think the hw is ok cause if i flash the remote firmware it works fine.
If you think is not i will desolder it from ebike to test.

Filippods, this is the first evidence of an error we have seen. For sure you should be able to program the nrf52840 without errors. The fact that the bootloader seemed to work with the wireless remote should not let us move from this spot.
We have to get the stink openocd session completing without errors.
As @beemac suggests, please try with a powered 5v connection and disconnect the power pin on the stlink.
Do you have a second stlink you can try?
Please also try on a second nrf52840 as well.
We absolutely need to get a successful openocd session before we move on to testing the firmware.

 

[Filippods]

Bootloader flashing via openocd with openocd.cfg (by beemac)
VBUS -> 5v (stlink)

after that i've flashed fw in DFU mode, no leds blink, no devices found in bt list.

Here the log:

c:\OpenOCD\bin>openocd.exe -f ../share/openocd/scripts/interface/stlink.cfg -f ../share/openocd/scripts/target/nrf52.cfg -c "program TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex verify" -c "exit"
Open On-Chip Debugger 0.10.0 (2020-12-28) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

nRF52 device has a CTRL-AP dedicated to recover the device from AP lock.
A high level adapter (like a ST-Link) you are currently using cannot access
the CTRL-AP so 'nrf52_recover' command will not work.
Do not enable UICR APPROTECT.

Info : clock speed 1000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V2J35S7 (API v2) VIDID 0483:3748
Info : Target voltage: 3.215243
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000a80 msp: 0x20000400
** Programming Started **
Info : nRF52840-xxAA(build code: D0) 1024kB Flash, 256kB RAM
Info : Padding image section 0 at 0x00000b00 with 1272 bytes
Info : Flash write discontinued at 0x0002f740, next section at 0x000eb000
Warn : Adding extra erase range, 0x0002f740 .. 0x0002ffff
Warn : Adding extra erase range, 0x000fc9e8 .. 0x000fcfff
** Programming Finished **
** Verify Started **
** Verified OK **

 

[Filippods]

Bootloader flashing via openocd with openocd.cfg (by beemac)
VBUS -> 5v and 3.3v (external psu)



c:\OpenOCD\bin>openocd.exe -f ../share/openocd/scripts/interface/stlink.cfg -f ../share/openocd/scripts/target/nrf52.cfg -c "program TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex verify" -c "exit"
Open On-Chip Debugger 0.10.0 (2020-12-28) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

nRF52 device has a CTRL-AP dedicated to recover the device from AP lock.
A high level adapter (like a ST-Link) you are currently using cannot access
the CTRL-AP so 'nrf52_recover' command will not work.
Do not enable UICR APPROTECT.

Info : clock speed 1000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V2J35S7 (API v2) VIDID 0483:3748
Info : Target voltage: 3.204734
Warn : UNEXPECTED idcode: 0xf3f00c77
Error: expected 1 of 1: 0x2ba01477
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

 

[Filippods]

Now the log is identical all times: vbus to stlink or psu, 5v or 3.3v, whith and without openocd.cfg

c:\OpenOCD\bin>openocd.exe -f ../share/openocd/scripts/interface/stlink.cfg -f ../share/openocd/scripts/target/nrf52.cfg -c "program TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex verify" -c "exit"
Open On-Chip Debugger 0.10.0 (2020-12-28) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
libusb1 09e75e98b4d9ea7909e8837b7a3f00dda4589dc3
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

nRF52 device has a CTRL-AP dedicated to recover the device from AP lock.
A high level adapter (like a ST-Link) you are currently using cannot access
the CTRL-AP so 'nrf52_recover' command will not work.
Do not enable UICR APPROTECT.

Info : clock speed 1000 kHz
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
Info : STLINK V2J35S7 (API v2) VIDID 0483:3748
Info : Target voltage: 3.214708
Warn : target nrf52.cpu examination failed
Error: jtag status contains invalid mode value - communication failure
Polling target nrf52.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Polling target nrf52.cpu failed, trying to reexamine
Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for nrf52.cpu on 3333
Info : Listening on port 3333 for gdb connections
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00000a80 msp: 0x20000400
** Programming Started **
Error: couldn't open TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

 

[rananna]

VBUS -> 5v and 3.3v (external psu)

Please explain what this means.
Have you powered with both 5V and 3.3V?

 

[Filippods]

Before trying to flash to the other nrf52 i would be sure that this one wasn't broken during this last attempts.

Unfortunately i haven't a 2nd stlink adapter.

 

[Filippods]

VBUS -> 5v and 3.3v (external psu)

Please explain what this means.
Have you powered with both 5V and 3.3V?

first attempt with 5v, second attampt with 3.3v

 

[rananna]

Now the log is identical all times: vbus to stlink or psu, 5v or 3.3v, whith and without openocd.cfg
Error: couldn't open TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

This is failing because the bootloader file is not found.
is it in the openocd folder?

 

[Filippods]

Now the log is identical all times: vbus to stlink or psu, 5v or 3.3v, whith and without openocd.cfg
Error: couldn't open TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

This is failing because the bootloader file is not found.
is it in the openocd folder?

Sorry, i've accidentally renamed it, now WORKS (**Verify OK**) :i've flashed bootloader with openocd (and openocd.cfg)... The nrf52 must be powered on with 5v, in fact when i power on with 3.3v i can't flash with openocd.cfg in the folder.

 

[rananna]

Now the log is identical all times: vbus to stlink or psu, 5v or 3.3v, whith and without openocd.cfg
Error: couldn't open TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

This is failing because the bootloader file is not found.
is it in the openocd folder?

Sorry, i've accidentally renamed it, now WORKS: i've flashed bootloader with openocd (and openocd.cfg)... The nrf52 must be powered on with 5v, in fact when i power on with 3.3v i can't flash with openocd.cfg in the folder.

OK, now what happens when you flash the 0.6.2 firmware using the bootloader?

 

[rananna]

Now the log is identical all times: vbus to stlink or psu, 5v or 3.3v, whith and without openocd.cfg
Error: couldn't open TSDZ2_wireless-bootloader_with_sd-v0.9.0.hex
embedded:startup.tcl:509: Error: ** Programming Failed **
in procedure 'program'
in procedure 'program_error' called at file "embedded:startup.tcl", line 574
at file "embedded:startup.tcl", line 509

This is failing because the bootloader file is not found.
is it in the openocd folder?

Sorry, i've accidentally renamed it, now WORKS: i've flashed bootloader with openocd (and openocd.cfg)... The nrf52 must be powered on with 5v, in fact when i power on with 3.3v i can't flash with openocd.cfg in the folder.

OK, now what happens when you flash the 0.6.2 firmware using the bootloader?
(keep the board powered with 5V.)

 

[Filippods]

This is failing because the bootloader file is not found.
is it in the openocd folder?

Sorry, i've accidentally renamed it, now WORKS: i've flashed bootloader with openocd (and openocd.cfg)... The nrf52 must be powered on with 5v, in fact when i power on with 3.3v i can't flash with openocd.cfg in the folder.

OK, now what happens when you flash the 0.6.2 firmware using the bootloader?
(keep the board powered with 5V.)

The leds still not blinking and the device not appear in bt list

 

[rananna]

Sorry, i've accidentally renamed it, now WORKS: i've flashed bootloader with openocd (and openocd.cfg)... The nrf52 must be powered on with 5v, in fact when i power on with 3.3v i can't flash with openocd.cfg in the folder.

OK, now what happens when you flash the 0.6.2 firmware using the bootloader?
(keep the board powered with 5V.)

The leds still not blinking and the device not appear in bt list

ok, that's where we got to yesterday. let's wait for the new release before going further.
as a last test, you could power down and then power up again and see if anything shows up in the BT list.

 

[Filippods]

OK, now what happens when you flash the 0.6.2 firmware using the bootloader?
(keep the board powered with 5V.)

The leds still not blinking and the device not appear in bt list

ok, that's where we got to yesterday. let's wait for the new release before going further.
as a last test, you could power down and then power up again and see if anything shows up in the BT list.

I've completed the linux procedure, now all works fine, i can connect to TSDZ2.

Now i'm switching this nrf52 with the one soldered to ebike, in this way i can do other tests on windows OS if you need it.

 

[Dimball]

Hi. First of all really excited about this wireless project and good work so far!

I have a question regarding which phone the configuration app can run on. I know the decision to have it run natively on Android was decided early, and to also use the nrfxxxx Bluetooth device. But what stopped you from using a raspberry pi zero for example? You could maybe have used the onboard Bluetooth to talk to the garmin via the ant python libraries, and served the configuration as a web app, which would then be accessible to whatever device running a browser. The pi zero would of course have to run as an access point, but given that it would be powered by the main big battery, it wouldn’t be a problem running it. Maybe I am missing the reason for the current implementation.

The second question is. Would it be possible to setup a raspberry pi zero as a Bluetooth client to your current nrfxxxx Bluetooth device, so that it could receive the json data to serve it out as a web app? (Also being able to set data to it as well)

I mean it is a bit backward, but it would give some options that I was thinking of, I.e make a web app that could also control a switch between throttle and thermostat (given that the pi would be located inside the controller housing for example), which would also control the firmware’s setting for using throttle or thermostat mode at the same time for example.

I hope my ramblings make sense. Either way keep up the great work!

 

[rananna]

OK, now what happens when you flash the 0.6.2 firmware using the bootloader?
(keep the board powered with 5V.)

The leds still not blinking and the device not appear in bt list

ok, that's where we got to yesterday. let's wait for the new release before going further.
as a last test, you could power down and then power up again and see if anything shows up in the BT list.

I've completed the linux procedure, now all works fine, i can connect to TSDZ2.

Now i'm switching this nrf52 with the one soldered to ebike, in this way i can do other tests on windows OS if you need it.

Well isn't that good news!
It seems that there is still something wrong the the mass_erase function of openocd for windows.
We will have to investigate, but in the meantime you got there!

 

[Filippods]

The leds still not blinking and the device not appear in bt list

ok, that's where we got to yesterday. let's wait for the new release before going further.
as a last test, you could power down and then power up again and see if anything shows up in the BT list.

I've completed the linux procedure, now all works fine, i can connect to TSDZ2.

Now i'm switching this nrf52 with the one soldered to ebike, in this way i can do other tests on windows OS if you need it.

Well isn't that good news!
It seems that there is still something wrong the the mass_erase function of openocd for windows.
We will have to investigate, but in the meantime you got there!

I've soldered the working nrf to the ebike and desoldered the naive one, tomorrow im going to test it.
Thank you.

 

[Frzoen]

Yes, connectors are optional but the holes will stay 8)
If the TSDZ2_VIN is just signal pin then there is no need to use BTS4140N as power switch with current limiting. I would use something like SSM6K361NU from Toshiba with additional PTC fuse for safety. They can be directly controlled with STM32 so i suppose that NRF will handle them too (I will dig into datasheet of NRF).

What amperage You're interested in? I can manage to fit in there 1A or 2.5A dc-dc converter without huge bump in price (maybe even lowering it?). But for higher amperage i will have to do test board for myself. I've done few designs with dc-dc converter that I've used in here, so I'm confident about it.

For the leakage voltage I'm pretty sure that this is caused by not having pullup resistor on BTS4140N gate and also not limitng the zero gate current from BSP89. Problem should be solved by adding two resistors like this:

Mind that in this example I've reused the BTS4140N symbol for the BSP89
And also that this circuit by adding pullup resistor to the gate of the BTS4140N will default into ON state.
I'll check datasheets deeper tomorrow

Morning! Ok great, thinking more unless anyone else shouts and wants greater amperage in the regulator probably makes sense to leave it small - as larger means less efficient unless the current is actually being used - and more heat!

Interesting information on the mosfet circuit thanks for your thoughts - Do you think the leakage voltage is going to cause a problem? The basic circuit works and switches the motor on/off ok. I think there will only be appetite to make any changes if we're solving a problem that definitely needs to be solved - anyone else have any thoughts?

Hi after delay

So basically I've came up with this. Minimal setup that from my calculations should work.
There are no parts on the back of the board
Power supply is only 100mA but for NRF-dongle and control of one mosfet it should be plenty.
There is hole to tie the cables to the board if You're not a connector type of a guy.

@beemac tell me if it seems to be ok for You. Then I will finish routing and put it into prototype production.

 

[casainho]

I have a question regarding which phone the configuration app can run on. I know the decision to have it run natively on Android was decided early, and to also use the nrfxxxx Bluetooth device. But what stopped you from using a raspberry pi zero for example? You could maybe have used the onboard Bluetooth to talk to the garmin via the ant python libraries, and served the configuration as a web app, which would then be accessible to whatever device running a browser. The pi zero would of course have to run as an access point, but given that it would be powered by the main big battery, it wouldn’t be a problem running it. Maybe I am missing the reason for the current implementation.

I think raspberry pi does not implement ANT, only Bluetooth. And I think NRF are probably the most popular that implement Bluetooth and ANT.

 

[Dimball]

Ah, ok, then that’s settled then (for raspberry pi natively not supporting ant+). So instead could we use a raspberry pi as a Bluetooth client for the nrfxxxx boards then? (Basically question number two in my previous post)

 

[casainho]

Ah, ok, then that’s settled then (for raspberry pi natively not supporting ant+). So instead could we use a raspberry pi as a Bluetooth client for the nrfxxxx boards then? (Basically question number two in my previous post)

Seems to bring more complexity and I do not see a really need for the final result.

My reference is how other comercial EBikes are doing mainly because I think that companies did study the market and know what most users want. The key seems to be wireless and using the standard of ANT because it includes many cycling and fitness sensors. Bluetooth because there are specifics of each motor that standard will not cover and so a specific app for each EBike brand / model.

 

[casainho]

@rananna, today I tried to build the TSDZ2 wireless firmware from master but I got an error about the bootloader building... and since I had short time, I was not able to build it and so I did not test the firmware. Can you please test to see if it builds ok for you?