DFU works with nRF52 DK but not with custom board using Fanstel BC832 module

[tclemcpe]

My team is in the process of developing a product that uses the Fanstel BC832 module and have been running into issues trying to implement buttlonless DFU in our application. I believe I have added the buttonless dfu service correctly by following the few tutorials that are available where I have it working fine using the nRF52 DK. When I test it with my custom device, the custom service I created does not show up from the nrfConnect app and can't read any of the characteristics, only the secure DFU service shows up. When I debug my device I get no error codes when I initialize my services. I am wondering if it has something to do with my RAM and ROM setting placements but I am unsure. I am using SDK 15.3, S132 6.1.1 and the secure bootloader from the SDK package. I can share the code just not publicly so if a Nordic representative is available, I could use a little guidance.

[BinderT]

This is for GCC in sdk_config.h there is something similar in other environments. This Macro needs to be adjusted to use custom uuids. 

// <o> NRF_SDH_BLE_VS_UUID_COUNT - The number of vendor-specific UUIDs. 
#ifndef NRF_SDH_BLE_VS_UUID_COUNT
#define NRF_SDH_BLE_VS_UUID_COUNT 2
#endif

If you compile in debug mode with SDH debug enable it will tell you the RAM and ROM settings.

// <e> NRF_SDH_BLE_LOG_ENABLED - Enable logging in SoftDevice handler (BLE) module.
//==========================================================
#ifndef NRF_SDH_BLE_LOG_ENABLED
#define NRF_SDH_BLE_LOG_ENABLED 1
#endif

Compile makefile in debug mode. Add the -DDEBUG to the c compile flags.
Do a clean build after changing the settings.

[tclemcpe]

I do have the UUID count set to 2 and the SDH debug enabled already, here is what SES outputs:

and the placement settings:

Like I said it is working just fine on the Development kit, just not on the Fanstel chip. One thing I have noticed is that the connect app says the Dk board uses NRF52832_xxAA_REV2 while the fanstel module is NRF52832_xxAA_REV1. 

[Vidar Berg]

Hi,

The RAM and ROM settings should be the same as both use the xxAA variant. Also, the IC revision should not be relevant to this. Rev.2 is only including some errata fixes related to the radio, more details in this document: IN105 Informational Notice v1.0

When I test it with my custom device, the custom service I created does not show up from the nrfConnect app and can't read any of the characteristics, only the secure DFU service shows up

It sounds like the device stays in bootloader DFU mode instead of booting the main application. It could be because of a different pinout. The original bootloader will for instance enter DFU mode if the "bootloader button" pin is pulled low on startup. 

I would suggest opening the bootloader project in SES and try to debug it on the custom board to see if any of the checks in nrf_bootloader.c::dfu_enter_check() return true. You may also go over the NRF_BL_DFU_ENTER_METHOD_* configurations in sdk_config.h to make sure it correctly configured for the custom board. 

[tclemcpe]

Hi Vidar,

At first I thought as well that the application just wasn't running and it was stuck in bootloader mode, but I am very sure it is not. My custom board still advertises with the correct name and parameters, the LED's blink exactly as I have set them to and it goes to sleep/wakes up exactly how I have programmed it. I still debugged the bootloader from my custom board and the dfu_enter_check() function does not return true for any of the if statements and it successfully gets to nrf_bootloader_app_start() in the init function.

For the SDK_config settings I have NRF_BL_DFU_ENTER_METHOD_BUTTON checked with the pin set to P0.16 (on my Fanstel module this pin is unconnected in my schematic), PINRESET is unchecked, GPREGRET is checked, and BUTTONLESS is unchecked. These are the default settings and I have not changed them from opening the example, do these seem correct for use with a buttonless dfu application?

I am guessing this has something to do with my application code, I am just not seeing where or why as it does not show any errors through initialization and can loop through my main application loop. 

[Vidar Berg]

Hi,

Agree, it seems like it's not a bootloader problem. I read your original description again and I must have overlooked the fact that you had already verified the return values from service initialization in your app. 

Are you using nRF connect on iPhone by any chance? In that case, maybe this particular device has been cached by your phone (caching allows the phone to skip service discovery on following connections). Please try to toggle flight mode enable or reboot the phone. This will clear any attribute cache on the phone so that it has to perform new service discovery on the next connection.

[tclemcpe]

So I have both an IPhone and an Android but had mainly been using Android because that is what I normally use. The custom service doesn't show up on my Android with nRF Connect but I tried it with the IPhone and it does. i then connected it with my Android phone and told it to re-read the services and then it shows up. The device is now working fine I guess thats what the problem was. But even after restarting my device, turning bluetooth off and on, unbonding and bonding the device again, it doesn't show the custom service when i first connect the device, i still have to tell it to re-read the services. Either way it seems to have been just fine all along the app just didn't show that it was. Thanks for the help Vidar!

[Vidar Berg]

Thanks for the update. Android exposes the API to re-read services as opposed to iOS. The only way to re-read the service on iOS is to clear the cache somehow.

I'd recommend using the Service changed characteristic (enabled in sdk_config) If the service table is dynamic, or if there is a chance that it may change in the future (through a DFU). There is a good summary of attribute caching/service changed in core spec, vol 3, part g, section 2.5.2.