• State Verified Answer
  • Replies 12 replies
  • Subscribers 63 subscribers
  • Views 9173 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 104782
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRFToobox on Android not recognizing changes in application type running on Nordic pcb

Paul Russell

Today nRF Toolbox App on my Android 5.0 phone is only recognizing HRM code running on my nRF5182-mkit, not other examples.

  • Today nRFToobox and nRFUART2.0 Apps both report "The Device Does not have the required services" when I try anything other than HRM code yesterday and today.

  • Two days ago it was allowing me to easily switch between code on the mkit, but then something changed. It was about same time as the latest nRFToolbox update on playstore. Funnily enough it was just after the previous Nordic updates on playstore that this all started working, as two weeks ago it wasn't working with similar issue. Did a fix get undone?

  • nRF-MCP App is shows changes in Device Name when I run other sample code on my mkit (Thermometer, UART Loopback, HRM, etc.)

  • I tried wiping the cache in the Android 5.0 phone, no effect

  • I can capture with nRF-MCP or Sniffer if that will help (just tell me what you need, I'm not very familiar with either of those)

Any help appreciated! Paul

Parents
  • 0

    I have been able to reproduce this on Android 4.4.4, and did some investigating.

    This is actually a Android bug, not a nRF Toolbox/nRF Master Control Panel bug.

    On Android 4.3 the cache was cleared if you restarted Bluetooth, but this does not happen in 4.4 (and 5). I think this modification was on purpose.

    Attribute catching is explained in Vol 3, Part G, Section 2.5.2 in the Bluetooth Core Specification 4.2.

    If GATT based services on the server cannot be changed during the usable lifetime of the device, the Service Changed characteristic shall not exist on the server and the client does not need to ever perform service discovery after the initial service discovery for that server.

    This means that if the Service Changed characteristic doesn't exist, Android can cache the attributes.

    For clients that have a trusted relationship (i.e. bond) with the server, the attribute cache is valid across connections. For clients with a trusted relationship and not in a connection when a service change occurs, the server shall send an indication when the client reconnects to the server.

    This means that if the devices are bonded Android can cache the attributes.

    For clients that do not have a trusted relationship with the server, the attribute cache is valid only during the connection. Clients without a trusted relationship shall receive an indication when the service change occurs only during the current connection.

    This means that if the devices are not bonded, Android can cache the attributes, but they must be cleared between every connection. Android do not do this.

    When you disconnect from Master Control Panel the cache is manually cleared. But this is not done in nRF Toolbox.

    This should only be a problem in development because the DFU procedure also manually clears the cache.

    The workaround is to do a disconnect in Master Control Panel if you change apps.

    The service changed characteristic is included in the SDK examples by setting IS_SRVC_CHANGED_CHARACT_PRESENT to 1.

Reply
  • 0

    I have been able to reproduce this on Android 4.4.4, and did some investigating.

    This is actually a Android bug, not a nRF Toolbox/nRF Master Control Panel bug.

    On Android 4.3 the cache was cleared if you restarted Bluetooth, but this does not happen in 4.4 (and 5). I think this modification was on purpose.

    Attribute catching is explained in Vol 3, Part G, Section 2.5.2 in the Bluetooth Core Specification 4.2.

    If GATT based services on the server cannot be changed during the usable lifetime of the device, the Service Changed characteristic shall not exist on the server and the client does not need to ever perform service discovery after the initial service discovery for that server.

    This means that if the Service Changed characteristic doesn't exist, Android can cache the attributes.

    For clients that have a trusted relationship (i.e. bond) with the server, the attribute cache is valid across connections. For clients with a trusted relationship and not in a connection when a service change occurs, the server shall send an indication when the client reconnects to the server.

    This means that if the devices are bonded Android can cache the attributes.

    For clients that do not have a trusted relationship with the server, the attribute cache is valid only during the connection. Clients without a trusted relationship shall receive an indication when the service change occurs only during the current connection.

    This means that if the devices are not bonded, Android can cache the attributes, but they must be cleared between every connection. Android do not do this.

    When you disconnect from Master Control Panel the cache is manually cleared. But this is not done in nRF Toolbox.

    This should only be a problem in development because the DFU procedure also manually clears the cache.

    The workaround is to do a disconnect in Master Control Panel if you change apps.

    The service changed characteristic is included in the SDK examples by setting IS_SRVC_CHANGED_CHARACT_PRESENT to 1.

Children
Related