fix led signalling

[rananna]

@casainho , fix a couple of signalling issues with power on , brakes, and walk mode

[4var1]

@casainho - asking here rather than on the main thread. People having issues with the DFU mode - why don't we provide the wireless_combined binary to flash bootloader and controller in one openocd step - see if that solves the issue? I know it doesn't help develop the OTA updates in that instance - but would be a good way to confirm their boards are working correctly if they are having DFU problems. Otherwise we risk people getting disheartened by thinking they need to rework their board when it's not really the issue.

And once they put their controller in a case - later updates must be OTA - so we still get the feedback.

[casainho]

Well, I did not yet understand what are the issues roots. Users need to deal with DFU anyway because of our firmware updates that is supposed to be many at this phase of the project. And at first time after flashing the bootloader, the system will always start in DFU, so, I think there is no mistake to enter in DFU.

I think we need to understand clearly where are the users issues and clarify on the instructions. Are they flashing the wrong file? can that be the issue?

[4var1]

Yea I'm not sure - I've done OTA for the initial flash just to test - but I've never done the 0x99 step to OTA flash updated firmware. I can't drag myself away from the ease and speed of swd! Maybe I should try that step and see what it's like. Do you always do it from the android app?

[casainho]

For the TSDZ2 wireless, I do my updates by writing the 0x99 and it works well for me. For the remote, as Bluetooth is not enable, then I do the button option that is some long press when at configurations mode - it always work.

[casainho]

I still do not know if their problem is when updating by DFU or if simple there is a problem with our mobile app not detecting and / or pairing with TSDZ2 wireless.

[rananna]

,I have been thinking about how we might confirm that a user had implemented a dfu successfully.

Of course, the nordic dfu upgrade has a progress indicator, and we wrote up what I thought were pretty clear that instructions on how to use the app ( along with a video), but as we saw on the forum, we are left guessing on whether the user did this successfully.

So how about this idea: On board power up, we compare the version number hard coded in the firmware with the version number written to flash memory previously.

If the two numbers disagree we flash a display of the version number ( Major number could be red, minor number could be green). For example, version 1.2 would flash a red led once, followed by a green flash twice. We could repeat this several times ( say 3 or even 5 times!) when a new firmware is detected to be sure a user sees it. We would then write the new version number in flash and never display again on power up until a new version is loaded by dfu.

We would then have a clear visual indicator that the user has successfully completed dfu and that they have loaded the right firmware version.

What do you think?

[casainho]

I would prefer first to understand why the user fail to flash the correct firmware file. Do you think the user is like flashing a wrong file? Since I know, the bootloader should accept only our NRF52 firmware file or our NRF52 bootloader file, right?

[rananna]

They cannot flash a wrong file, only a wrong version ( an earlier version of the firmware). We allowed downgrading of firmware to allow users to revert software to an earlier version.

They could also flash a wireless remote firmware and try to use the board as a wireless controller or vice versa. Hard to protect against that error.

[rananna]

And of course the bootloader will not accept any other file as they would not be signed. So they can only use our ota files

[rananna]

I just asked the user what filename they used.

[4var1]

@rananna - I'd like to back out the hack I put into the led code earlier in the week to mitigate the issue with sequences being lost when you queued lots of play_next quickly. Could you try commenting out the below line 348 in ledalert.c please just to make sure it won't cause you problems. I don't think it will now you've converted to the other calls.

348 | led_sequence_clock(&led_sequence_clock);

If that works ok - then I think my only change before release will be to remove the above line - and finally comment out the old led calls from the header.

[4var1]

@rananna - I've done a PR for the updates above - please check it doesn't conflict., if you're using all the new calls should be fine. https://github.com/OpenSourceEBike/TSDZ2_wireless/pull/105

[rananna]

ok