9 years, 1 month ago.

BLE App reverting to DFUTarg on startup

Note : This is now solved, answer at the end of this question

Ok, this is a bit of a long question, but I am doing my best to be thorough :

Hardware

• nrf51822 using mbed libraries/IDE on custom hardware.
• Target is the Nordic NRF51822 with FOTA selected.
• Currently using older revisions of the mbed and BLE_API libraries for reasons explained below.
• The board has the default FOTA starter app loaded to it. This app contains S110 7_0_0, boot loader at 0x3c000, and a default application called nRF5x with device information, DFU, and (i think) uart services
• The initial image is from the shadow FOTA image on this page - https://developer.mbed.org/platforms/Nordic-nRF51822-FOTA/
• There is another IC connected to the nrf chip over a handful of pins. The other IC does not connect to the SWD or SWCLK lines of the nrf chip.

TLDR/ My Hypothesis

From what I have read, it looks like the bootloader is taking control from the application in the power-up state, and relinquishing control after a little while. Mostly I am wondering if anyone knows why, and what I can do about it

The full Description

• Upon some power-up states, our device is showing up as DFUTarg with only the DFU service. Not as the app that it should be showing up as. This is the case regardless (or so it seems) of what code sits on the other IC on the board.
• After about a minute or two the device will then switch over to showing up as whatever the app code wants it to.

1. In the case of the default code pre-loaded to the board, that is nRF5x
2. This is better than nothing, but it's not going to fly in our product

• This is not an issue of iOS or Android caching- I have verified this issue on a number of boards, with a handful of devices, a few different apps, and the MCP on a computer.
• There are 2 distinct power-up modes that have different results

1. If I power up the device by toggling the SPDT on/off switch to on (this controls flow from battery to IC) the device will start up in the DFUTarg bootloader mode
2. If I power up the device by plugging in external power (switch already set to on) then it will start up in the Application space and all is fine
3. my guess is that the on/off switch is inducing some jitter/bounce to the power line that is throwing it into bootloader mode

• I only first noticed this issue yesterday- I have no idea how or why this would only suddenly be a problem- I assume it was probably always there, but unbeknownst to me.

The Backstory/Setup

• We are using the nrf51822 via mbed to program an nrf51822 chip that is acting as a go-between in our product between our main IC and a phone. The end use case is in a product- in retrospect I regret choosing to use mbed as it is clearly not stable or mature enough for something like this, but that's for another time.
• At this point the boards are pre-flashed and assembled, and they are bootloaded with the default app package I described above, we are basically waiting on getting this issue resolved before we can put the final firmware on them. This is a big problem for me
• Because we already have the S110 7.0.0 softdevice on all boards, I am using older version of the mbed libraries and BLE_API. Also see my note about instability- I'm not updating anything at this point.
• We will be loading the final nrf application software to the boards wirelessly via the master control panel before packout. If necessary we can do a wired programming, but as we need them field-updateable that is only a short term solution. We also really don't want to have to do this over a wired connection.
• It looks like maybe the best option is to replace the bootloader and app wirelessly, assuming this issue requires an alteration to the bootloader

Thanks, Steve

EDIT, I have solved the issue with Rohit's excellent help. The cause of the issue is below

The bootloader was sending me into the DFUTarg state upon startup, and then moving to the app after it timed out.This is due to the bootloader that I'm using looking for the DFU button (pin 7 on the NRF dev boards) being low upon startup. The bootloader image that I am using is this one - https://developer.mbed.org/platforms/Nordic-nRF51822-FOTA/ .

The issue is that the hardware on my board was holding that particular pin low upon startup. When I stopped doing this the issue went away. For those of you doing custom hardware, beware!