• State Not Answered
  • Replies 21 replies
  • Subscribers 61 subscribers
  • Views 4512 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 239812
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU issues on Android 10

AntonHellbe

Hi,

We are currently testing DFU upgrades on Android. In my current setup I have two different phones, a Sony one running Android 8 and a OnePlus running Android 10.

The bootloader uses bonds and the application uses the buttonless DFU service.

Entering the bootloader and performing a DFU upgrade through the nRFConnect App on the Sony phone works fine. No failures there.

However on the OnePlus there are some issues. The first issue is that when trigger a DFU with the new FW zip file the nRF52832 enters the bootloader, the OnePlus connects again, but at reconnect it receives "GATT_INVALID_HANDLE", like it does not receive the GATT_SERVICE_CHANGED notification or that it receives it too late.

The second issue is that sometime the application cannot enter the bootloader from the buttonless DFU service, these are the logs from the application when I'm writing to the characteristic from the OnePlus:

<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation
<info> app: Read/Write Authorization request.
<info> app: Writing peer data to the bootloader...
<error> app: Request to enter bootloader mode failed asynchroneously.
<info> app: Handle Value Confirmation

Hardware: nRF52832 PCA10040

SDK: v15.0

Softdevice: v6.0.0

Edit: added screenshots from LOG

  • 0

    Hi,

    Both these issues could be explained by missing service changed. Have you made sure the NRF_SDH_BLE_SERVICE_CHANGED is set to the same value in both the applications and bootloaders sdk_config.h? What is it?

  • 0 in reply to Einar Thorsrud

    Hi,

    Doubled checked that three or four times now: NRF_SDH_BLE_SERVICE_CHANGED 1.

    I found a similar issue here on devzone where the suggested solution was to move the DFU service to the top of the attribute table to line it up with the bootloader attribute table. In the application we are making changes to the attribute table quite often.

    Accidently closed the tab with that issue so I dont have think link at the moment, will try to find it again.

    Also In the application I have given the Peer Manager control over Service Changed Indications, could that have any consequences?

    Edit: Found the link

    / Anton

  • 0 in reply to Einar Thorsrud

    Hi again,

    Here is another screenshot from my OnePlus 5 running Android 9, attempting DFU through the NRF Connect App.

    I've never had any issues on this phone before.

  • 0 in reply to AntonHellbe

    Hi,

    I have not found any reports of similar issues with Android 10 specifically, but a possible explanation is if Service changed collides with MTU exchange. The timing can be different between phones and SW versions, so perhaps you incidentally see this on Android 10 on the OnePlus. If so, this could actually be a similar issue in your problem 1 and 2. Sniffer traces could be useful to see if this theory makes sense.

    For problem 2, can you try to trigger DFU mode by manually writing to the DFU characteristic in the nRF Connect app? Doing it manually should change the timing, and it would be interesting to see if you still get the issue with "Request to enter bootloader mode failed asynchroneously" or not.

    For problem 1, it would be good to delay the serviced changed indication from the bootloader do see if that fixes the issue.

  • 0 in reply to Einar Thorsrud

    Hi Einar,

    Problem 1:

    I dont think Service changed colliding with MTU exchange is a problem. There was a bug in SDK V15.0 that I have resolved with help from your team that skipped Service changed indications if there was an ongoing MTU Exchange.

    You can see that ticket here: Service changed indication MTU exchange

    Problem 2:

    The logs from the nRF52832 application that I provided in the post are me trying to write to the characteristic manually

Related