Attachments (5) Download All
Nordic Case Info
  • Case ID: 241312
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Application service UUID gone after secure OTA DFU

SK

Hello, 

I am using nRF52832 on SES v4.12 with SDK v15.3 and SD v6.1.1 on a custom board.

Background: 

I want to perform OTA DFU and with that i have two services enabled (secure dfu buttonless and NUS). I was facing OTA DFU issue in which i was getting CRC does not match error. This has been resolved here - https://devzone.nordicsemi.com/f/nordic-q-a/55653/dfu-crc-does-not-match-error

So, i have been able to perform OTA update. 

The package that i created includes BL+SD+APP. 

Problem: 

Once i perform the update and connect again, i only see one service, which is Secure DFU service and the other which is the main application service ID (NUS) is gone. I looked in the forum and found this -https://devzone.nordicsemi.com/f/nordic-q-a/39982/after-ota-dfu-bootloader-application-gone

But i do not quite fully understand as to what is to be done here. Could you please highlight on what is required for a proper DFU process? From what i understand from the post and infocenter that it is still a single update, so BL+SD+APP merged together should work fine internally. 

EDIT:

Zip created has only application hex in it. BL+SD+APP is programmed directly using nrfjprog. 

Please let me know if you require more information. 

Thanks a lot!

-SK

  • 0 in reply to Aleksander Nowakowski

    oh alright, in that sense, yes.

    BTW, i tried again and this time i got 133 error. Attached. 

    Fullscreen Log 2019-12-18 17_32_29.txt Download
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    nRF Connect, 2019-12-18
    HELIOS_1 (FB:30:2F:3A:7F:01)
    V 17:30:44.401 Connecting to FB:30:2F:3A:7F:01...
    D 17:30:44.401 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D 17:30:45.147 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    D 17:30:45.190 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
    I 17:30:45.190 Connected to FB:30:2F:3A:7F:01
    V 17:30:45.228 Discovering services...
    D 17:30:45.228 gatt.discoverServices()
    I 17:30:45.856 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
    D 17:30:45.959 [Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDING (11)
    D 17:30:45.987 [Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)
    D 17:30:46.047 [Callback] Services discovered with status: 0
    I 17:30:46.047 Services discovered
    V 17:30:46.075 Generic Access (0x1800)
    - Device Name [R W] (0x2A00)
    - Appearance [R] (0x2A01)
    - Peripheral Preferred Connection Parameters [R] (0x2A04)
    - Central Address Resolution [R] (0x2AA6)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    One more 

    Fullscreen Log 2019-12-18 17_37_21.txt Download
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    nRF Connect, 2019-12-18
    HELIOS_1 (FB:30:2F:3A:7F:01)
    V 17:35:26.747 Connecting to FB:30:2F:3A:7F:01...
    D 17:35:26.747 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D 17:35:26.828 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    D 17:35:26.841 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
    I 17:35:26.841 Connected to FB:30:2F:3A:7F:01
    D 17:35:26.842 wait(1600ms)
    I 17:35:27.652 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
    I 17:35:27.971 Connection parameters updated (interval: 48.75ms, latency: 0, timeout: 5000ms)
    V 17:35:28.443 Discovering services...
    D 17:35:28.443 gatt.discoverServices()
    D 17:35:28.466 [Callback] Services discovered with status: 0
    I 17:35:28.466 Services discovered
    V 17:35:28.516 Generic Access (0x1800)
    - Device Name [R W] (0x2A00)
    - Appearance [R] (0x2A01)
    - Peripheral Preferred Connection Parameters [R] (0x2A04)
    - Central Address Resolution [R] (0x2AA6)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Aleksander Nowakowski
    Aleksander Nowakowski said:
    You need to select "Refresh services" in the top menu to clear the cache and do service discovery again

    This worked! so we will have to do everytime we try to do OTA DFU, then? 

  • 0 in reply to SK

    and it seems, sometimes i get that 133 error and other times ( which is 2/10) i get DFU done successfully. 

  • 0 in reply to SK

    Ideally, the app, after started after successful DFU, should send SC indication, just like the bootloader is sending when switched from app to bootloader mode. On Android you may force clear the cache, like nRF Connect does, but if you want to support iOS as well, there's no such API, not even hidden, so working SC is a must when working with bonded DFU.

    The errors 133 happen often, yes. The DFU lib does what it can to try to avoid them, tries many times sometimes, but, a specially on older Android devices and when the device is bonded, the 133 error is common. What phone are you testing on?

    If you have sniffer (for example this one: https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE) you may try to find out what's causing this 133 error. Usually it means that there was a packet lost, packet collision, some packets came too early or too late, or, when device is bonded, perhaps something with the encryption. Try putting phone and device close to each other to avoid interference, sometimes disabling wi-fi also helps, as I read in the Internet. 133 is a generic error when "something else" happens, so it may be almost anything.

    The 133 around 5 sec after connection attempt seems like the Connect Request was missed by the device and it continued to advertise instead. Retries should increase the chance of success.

  • 0 in reply to Aleksander Nowakowski
    Aleksander Nowakowski said:
    What phone are you testing on?

    I am testing on samsung S9+ currently.

    Aleksander Nowakowski said:
    133 is a generic error when "something else" happens, so it may be almost anything

    That's comforting to know :D 

    Yes, i will try it out by sniffing the packets and see if i can get somewhere with this error. 

    SK said:
    Would you know anything about this issue? https://devzone.nordicsemi.com/f/nordic-q-a/36346/a-problem-on-buttonless-dfu-bonding-valid

    This is what Hung said in the link i shared above

    "I think we found the root cause of the issue. When you set the MTU to something else not the default that the iPhone set when connected, the nrf_ble_gatt.c will try to request sd_ble_gattc_exchange_mtu_request() immediately right after CONNECTED event."

    . Would you know if it is corrected in v15.3? or is it still an issue? 

« 3 4 5 6 7
Terms of service