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

[casainho]

So please add the new characteristic specifically to set the bootloader startup flag and reset the system, like
what is currently done to change the ANT ID.

To keep it simple for the user I propose we eliminate the new characteristic and use the existing ANT ID characteristic to put into DFU mode. For example, entering an ANT ID of 999 will cause the board to reboot into DFU mode.

Good idea.

 

[rananna]

I got it working 2 times in 10 times. It is confused the process. Why not go back to that idea of writing the enter bootloader flag and reset, just like we do for ANT ID?
When I have the bootloader DFU, then everything works and is easy to follow.

I am working on using the ant ID to get into DFU mode, and I am now having similar problems to you with the board not resetting and hanging up instead of going into the bootloader.
I think I have tracked the problem down to the function NVIC_System_reset() not working properly all the time in debug mode.
When I unplug from the debugger the board works fine.
As a test, could you please try the buttonless DFU firmware with no debugger attached?
There are several reports on Nordic of this issue.
ie:
https://community.st.com/s/question/0D50X00009XkbSaSAJ/nvicsystemreset-not-working

 

[casainho]

I got it working 2 times in 10 times. It is confused the process. Why not go back to that idea of writing the enter bootloader flag and reset, just like we do for ANT ID?
When I have the bootloader DFU, then everything works and is easy to follow.

I am working on using the ant ID to get into DFU mode, and I am now having similar problems to you with the board not resetting and hanging up instead of going into the bootloader.
I think I have tracked the problem down to the function NVIC_System_reset() not working properly all the time in debug mode.
When I unplug from the debugger the board works fine.
As a test, could you please try the buttonless DFU firmware with no debugger attached?
There are several reports on Nordic of this issue.
ie:
https://community.st.com/s/question/0D50X00009XkbSaSAJ/nvicsystemreset-not-working

I just tested a few times and yes, seems to work correctly if I keep the STLinkV2 unconnected from computer.
Good!! I am happy as it is now!!

But there is still an issue: long button press at startup do not start the bootloader (nor even a simple button press). Can you please check this?

 

[rananna]

I just tested a few times and yes, seems to work correctly if I keep the STLinkV2 unconnected from computer.

Good news!

Good!! I am happy as it is now!!

But NOW I'm not happy - I think I prefer the simplicity of the 0x99 ANT_ID to enter bootloader.
I have eliminated the extra characteristics and have just about finished testing this mode of entering the bootloader, and so far it seems to work fine as long as you are not debugging.

But there is still an issue: long button press at startup do not start the bootloader (nor even a simple button press). Can you please check this?

I have also implemented the button push for the bootloader firmware

I will finish testing both and will push updates later today.

 

[casainho]

But NOW I'm not happy - I think I prefer the simplicity of the 0x99 ANT_ID to enter bootloader.
I have eliminated the extra characteristics and have just about finished testing this mode of entering the bootloader, and so far it seems to work fine as long as you are not debugging.

For me is ok one way or the other.

I will be able to test tomorrow your changes.

Please make the button long press of 10 seconds and check at first 1 second if is released already.
We should use the button for TSDZ2 board to start it, just like is done on wireless remote with the other buttons.

 

[rananna]

Please make the button long press of 10 seconds and check at first 1 second if is released already.
We should use the button for TSDZ2 board to start it, just like is done on wireless remote with the other buttons.

I didn't see this post before I pushed the bootloader change.
Basically all it does now is check to see if the button is pushed when the bootloader starts, and enters DFU if that is the case.
I will change it so that it will go into DFU with:
1. a button push at startup
2. Go into dfu with a 10 second button push at any time.
Does that sound right?
I also pushed an update to TSDZ2 wireless to go into DFU mode with 0x99 ANT_ID.
Works great on my end. Please test and let me know.
I will change the wireless remote to work the same if you find no issues.
Please read the comments in main.c where the change is made.

 

[casainho]

Please make the button long press of 10 seconds and check at first 1 second if is released already.
We should use the button for TSDZ2 board to start it, just like is done on wireless remote with the other buttons.

I didn't see this post before I pushed the bootloader change.
Basically all it does now is check to see if the button is pushed when the bootloader starts, and enters DFU if that is the case.
I will change it so that it will go into DFU with:
1. a button push at startup
2. Go into dfu with a 10 second button push at any time.
Does that sound right?
I also pushed an update to TSDZ2 wireless to go into DFU mode with 0x99 ANT_ID.
Works great on my end. Please test and let me know.
I will change the wireless remote to work the same if you find no issues.
Please read the comments in main.c where the change is made.

The button does not work to enter bootloader. I even did some corrections to the code but still does not work. Maybe the issue is because this button is the P0.18 that is also the reset button - I did the changes for it to work as IO pin...

Maybe you can test on the remote with some other button other then the reset button.

So, I think the enter button for bootloader can be the same code for both TSDZ2 wireless board and remote, except of using different pin. Maybe on remote we can check only one pin / button instead of all buttons, like this:
1. system boots and timer app is set for 1 second
2. at 1 second timer app event, the pin is checked: if button disable, jump to user firmware and if not, start app timer for 9 seconds
3. at 9 seconds timer app event, the pin is checked: if button disable, jump to user firmware and if not start the bootloader.

Can you try to do this? I hope you will agree with this sequence.

 

[casainho]

I also pushed an update to TSDZ2 wireless to go into DFU mode with 0x99 ANT_ID.
Works great on my end. Please test and let me know.
I will change the wireless remote to work the same if you find no issues.
Please read the comments in main.c where the change is made.

After your changes, I updated the code and now both changing ANT ID and enter bootloader works well!! See my last commit
diff before update the wireless remote code.

 

[casainho]

@stancecoke alerted me that he did a release of his app and I tested to see if the Bluetooth on my phone was working or not to see my Bluetooth devices - and yes, it seems to work!!

 

[rananna]

I also pushed an update to TSDZ2 wireless to go into DFU mode with 0x99 ANT_ID.
Works great on my end. Please test and let me know.
I will change the wireless remote to work the same if you find no issues.
Please read the comments in main.c where the change is made.

After your changes, I updated the code and now both changing ANT ID and enter bootloader works well!! See my last commit
diff before update the wireless remote code.

Yes, the enter_bootloader flag is an improvement.

 

[rananna]

The button does not work to enter bootloader. I even did some corrections to the code but still does not work. Maybe the issue is because this button is the P0.18 that is also the reset button - I did the changes for it to work as IO pin...

I will work on this.
However, the board button IS working in the bootloader firmware. To test this, hold the board button down during a reset. (Like when power is applied) This is the point when the mbr passes control to the bootloader to load the app, and it is at this time that it catches the button press. This change was made in the latest pr for bootloader

So, I think the enter button for bootloader can be the same code for both TSDZ2 wireless board and remote, except of using different pin. Maybe on remote we can check only one pin / button instead of all buttons, like this:
1. system boots and timer app is set for 1 second
2. at 1 second timer app event, the pin is checked: if button disable, jump to user firmware and if not, start app timer for 9 seconds
3. at 9 seconds timer app event, the pin is checked: if button disable, jump to user firmware and if not start the bootloader.

Can you try to do this? I hope you will agree with this sequence.

The way it is currently working on the remote is to go to bootloader if any key is held down for 10s or more.
This is pretty straightforward.
Also, with the board button working in the bootloader firmware as a failsafe against app firmware potential issues, this is probably OK.

In summary, I propose that bootloader can be entered by either a
1. 10 s push of either the board button on tsdz2_wireless or any remote pad key on ebike remote control (I am pretty sure I can fix the board button issue with tsdz2_wireless)
Or
2. Board button push during power on in both firmwares
What do you think?

 

[casainho]

The button does not work to enter bootloader. I even did some corrections to the code but still does not work. Maybe the issue is because this button is the P0.18 that is also the reset button - I did the changes for it to work as IO pin...

I will work on this.
However, the board button IS working in the bootloader firmware. To test this, hold the board button down during a reset. (Like when power is applied) This is the point when the mbr passes control to the bootloader to load the app, and it is at this time that it catches the button press. This change was made in the latest pr for bootloader

I tested again and even tried to debug, but debug does not work because code is built with OPT = -O3 and if I change to -O0, then the flash memory is not enough.

I tested a few times, with debugger connected and not connected, it simple does not work on my board.

So, I think the enter button for bootloader can be the same code for both TSDZ2 wireless board and remote, except of using different pin. Maybe on remote we can check only one pin / button instead of all buttons, like this:
1. system boots and timer app is set for 1 second
2. at 1 second timer app event, the pin is checked: if button disable, jump to user firmware and if not, start app timer for 9 seconds
3. at 9 seconds timer app event, the pin is checked: if button disable, jump to user firmware and if not start the bootloader.

Can you try to do this? I hope you will agree with this sequence.

The way it is currently working on the remote is to go to bootloader if any key is held down for 10s or more.
This is pretty straightforward.
Also, with the board button working in the bootloader firmware as a failsafe against app firmware potential issues, this is probably OK.

In summary, I propose that bootloader can be entered by either a
1. 10 s push of either the board button on tsdz2_wireless or any remote pad key on ebike remote control (I am pretty sure I can fix the board button issue with tsdz2_wireless)
Or
2. Board button push during power on in both firmwares
What do you think?

Maybe if you make 2 pins, one or other, to start the bootloader, like board button or UP button (P5). The P5 is not used on the TSDZ2 board so it is ok.
What I mean is that we could have only one common bootloader:
- TSDZ2 board: would start with button board only as P5 is not connected
- remote board: would start with P5 as button board will not be accessible

 

[rananna]

I tested a few times, with debugger connected and not connected, it simple does not work on my board.

Basic question - did you compile the new hex for the bootloader and link it with the TSDZ2 wireless firmware?
Only the latest firmware for the bootloader will sense a button press on boot.

I also just made a PR for TSDZ2 wireless , please read the PR notes.

 

[rananna]

I tested a few times, with debugger connected and not connected, it simple does not work on my board.

Also, I see you removed the launch.json option to clear the PSEL register that I put in.
If you compile any firmware with the CONFIG_GPIO_AS_PINRESET option it sets the PSEL register which makes pin 18 as a Pin RESET. Unfortunately, the OPENOCD clear will not clear this register, which is why I added the program to reset this register.
If you want to compile and run it on your board, here is the github repository:
https://github.com/rananna/pselreset

 

[casainho]

I tested a few times, with debugger connected and not connected, it simple does not work on my board.

Basic question - did you compile the new hex for the bootloader and link it with the TSDZ2 wireless firmware?
Only the latest firmware for the bootloader will sense a button press on boot.

I also just made a PR for TSDZ2 wireless , please read the PR notes.

Sorry, I think there is a big confusion right now and I will try to explain better myself. Your PR just added to the TSDZ2 firmware the possibility to click the board button to start in bootloader mode... here is what is needed:

1. On the bootloader, there is only 1 way to enter on the bootloader: at startup, check for a long press of at least 10 seconds of the pins board button or remote UP button (P5).

2. On the firmware, there is only 1 way to enter on the bootloader: write ANT ID as 0x99.

So, I will not accept your PR because it adds an extra option to 2. I hope this is ok for you.

 

[casainho]

I tested a few times, with debugger connected and not connected, it simple does not work on my board.

Also, I see you removed the launch.json option to clear the PSEL register that I put in.
If you compile any firmware with the CONFIG_GPIO_AS_PINRESET option it sets the PSEL register which makes pin 18 as a Pin RESET. Unfortunately, the OPENOCD clear will not clear this register, which is why I added the program to reset this register.
If you want to compile and run it on your board, here is the github repository:
https://github.com/rananna/pselreset

Well, for some reason your previous pull request had some conflicts and maybe I removed launch.json without understand it.

Can you please verify again current bootloader code? maybe correct the launch.json?

 

[rananna]

Sorry, I think there is a big confusion right now and I will try to explain better myself. Your PR just added to the TSDZ2 firmware the possibility to click the board button to start in bootloader mode

Ok, we are definitely not on the same page.
I thought you wanted 2 ways to enter the bootloader when the tsdz2 wireless firmware is running normally:
1wireless using 0x99 ant id
2 using a long 10s button press.
I personally do not see the need for a button press as I can't imagine a situation where you would want a hardware button to go into bootloader when the firmware is running. So, if we are in agreement, forget the pull request.
That will leave us with option 1 only for the tsdz2 wireless firmware.
The wireless remote will also have only one option, press and hold any key for 10s and it will enter the bootloader.

1. On the bootloader, there is only 1 way to enter on the bootloader: at startup, check for a long press of at least 10 seconds of the pins board button or remote UP button (P5).

I think the misunderstanding may be here. On startup, the bootloader is only active long enough to load the firmware. We can (and I do) check to see if the board button is pressed upon entry, but an interrupt based 10s timer that prevents the app from being loaded seems unnecessary to me. If the user is pressing the board button after power cycling they definitely want the bootloader in dfu mode. Why make them wait 10 seconds to go into dfu mode?
Right now, the bootloader will go into dfu mode if the button is pressed on bootloader entry. If you want me to change this to a 10s wait for the button press please confirm.
For the TSDZ2 remote, I can modify the bootloader code to look for the plus key being pressed on entry to cause it to go into bootloader mode. Again if you want this to be pressed for 10s on reboot before dfu starts, let me know.

 

[casainho]

1. On the bootloader, there is only 1 way to enter on the bootloader: at startup, check for a long press of at least 10 seconds of the pins board button or remote UP button (P5).

I think the misunderstanding may be here. On startup, the bootloader is only active long enough to load the firmware. We can (and I do) check to see if the board button is pressed upon entry, but an interrupt based 10s timer that prevents the app from being loaded seems unnecessary to me. If the user is pressing the board button after power cycling they definitely want the bootloader in dfu mode. Why make them wait 10 seconds to go into dfu mode?
Right now, the bootloader will go into dfu mode if the button is pressed on bootloader entry. If you want me to change this to a 10s wait for the button press please confirm.
For the TSDZ2 remote, I can modify the bootloader code to look for the plus key being pressed on entry to cause it to go into bootloader mode. Again if you want this to be pressed for 10s on reboot before dfu starts, let me know.

For the TSDZ2 board, the idea is to use the board button to 2 different functions: 1. startup the system or 2. enter bootloader.
My idea is that we can put the board in ultra low power mode just like the remote and then wakeup / startup the system with a board button press, that I hope will be less than 1 second and no more than 10 seconds. On the bootloader, checking for this button on the first 1 second means that all this will not add a delay more than 1 second for system to boot.

For the remote, the UP (P5) will have also the 2 different functions: 1. startup the system or 2. enter bootloader.

So I think the bootloader can be common to both projects if checking the long press at startup, of the buttons board and UP (P5). Maybe even the long press could be like 20 seconds, so user will not start the bootloader by mistake because that way the remote will not work and maybe user will not understand why...

 

[rananna]

Can you please verify again current bootloader code? maybe correct the launch.json?

I will modify the bootloader code to be what you want and thorough test before generating a PR.

I will add the launch.json mod to clear the psel register for the makerdiary 52840 dongle to the bootloader code also.
I suspect that is why your board button is not functioning; p18 is configured as a reset pin.

 

[rananna]

For the TSDZ2 board, the idea is to use the board button to 2 different functions: 1. startup the system or 2. enter bootloader.
My idea is that we can put the board in ultra low power mode just like the remote and then wakeup / startup the system with a board button press, that I hope will be less than 1 second and no more than 10 seconds. On the bootloader, checking for this button on the first 1 second means that all this will not add a delay more than 1 second for system to boot.

Now, we are getting to the source of my confusion. The board button can certainly wake up the firmware from low power mode. However, I didn't think that the bootloader is activated when the nrf52840 wakes up . It will never see the button push unless you force a reset when waking up. Are you intending to do this when the button is pressed to get into bootloader mode?

 

[casainho]

However, I didn't think that the bootloader is activated when the nrf52840 wakes up. It will never see the button push unless you force a reset when waking up. Are you intending to do this when the button is pressed to get into bootloader mode?

Well, see this comment on current bootloader code:

void shutdown(void)
{
  // // all pins must be disabled or system will wakeup, similar to a reset after enter ultra low power mode
  // // debug pins
  // nrf_gpio_cfg_default(10);
  // nrf_gpio_cfg_default(9);

  // enter in ultra low power mode
  nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF);
}

System will enter in NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF, that I think is a restart and may enter in bootloader everytime!! It will reset when you press the button, so, if it goes to bootloader, it must be a long press and not a regular press - I hope user will do a regular press to wakeup the remote and not a long press.

I did and tested, there are 2 moments when the remote will go to deep power sleep:
- timeout of 1 hour no button press
- ANT event EVENT_RX_SEARCH_TIMEOUT

You changed a lot the code, the main loop does not anymore enter in low power mode. The main loop can not be running the code for counting timers, it must use app_timers because they use low power (the RTC).
In the end we need to check again the code and test to make sure it is in lower power mode most as possible as also in ultra low power mode.
I can tell that first time when I had all this wrong, a battery only worked for a week. With all this of low and ultra low power mode, I think is running since at least 2 months ago!!

 

[casainho]

nrf_pwr_mgmt_shutdown(NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF);

A device will typically enter sleep from the main application (after advertisment timeout,etc.), and therefore not require any changes in the bootloader code, but you may need to disable the BOOTLOADER_BUTTON pin if you only have one button in your design, bootloader will enter DFU mode on startup if you use the same pin for wake-up.

https://devzone.nordicsemi.com/f/nordic-q-a/33507/bootloader-deep-sleep

 

[rananna]

System will enter in NRF_PWR_MGMT_SHUTDOWN_GOTO_SYSOFF, that I think is a restart and may enter in bootloader everytime!! It will reset when you press the button, so, if it goes to bootloader, it must be a long press and not a regular press - I hope user will do a regular press to wakeup the remote and not a long press.

Yes it does reset. This is such a complicated SOC to learn!
My whole confusion was trying to understand when the bootloader is active for the button capture.
Anyway here is further confirmation from Nordic that it resets:

https://devzone.nordicsemi.com/f/nordic-q-a/35445/nrf_pwr_mgmt_shutdown_goto_sysoff-and-nrf_pwr_mgmt_run?ReplySortBy=CreatedDate&ReplySortOrder=Ascending

I will make the changes to the bootloader code and give you a pull request.

 

[plpetrov]

For the TSDZ2 board, the idea is to use the board button to 2 different functions: 1. startup the system or 2. enter bootloader.
My idea is that we can put the board in ultra low power mode just like the remote and then wakeup / startup the system with a board button press, that I hope will be less than 1 second and no more than 10 seconds. On the bootloader, checking for this button on the first 1 second means that all this will not add a delay more than 1 second for system to boot.

Just my 2 cents...

I think your are missing two more functions that this button should play:

1. Shutdown if the system is up and running.
2. Reset or force shutdown in a similar way it is implemented on the PCs and the phones in case of issues.

I see no reason why to be limited only to the embedded board’s button only?

Also as you are always speaking about consistency and code unification, why you simply do not add the option to connect buttons to TSDZ2 wireless board. Preferably with exactly the same functions as on the remote. They might not be visibly installed and used only in emergency cases but will give the user an option to change the assist level and turn on the lights on his bike in case the battery of the remote is dead or in case he is in an area with strong radio frequency interferences.

 

[casainho]

For the TSDZ2 board, the idea is to use the board button to 2 different functions: 1. startup the system or 2. enter bootloader.
My idea is that we can put the board in ultra low power mode just like the remote and then wakeup / startup the system with a board button press, that I hope will be less than 1 second and no more than 10 seconds. On the bootloader, checking for this button on the first 1 second means that all this will not add a delay more than 1 second for system to boot.

Just my 2 cents...

I think your are missing two more functions that this button should play:

1. Shutdown if the system is up and running.
2. Reset or force shutdown in a similar way it is implemented on the PCs and the phones in case of issues.

I see no reason why to be limited only to the embedded board’s button only?

1. Is obvious and hardware is already able to disable TSDZ2 motor controller. The wireless board can always be on (will use about 0.5Wh per each week) or be disabled with a switch.

2. This is a DIY almost quick and dirty, most simple possible to avoid soldering as possible. No fancy hardware to do such thing. But that can be achieved manually by unconecting the wireless board on the display connector of TSDZ2.
But I am pretty sure that will not be needed.

Also as you are always speaking about consistency and code unification, why you simply do not add the option to connect buttons to TSDZ2 wireless board. Preferably with exactly the same functions as on the remote. They might not be visibly installed and used only in emergency cases but will give the user an option to change the assist level and turn on the lights on his bike in case the battery of the remote is dead or in case he is in an area with strong radio frequency interferences.

I am assuming the user will always have another alternative in the case the battery of remote goes empty (which should work for one year long) - user will have the phone or like me, also a compatible watch.
And see that battery state of remote will possible be shown on the mobile app as also the mobile app may give an alert to user for low battery when it is maybe like with 20% (yet 2.5 months available).

But other options will be possible, this is an OpenSource project, everyone will be able to thinkering with it!! Like adding wired buttons.