DFU over BLE for Simblee

RE: DFU over BLE for Simblee

Tim — Fri, 22 May 2020 04:51:59 GMT

Hi Edvin,

As per related ticket ...

I have ble_app_uart for s130 in SDK 12.3 now working with s110. I also discovered that Simblee apps are located at 0x1F000 instead of the standard location 0x18000. I don't understand why. When I change the FLASH_START address from 0x18000 to 0x1F000 and build the app, I can take the hex file, generated a zip using nrfutil and the Simblee bootloader will accept the image and the app runs properly.

So I'm good now and will proceed with work to customize ble_app_uart for our application.

Many thanks for your help along the way.

Tim

RE: DFU over BLE for Simblee

Tim — Wed, 29 Apr 2020 14:53:36 GMT

Thank you Edvin. All understandable, and I’m learning a lot from you.

I agree the best approach is to replace the Simblee bootloader (via DFU over BLE) with one I develop thereby giving us full control over the DFU process from that point on. However, I speculate that the Simblee bootloader does not allow update of the bootloader itself. If this turns out to be the case, then it seems to me our only option to update the application on the 700 Simblees in the field would be to first discover the SoftDevice and version required by the currently installed Simblee bootloader and develop our new nRF51822 app accordingly, then push it out to our users via a new version of our iOS app that uses DFU over BLE to update the application. Am I understanding this correctly?

The next step is to build a DFU/BLE bootloader for nRF51822 and see if the currently installed Simblee bootloader will accept it. This is what I’m working on now.

I am also going to try and reach the developer of Simblee and also the company that acquired the product (AMS) to see if, given they discontinued the Simblee product line, they might provide developers that used Simblee access to information that would be helpful.

All along I’ve been assuming that if I’m unable to update the application on Simblee, either by updating the bootloader, SoftDevice and application, or just the application, that we would be able to have our 700 customers return their devices and we could erase the flash and install our own bootloader, application (and appropriate SoftDevice) via an nRF51 DK. Unfortunately, the Simblee flash process via the Arduino IDE uses Serial IO on GPIO 0/1 whereas SWD (required by nRF51 DK) is supported on two different Simblee pins and our board layout does not provide access to SWDCLK. So we can’t even update the application by recalling product.

Will see where this all leads. Enjoying the learning along the way.

Many thanks,

Tim

RE: DFU over BLE for Simblee

Edvin — Wed, 29 Apr 2020 07:20:34 GMT

No worries, Tim. It may say something about the version in the BL hex file, but as soon as they change just a tiny thing in the bootloader project, it may change the location of many (!) things in the .hex file. In this case, you are looking at a binary blob that you would have to reverse engineer in some way. Besides, I believe that the softdevice version is stored in the bootloader settings, and not in the bootloader itself. And since the requirement for the dfu image is 0xfffd, I doubt it will say.

Unfortunately, the flash start is quite generic. It is rounded up to the next page. So this would indicate that the softdevice ends between 0x1E000 and 0x1EFFF.

Looking at the latest softdevice for nRF51, S130 from SDK12.3.0, the applications from this version starts at 0x1B000, so I am not sure this is actually a hint. Please also note that the start address of an application transferred over DFU doesn't really matter. The bootloader will place it after the softdevice. They may have known this, and just set a "random" address.

I am not sure why you would need to know what softdevice version they use? Can you remind me? You don't need this in order to transfer the new bootloader (if possible).

RE: DFU over BLE for Simblee

Tim — Tue, 28 Apr 2020 14:20:49 GMT

Thanks Edvin. Yes, I realize the SD is separate from the BL and app. I wondered, though, if the SD required by the BL might be somehow specified in the BL itself. Please pardon my inexperience.

Can the location of the application in flash offer a clue of the required SD? The start address of the app allows enough room for the MBR and SD. Each SD version has a particular size.

Thank you,

Tim

RE: DFU over BLE for Simblee

Edvin — Tue, 28 Apr 2020 07:09:51 GMT

The bootloader is usually placed in the top of the flash. This is done to minimize the restriction of the application size.

The bootloader does not contain the softdevice. Check out the memory layout for the bootloader:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v12.3.0/lib_bootloader.html?cp=7_5_8_3_5_0_1#lib_bootloader_memory

RE: DFU over BLE for Simblee

Tim — Tue, 28 Apr 2020 05:35:32 GMT

Hi Edvin. I tried connecting to Simblee via nRF51 DK and it appears that it's readback protected. This is not surprising.

So will turn my attention to building an nRF51 DFU/BLE bootloader and see if the Simblee DFU bootloader will accept it.

I don't suppose it's possible to look inside the Simblee DFU bootloader hex file to see which SD is required? I've attached the hex.

Thanks,

Tim

devzone.nordicsemi.com/.../ota_5F00_bootloader_5F00_dual_5F00_bank.hex

RE: DFU over BLE for Simblee

Tim — Mon, 27 Apr 2020 15:18:42 GMT

Thanks Edvin. I will pursue both angels: 1) determine the SD required by the current Simblee bootloader (on devices in the field) with the possibility of developing a new app using that Nordic SDK and that SD that can be accepted by current bootloader over BLE, and 2) determine if current Simblee bootloader will accept a new bootloader, which would be a better solution because we would then have control over the bootloader and the DFU process.

I found buried in the Simblee library these files:

ota_bootloader_dual_bank.hex
ota_bootloader_single_bank.hex

These appear to be the bootloaders that allow either single or dual bank DFU. I built a simple blinky app for Simblee using the Simblee library and Arduino IDE that uses the Simblee bootloader. Then using nRF Connect on macOS I connected to my nRF51 DK, then added the dual bank bootloader and compiled blinky app hex files to the file memory layout and see the following regions:

Seems odd that they place the bootloader at the top of flash. They've probably done a lot to try and hide much of the layout. Of course the app does not run because there's no SD and MBR.

Today I will try your suggestion of connecting a Simblee (programmed with app, SD and bootloader) to an nRF51 DK and try reading the device memory layout. Will also try to read the hex files from the device but I speculate that they've disabled flash reading.

Thanks for your guidance Edvin.

Tim

RE: DFU over BLE for Simblee

Edvin — Mon, 27 Apr 2020 08:46:29 GMT

[quote user="Tim123"][/quote]

the command specifies 0xfffe for --sd-req:

nrfutil dfu genpkg simblee77-1.zip --application simblee77-1.hex --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0xfffe

Is that specified from simblee?

0xfffe means "softdevice required, but no version specified". I find it a bit strange, because that means that there is no guarantee that the application will work, if the application doesn't require the same softdevice version as the bootloader. But I guess that if they have their own IDE (or use some version of arduino), then they will always use the same softdevice version. Unfortunately, it doesn't give any hints on what version that is used.

Do you have the possibility to read out the flash of your device? If you are able to attach a debugger, you can use the command:

nrfjprog --readcode <file-name>

e.g.:

nrfjprog --readcode my_flash_dump.hex

to read out the flash. Can you do this, and send me the .hex file? I can try to figure out which softdevice that is used. NB: still no guarantee that you can update the bootloader based on this information.

[quote user="Tim123"]I will focus on creating a DFU bootloader from the SDK 12.3 example and get that working on nRF51 DK. Then will try on a Simblee with fingers crossed.[/quote]

I agree that this sounds like the best plan. Actually, it isn't certain that you need to know the softdevice being used by the old bootloader for this. When you have a bootloader, try to generate a dfu image like you do for your applications, containing the new bootloader and new softdevice, and see if it is accepted or not.

Best regards,

Edvin

RE: DFU over BLE for Simblee

Tim — Fri, 24 Apr 2020 15:42:13 GMT

I understand, Edvin. I find it odd that to generate the DFU package (using version 0.5.2 of nrfutil), the command specifies 0xfffe for --sd-req:

nrfutil dfu genpkg simblee77-1.zip --application simblee77-1.hex --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0xfffe

Does that reveal anything about the SD that might be installed on Simblee? Or does this simple mean the required SD is not specified within the package, but the bootloader will still require a specific SD and version?

I will focus on creating a DFU bootloader from the SDK 12.3 example and get that working on nRF51 DK. Then will try on a Simblee with fingers crossed.

Many thanks Edvin,

Tim

RE: DFU over BLE for Simblee

Edvin — Fri, 24 Apr 2020 13:04:50 GMT

Not to upset you, but there are several versions of S130, S110 and S120 as well. So I guess you have a bit of work ahead. One version typically with each SDK release.

Again, you should look into updating the bootloader itself. Once you do this, you are free to choose any combination of bootloader and softdevice (that is matching, of course).

RE: DFU over BLE for Simblee

Tim — Fri, 24 Apr 2020 11:47:21 GMT

Hi Edvin,

Ongoing thanks. I would not be able to do this work without the support of you and other Nordic engineers. We are glad and committed to the Nordic platform. Thanks ..

This is all about DFU over BLE for the 700 Simblee units we have out in the field, with hope we can update application to an application we develop using Nordic SDK and SD via the DFU bootloader already present on the devices. We can use this DFU bootloader to update to a new application built using the Simblee library and Arduino IDE, but the Simblee library does not expose much of the SoftDevice, including the Timeslot API which we now need to use.

If the Simblee DFU bootloader will accept an application built using Nordic SDK+SoftDevice (over BLE), as you say, the app must use the same SoftDevice version the bootloader. So I'm trying to guess which SoftDevice that might be. Simblee was initially released in November of 2015. I see that SoftDevice options for nRF51822 are S110, S120 and S130. Version 1 of S130 was released June 2015, so it's a possibility. Version 1 of S120 was released May 2014. Version 1 of S110 was February 2013. So all SoftDevices could've been used.

S110 and S120 use SDK 10.0. I can start with S130 as it uses SDK 12.3 which is newer. In trying to import and build ble_app_uart example of SDK 12.3 with SES 4.18 (macOS), I get (different) errors which I will post over at other thread.

Many thanks Edvin,

Tim

RE: DFU over BLE for Simblee

Edvin — Fri, 24 Apr 2020 06:09:37 GMT

[quote user="Tim123"]I wonder about trying to create a package that contains an application built using Nordic SDK 10.0 and S110, and seeing if the Simblee bootloader would accept it. Worthy of trying?[/quote]

It is worth trying. To be honest, it is a bit old, so I have never tested the bootloader with s110 and SDK10.

Is it a serial bootloader or a BLE bootloader? (I suppose serial) If so, I don't think there is any issues using any combination of Softdevice and application, since the bootloader is not dependent on a specific softdevice in order to work. If it is a BLE bootloader, your application will have to use the same softdevice version that the bootloader does.

I was assigned to your other ticket yesterday. I haven't got time to look into it yet. Hopefully, I'll get time today.

Best regards,

Edvin

RE: DFU over BLE for Simblee

Tim — Thu, 23 Apr 2020 14:34:08 GMT

Thank you Edvin. That all makes sense. I wouldn't be surprised if the Simblee bootloader prevents updating of the bootloader itself. If that is the case, I wonder about the possibility of still updating the application via its legacy DFU bootloader to an application build using Nordic SDK. Is it possible to develop an application for nRF51822 without using your SDK and without requiring a SoftDevice? I wonder about trying to create a package that contains an application built using Nordic SDK 10.0 and S110, and seeing if the Simblee bootloader would accept it. Worthy of trying?

I'll proceed to create a DFU bootloader for nRF51822. I'm running into issues importing/building the DFU example of SDK 10.0 into SES 4.18 (macOS). Hopefully some assistance will come over at this post.

Many thanks Edvin,

Tim

RE: DFU over BLE for Simblee

Edvin — Thu, 23 Apr 2020 09:11:45 GMT

[quote user="Tim123"]It will take me some time to create a bootloader for nRF51822. I will start with the example included with SDK 10.0. I will proceed if you feel this is the next step in the investigation.[/quote]

Yes. I would say that this is the next step in the investigation, indeed. Good to see that you have some knowledge on DFU already. As mentioned, try to create your own bootloader on something that you know works (e.g. a DK), and update the bootloader itself there, just to see that you have the correct procedure.

It may very well be that the bootloader can update the bootloader without any issues, but the reason I mentioned it is that we do this thing in the nRF52840 dongle, where we have an open bootloader that can update to any application, because the dongle doesn't have a programming chip, but we have protected the bootloader from updating itself. The reason for this is basically that if anyone attempts to do so, and they fail in some way, causing the bootloader to not work, the device is bricked, because it doesn't have a programmer.

So try it out, and see if they have protected the bootloader from bootloader updates.

BR,

Edvin

RE: DFU over BLE for Simblee

Tim — Wed, 22 Apr 2020 15:56:21 GMT

Hello Edvin,

Thank you. Very helpful.

Yes, I have implemented a secure DFU bootloader for our nRF52832-based product and all works well.

I'm pretty sure the bootloader on Simblee is not secure because packages for consumption by the bootloader are generated without the use of a private key. I use version 0.5.2 of nrfutil with this command:

nrfutil dfu genpkg simblee77-1.zip --application simblee77-1.hex --application-version 0xffff --dev-revision 0xffff --dev-type 0xffff --sd-req 0xfffe

When I perform DFU update using nRF Connect on iOS, I get the following log:

File Name: simblee77-1.zip
Parts: 1
Size: 34 KB
Soft Device Size: Zero KB
Bootloader Size: Zero KB
Connecting to p1...
centralManager.connect(peripheral, options: nil)
[Callback] Central Manager did connect peripheral
Connected to p1
Discovering services...
peripheral.discoverServices(nil)
Services discovered
Starting Legacy DFU...
Connected to p1
Services discovered
Legacy DFU Service found
Discovering characteristics in DFU Service...
peripheral.discoverCharacteristics(nil, for: 00001530-1212-EFDE-1523-785FEABCD123)
DFU characteristics discovered
Reading DFU Version number...
peripheral.readValue(00001534-1212-EFDE-1523-785FEABCD123)
Read Response received from 00001534-1212-EFDE-1523-785FEABCD123, value (0x): 0100
Version number read: 0.1
Enabling notifications for 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.setNotifyValue(true, for: 00001531-1212-EFDE-1523-785FEABCD123)
Notifications enabled for 00001531-1212-EFDE-1523-785FEABCD123
DFU Control Point notifications enabled
Application with buttonless update found
Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x0104, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
Data written to 00001531-1212-EFDE-1523-785FEABCD123
Jump to bootloader (Op Code = 1, Upload Mode = 4) request sent
[Callback] Central Manager did disconnect peripheral
Disconnected by the remote device
Connecting to p1...
centralManager.connect(peripheral, options: nil)
[Callback] Central Manager did connect peripheral
Connected to p1
Discovering services...
peripheral.discoverServices([00001530-1212-EFDE-1523-785FEABCD123])
Services discovered
Legacy DFU Service found
Discovering characteristics in DFU Service...
peripheral.discoverCharacteristics(nil, for: 00001530-1212-EFDE-1523-785FEABCD123)
DFU characteristics discovered
Reading DFU Version number...
peripheral.readValue(00001534-1212-EFDE-1523-785FEABCD123)
Read Response received from 00001534-1212-EFDE-1523-785FEABCD123, value (0x): 0600
Version number read: 0.6
Enabling notifications for 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.setNotifyValue(true, for: 00001531-1212-EFDE-1523-785FEABCD123)
Notifications enabled for 00001531-1212-EFDE-1523-785FEABCD123
DFU Control Point notifications enabled
Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x0104, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
Writing image sizes (0b, 0b, 34376b) to characteristic 00001532-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x000000000000000048860000, for: 00001532-1212-EFDE-1523-785FEABCD123, type: .withoutResponse)
Data written to 00001531-1212-EFDE-1523-785FEABCD123
Start DFU (Op Code = 1, Upload Mode = 4) request sent
Notification received from 00001531-1212-EFDE-1523-785FEABCD123, value (0x): 100101
Response (Op Code = 1, Status = 1) received
Writing Initialize DFU Parameters...
Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x0200, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
Writing to characteristic 00001532-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0xffffffffffff00000100feff8014, for: 00001532-1212-EFDE-1523-785FEABCD123, type: .withoutResponse)
Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x0201, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
Data written to 00001531-1212-EFDE-1523-785FEABCD123
Data written to 00001531-1212-EFDE-1523-785FEABCD123
Notification received from 00001531-1212-EFDE-1523-785FEABCD123, value (0x): 100201
Response (Op Code = 2, Status = 1) received
Initialize DFU Parameters completed
Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x080c00, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
Data written to 00001531-1212-EFDE-1523-785FEABCD123
Packet Receipt Notif Req (Op Code = 8, Value = 12) request sent
Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x03, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
Data written to 00001531-1212-EFDE-1523-785FEABCD123
Uploading firmware...
Sending firmware to DFU Packet characteristic...
Notification received from 00001531-1212-EFDE-1523-785FEABCD123, value (0x): 100301
Response (Op Code = 3, Status = 1) received
Upload completed in 13.98 seconds
Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x04, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
Data written to 00001531-1212-EFDE-1523-785FEABCD123
Validate Firmware (Op Code = 4) request sent
Notification received from 00001531-1212-EFDE-1523-785FEABCD123, value (0x): 100401
Response (Op Code = 4, Status = 1) received
Writing to characteristic 00001531-1212-EFDE-1523-785FEABCD123...
peripheral.writeValue(0x05, for: 00001531-1212-EFDE-1523-785FEABCD123, type: .withResponse)
Data written to 00001531-1212-EFDE-1523-785FEABCD123
Activate and Reset (Op Code = 5) request sent
[Callback] Central Manager did disconnect peripheral
Disconnected by the remote device

The new package is generated using an application compiled using the Simblee library and Arduino IDE, so not sure if it uses a SoftDevice or other details. I am also able to perform DFU over BLE with our iOS app that uses the iOS-Pods-DFU-Library with the same successful results.

If I understand you correctly, a next helpful step would be to create my own bootloader and attempt to perform DFU to flash it to the Simblee device. It's uncertain at the moment if the bootloader on Simblee will accept a new bootloader. If that succeeds, then, given I have control over the bootloader, I can then enable it to accept S110 and a new app that uses S110. Am I understanding correctly?

It will take me some time to create a bootloader for nRF51822. I will start with the example included with SDK 10.0. I will proceed if you feel this is the next step in the investigation.

Again, many thanks,

Tim

RE: DFU over BLE for Simblee

Edvin — Wed, 22 Apr 2020 12:44:02 GMT

Hello,

If the bootloader is a secure bootloader, then you will not be able to generate a packet that the bootloader will accept.

I have no idea what their bootloader looks like. It may be based on our bootloaders, but they may have done something to it. Either way, what you would want to do is to try to update the bootloader itself to a bootloader that you have control of. I don't know if you have worked with bootloaders before, but I suggest that you check out this getting started blogpost.

If they have an old bootloader, it may be that it is not protected at all. See if you can generate a dfu image that contains your own bootloader (but practice one time with the guide before you take on that task).

If the bootloader is protected, you either need to get access to the private key, or else you need to manually program the devices with a programmer.

Since the device has a bootloader, how would you normally go about to update the firmware?

BR,

Edvin