Bafang SW102 Bluetooth LCD - OpenSource firmware and mobile app

casainho

10 GW
Joined
Feb 14, 2011
Messages
6,043
This thread is for discussion on development of OpenSource firmware and mobile for Bafang SW102 Bluetooth LCD.

See all the details about the firmware, here: https://github.com/OpenSource-EBike-firmware/TSDZ2_wiki/wiki
 
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/
 
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.
 
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.
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.

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 -- this will be a nightmare for warranty of seller/manufacturer.

With a physical connection like on KT-LCD3, is unlikely to lock forever but not on SW102.

So I would avoid to do that other way I would be responsible for potentially big problems to the seller/manufacturer and that means also big problems for us users and developers if OpenSource firmware once seller/manufacturer stops selling the problematic SW102 LCD.
In my opinion, the best we can do is to keep manufacturer/sellers happy by making more and more users to buy SW102 and then ask seller/manufacturer to provide a version with our own bootloader and so everyone will be happy -- users and sellers/manufacturers.
 
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.
 
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.
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?
 
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...

I didn't dive into the nrf5 bootloader concept but a bootloader which can destroy itself by any kind of wrong configuration is a really bad design!
First, a bootloader should be very robust. Bricking the SW102 by the DFU bootloader should be near to impossible.
But apart from that, extracting the keys and publish them "officially" in the context of this project would be a against law I think. This renders the key extraction quite useless anyway.

What I can imagine is that there will be "magically" signed firmware packages of the open source project "somwhere on the internet" which one can flash with the orig. bootloader. :wink:
But nothing official.
 
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!
 
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!

+1
 
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.
 
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.
One note, I think timer0 is used by softdevice, that we will need for Bluetooth. I think we can only use timer1.

850C LCD driver seems more efficient that we can update pixel by pixel or a rectangle. On SW102 seems the min we can update is a page of 64 bytes = 512 pixels.

And I think we don't need to update at less than 100 ms, as data coming from motor controller happens at 100 ms. Some variables even should not update at less than 1000 ms or will be confuse for user to see fast changing values, better to have stable/low pass filter values and that means simple refresh at low frequency like the 1000 ms.
 
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 code overhead of the SPI transaction manager to initiate a transfer! --> for a complete LCD write this would be 1 kB + 3 kB of data.
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. --> for a complete LCD write this would be 1 kB + 48 byte of data.
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) and it is synced. If we compare this with the current 50 ms refresh rate this would reduce CPU load by ~20 (just a wild guess, maybe some few percent of CPU load).
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.
 
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.
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.
But I think as like on 850C, you need to guarantee that communication receive code has higher priority on an interrupt and LCD print can be called on main loop.
 
For next step, I would start the communications code and make sure I get it working and being able to print on LCD data like wheel speed or motor power. If this data always work means there is no problem with the receives packages and that means no timing issues in the code, then, all other next things will be easier to implement.

I am also curious for the design and what configurations should the LCD provide (guess will be a min value of them as the full can be on the mobile app).
 
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.
 
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.

All reasonable concerns. 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. However, the primary developers were headed down a path that would require breaking the case open to flash it. That simply wouldn't work for the majority of people that might like to use it. That approach is limited to a few fearless DYIers and would remain valid even if there were other options out there like the ones we proposed. I am sure there will be many ways to get the job done and of course, the easiest and cheapest will prevail. Right now, splicing cables and flashing firmware is daunting to a lot of users that want to use the TSDZ2/KT-LCD3 open source firmware so we have made it easy for them. Others have more money than time or technical confidence so they now have an option that works for them.

With the quantities and discounts involved, It is likely that the price you would pay for one of our pre-loaded displays will be the same as you could buy the generic display elsewhere that would need to be hacked in some way to load new firmware. However, like you, I would want other options as well. :)

I will also re-post here, the options and issues I described in the main forum since the conversation has moved.

FYI, We are now shipping outside North America by separate quote. Shipping prices are in the product description.
 
Repost:

Although doable, opening up the case is pretty ugly so Eyebyesickle and I have been exploring Bluetooth uploading and firmware flashing with Topology Tech., the SW102 manufacturer. The problem we have is that they require an NDA to gain access to their boot loader and technical documents. As Casainho has pointed out an NDA is not possible with an open source project like this. Eyebyesickle is still trying to get them to reconsider this so that is still a possibility.

Topology Tech has said that with a volume commitment, they would be willing to preload firmware for us at the factory. We are willing to make that commitment. There are several possibilities with that approach.

The first might be to use a generic Bluetooth bootloader based on the Nordic NRF SDK that we could give to Topology to preload at the factory, after which we can use Bluetooth to update the firmware. Some have expressed that with a generic bootloader someone could maliciously reprogram your display remotely. I tend to think the possibility of this is remote and is a form of vandalism. A vandal could more easily take a hammer to your display if harm was their intent. Perhaps a password system could be implemented as a way to address this concern.

Another possibility would be to load a complete version of the firmware. The problem would be that it would be stuck on that version. Maybe that would not be bad if it was mature. My concern is if people start expanding it to cell phone app functionality they will inevitably want to make changes to the SW102 firmware. This has been the case with Eggrider for over a year. I would rather see a generic bootloader loaded at the factory or if Eyebyesickle prevails we can perhaps use theirs without an NDA.

I am sure we will figure something out. Let's keep this discussion going as development proceeds.
 
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.
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?

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).
 
casainho said:
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.
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?

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.
 
There is a discussion going on in the Eggrider facebook group about simplifying and making the text bigger and more readable for the critical functions. There have been many complaints and of course, there are always a lot of tradeoffs and opinions regarding what information is critical, keeping it simple and making such a tiny display able to be read while riding. Here is one proposal that I like a lot.

57118232_10217618180099475_899070610787794944_n.jpg

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.
 
Rydon said:
casainho said:
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.
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?

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.
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.

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.
 
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.
On that design for the main screen, I would:
1. not show battery voltage as we support very good SOC estimation, based on coulomb counting AND battery voltage considering battery resistance

2. swap battery SOC to left and use instead graphic indication (or numeric or maybe voltage if user prefer on a configuration) on right side where is battery SOC, I would put the time as "12:05". I already investigated and seems SW102 hardware may add/remove max of 1 second per each hour. I hope this can be calibrated by the user, like how many seconds to adjust after each 24h

3. we have other values, like human pedal power or motor temperature but that can be like LCD3 odometer field and as shown on that picture, with the advantage that we can now add a small label for the data being shown on that "odometer" field. But I agree that we should start simple and not add to much information on this LCD and move the most advanced information to the mobile app.
 
casainho said:
Rydon said:
casainho said:
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.
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?

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.
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.

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.

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.
 
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).

this is only true if 'button-less' DFU is implemented. otherwise you always need some manual action to trigger the bootloader. (like power up the display with the down key pressed) this would not be possible for someone to do from a distance.

the Nordic bootloader works like this from reset: sofdevice is on 0x0 so is started first (acutally the first page is called MBR). the softdevice then starts the bootloader. the bootloader checks some 'special' condition. if this is met, the bootloader waits for bluetooth connection to receive new firmware. if the special condition is not met. normal code is started. the only way to get in to the bootloader now is to reset the MCU.

there is one exception for this. that is called 'button-less' DFU. with this, you implement a special feature in your normal code to jump back to the bootloader. the would make it possible to update the code from a distance if you implement this with something you can trigger from bluetooth
 
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.

Yes I have been working with Topology/Star Union Wuxing for a while and am confident we can get approval for whatever we need within reason. Me and Rydon should be able to bring in enough to make this platform reasonably priced and widely available, and I will arrange to keep some with a Chinese partner for cheap international shipping... This will be good for everyone... I have actually been working on this for quite a while as I saw merit in this display early on!

Working with the SW102 and TSDZ2
[youtube]8uTGae2oqF4[/youtube]
 
Back
Top