nieles said:do you have one that still has the stock firmware?
if so, you can read the memory content even if its protected:
https://www.pentestpartners.com/security-blog/nrf51822-code-readout-protection-bypass-a-how-to/
I think that by doing that and getting the encryption keys would be nice for us developers and users of OpenSource firmware but can also put the manufacturer at a big problem!! Why?? Because then everyone will be able to update the bootloader itself and potentially render useless the SW102 and ask for warranty to the seller/a manafacturer.Nick said:nieles said:do you have one that still has the stock firmware?
if so, you can read the memory content even if its protected:
https://www.pentestpartners.com/security-blog/nrf51822-code-readout-protection-bypass-a-how-to/
NICE!
I hace one orig in spare and will try to dump the firmware.
Why take the risk while there are already 2 sellers negotiating with the manufacturer to flash on production our own bootloader on SW102?nieles said:while i agree with you partially, and we should not publicly share the keys, i see no reason not to 'unlock' the LCD's by releasing some software that would replace the bafang booloader with our own. this way the warranty is void and we wouldn't cause problems for the manufacturer.
casainho said:Once anyone update the bootloader with a different encryption keys and forget them by a mistake or simple flash a no working version of bootloader, the SW102 will be locked forever and will be useless...
casainho said:Why take the risk while there are already 2 sellers negotiating with the manufacturer to flash on production our own bootloader on SW102?
One of that sellers is already selling online TSDZ2 and KT-LCD3 flashed with our firmware. Why not trust them?
Nick said:casainho said:Why take the risk while there are already 2 sellers negotiating with the manufacturer to flash on production our own bootloader on SW102?
One of that sellers is already selling online TSDZ2 and KT-LCD3 flashed with our firmware. Why not trust them?
Yes, thats the official way to go! I agree!
One note, I think timer0 is used by softdevice, that we will need for Bluetooth. I think we can only use timer1.Nick said:I updated the SW102_LCD_Bluetooth repository with my working copy (as suggested by casainho).
SPI transfers are now implemented none-blocking by SPI transaction manager. For now, LCD gets refreshed every 50 ms by a timer.
Software delay loops suffer from slow-downs especially if you further reduce the refresh rate so this is still quite demanding. But we have enough processor power left. We also may implement the LCD refresh far more efficient if we trigger this in the uGUI library only when necessary. This will also reduce tearing effects (from the quite slow 20 Hz refresh) to zero.
I think can then can be a good idea to first fully update the framebuffer when receiving and calculating all the new data to show on LCD and finally push to LCD.Nick said:Sure you can update pixel by pixel on SW102 also. But you have a huge overhead then. Before you can write pixel data you have to set page and pixel address by a 3 byte command. So, 4 bytes per pixel plus the overhead of the SPI transaction manager to initiate a transfer!
Thus I write the maximum amount of data before you have to set a new page address in one go (thats one page / 64 bytes) in a queue of 16 transactions managed by the transaction manager. Because the uGUI library writes pixel by pixel, it uses the SRAM frameBuffer.
The "biggest" problem is, that frameBuffer write to LCD is not synchronized with uGUI write to frameBuffer. If you reduce the refresh rate to much, you can see some kind of "tearing effect", where f.i. a text is painted incompletely on the LCD for a short period of time. This just doesn't feel snappy / looks good.
The best way to go is to extend the uGUI lib to trigger a lcd_refresh after each complete GFX function (f.i. String, Circle, etc.). We only have SPI writes if we really paint something in the uGUI lib (f.i. once a second). If we compare this with the current 50 ms refresh rate this would reduce CPU load by ~20!
My next step is trying to implement this.
P.S.
Another solution would be to trigger lcd_refresh manually. So we can decide when to refresh, f.i. only if a new page with all its elements is finished or values from motor shown on the LCD indeed change. But this means a bit more code overhead.
casainho said:One of that sellers is already selling online TSDZ2 and KT-LCD3 flashed with our firmware. Why not trust them?
Aeron said:casainho said:One of that sellers is already selling online TSDZ2 and KT-LCD3 flashed with our firmware. Why not trust them?
Trust aside, this seller charge for flashing and don't ship outside of north America.
For a non north-american wanting to save $35 (+ expensive shipping if they were to ship anyway), that makes two valid reasons.
Not saying it's too expensive or anything, just saying why I believe this is not a good solution for everyone (and by quite a reasonnable distance).
I'd rather have a firmware I can flash myself on any SW102 than having to rely on a couple sellers to obtain a certain version of this neat looking LCD.
So, this means that you as a seller, if an user render useless the SW102 because by mistake or on purpose did flash a no working bootloader version and ask a replace using the warranty, would not be an issue for you?? And do you think would be an issue or not for the manufactur?Rydon said:If there is a way forward that allows any generic SW102 to be flashed with open source firmware then we are 100% in favor of that.
casainho said:So, this means that you as a seller, if an user render useless the SW102 because by mistake or on purpose did flash a no working bootloader version and ask a replace using the warranty, would not be an issue for you?? And do you think would be an issue or not for the manufactur?Rydon said:If there is a way forward that allows any generic SW102 to be flashed with open source firmware then we are 100% in favor of that.
To clarify: the possibility to get the bootloader encryption keys with or without the manufacture acceptance, should let anyone flash at a distance (using Bluetooth) the bootloader and the firmware, working or non working versions (and in this case render useless the SW102 if flashing no working bootloader).
So, as we can understand for what you did explain, you and Eyebyesickle are negotiating with the manufacture not only the possibility to sell SW102 with our own Bluetooth bootloader and with the cables ready for TSDZ2. All of that are of great importance for the TSDZ2 ebike users as you did explain and this is easy to understand.Rydon said:casainho said:So, this means that you as a seller, if an user render useless the SW102 because by mistake or on purpose did flash a no working bootloader version and ask a replace using the warranty, would not be an issue for you?? And do you think would be an issue or not for the manufactur?Rydon said:If there is a way forward that allows any generic SW102 to be flashed with open source firmware then we are 100% in favor of that.
To clarify: the possibility to get the bootloader encryption keys with or without the manufacture acceptance, should let anyone flash at a distance (using Bluetooth) the bootloader and the firmware, working or non working versions (and in this case render useless the SW102 if flashing no working bootloader).
No, I did not mean to imply that. Perhaps it is wishful thinking. Those concerns need to be addressed.
On that design for the main screen, I would:Rydon said:The light and dark background on the assist level is a stealthy way to communicate road/off-road mode. I like having the volts but I think % could be graphical.
casainho said:So, as we can understand for what you did explain, you and Eyebyesickle are negotiating with the manufacture not only the possibility to sell SW102 with our own Bluetooth bootloader and with the cables ready for TSDZ2. All of that are of great importance for the TSDZ2 ebike users as you did explain and this is easy to understand.Rydon said:casainho said:So, this means that you as a seller, if an user render useless the SW102 because by mistake or on purpose did flash a no working bootloader version and ask a replace using the warranty, would not be an issue for you?? And do you think would be an issue or not for the manufactur?Rydon said:If there is a way forward that allows any generic SW102 to be flashed with open source firmware then we are 100% in favor of that.
To clarify: the possibility to get the bootloader encryption keys with or without the manufacture acceptance, should let anyone flash at a distance (using Bluetooth) the bootloader and the firmware, working or non working versions (and in this case render useless the SW102 if flashing no working bootloader).
No, I did not mean to imply that. Perhaps it is wishful thinking. Those concerns need to be addressed.
I think it is really important to keep that negotiations and good relationship going on because that way we all be happy: manufacturer and shops will sell more and TSDZ2 ebike users will have a much better LCD than the original one, and all of this at accessible prices and possible on many online shops.
If we make the life hard for the manufacturer and shops, that will for sure make also hard the life of TSDZ2 ebike users as the manufacturer and shops will try to protect themselves, probably stop selling SW102.
casainho said:To clarify: the possibility to get the bootloader encryption keys with or without the manufacture acceptance, should let anyone flash at a distance (using Bluetooth) the bootloader and the firmware, working or non working versions (and in this case render useless the SW102 if flashing no working bootloader).
Rydon said:Eyebyesickle has been working with Topology the longest so we have agreed that he will be the main one driving communications with the manufacturer on this effort.