The Buttonless DFU Template Application is not working on a custom board

[Vu]

Hi,

I am currently working on a custom product that uses module BMD-300 from u-blox, which has nrf52382 chip in it. My application works fine and now I want to integrate the Secure DFU function into it. I programmed the board with the DFU test image sd_s132_bootloader_buttonless_with_setting_page_dfu_secure_ble_debug_without_bonds.hex but I could not see it advertising when I scan for devices on nrf Connect. Does anyone know what problem could cause it to not advertising? I am using sdk v15.0.0.

Thank you in advance.

[Turbo J]

The BMD-300 lacks the 32768 Hz RTC (LFXO) quarz crystal that most Nordic examples require. You need to change the LF clock configuration in the source code and recompile - or populate the quarz circuit on XTAL1/XTAL2.

[Vu]

I tried your suggestion but the problem still exists. I followed the instruction on this link Add Nordic DFU to SDK Example from u-blox, and then changed the clock configuration afterward, but I still could not see it on the nRF Connect Scanner.

Now I think the custom board may behave different than the eval board, so I go straight into modify my firmware, which I know is working, and the scanner can see the device. After following the instruction on the link above, I can connect to it through nRF Connect and see the DFU service, but the device is frozen after a few seconds. Same thing happened when I use nRF Connect on Android. The nRF Connect on iOS, on the other hand, can connect to the device without any problem, but it doesn't see the DFU service.

I know these maybe 2 different problems, but I just want to put it here in case you (or anybody) know the answer for the problems.

[Vu]

I debug the application with IAR. Here is the message I got:

"The processor has escalated a configurable-priority exception to HardFault. Exception occured at PC = 0x2dd22, LR = 0x2dd71"

In disassembly, 0x2dd22 and 0x2dd71 are in ble_conn_params.c. 0x2dd22 is at line 4 of this function:

static bool send_update_request(uint16_t conn_handle, ble_gap_conn_params_t * p_new_conn_params)
{
    ret_code_t err_code;
    err_code = sd_ble_gap_conn_param_update(conn_handle, p_new_conn_params);
    if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_BUSY)) // NRF_ERROR_BUSY means another conn_param_update request is pending.
    {
        send_error_evt(err_code);
    }
    return (err_code == NRF_SUCCESS);
}

    

and 0x2dd71 is at line 10 of this function:

static void update_timeout_handler(void * p_context)
{
    uint32_t                     conn_handle = (uint32_t)p_context;
    ble_conn_params_instance_t * p_instance  = instance_get(conn_handle);
    if (p_instance != NULL)
    {
        // Check if we have reached the maximum number of attempts
        if (p_instance->update_count < m_conn_params_config.max_conn_params_update_count)
        {
            bool update_sent = send_update_request(conn_handle, &p_instance->preferred_conn_params);
            if (update_sent)
            {
                p_instance->update_count++;
            }
        }
        else
        {
            p_instance->update_count = 0;

            // Negotiation failed, disconnect automatically if this has been configured
            if (m_conn_params_config.disconnect_on_fail)
            {
                ret_code_t err_code;
                err_code = sd_ble_gap_disconnect(conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);
                if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_INVALID_STATE)) // NRF_ERROR_INVALID_STATE means disconnect is already in progress.
                {
                    send_error_evt(err_code);
                }
            }
            // Notify the application that the procedure has failed
            if (m_conn_params_config.evt_handler != NULL)
            {
                ble_conn_params_evt_t evt;
                evt.evt_type = BLE_CONN_PARAMS_EVT_FAILED;
                evt.conn_handle = conn_handle;
                m_conn_params_config.evt_handler(&evt);
            }
        }
    }
}

From the log I can see that it happened after the BLE_GAP_EVT_DATA_LENGTH_UPDATE event. 

[Vu]

I also tested with the nRF Connect on Android and received "Error 133 (0x85): GATT ERROR"

[Vu]

I also want to clarify that I don't use bonding in my application.

[Edvin]

So now it isn't working anymore? I must say I am a bit confused about what's going on here. Did you try to monitor the log?

[Vu]

Okay sorry the confusion. Here is the summary of the problem so far:

- The whole DFU process is working okay with nRF Connect on iPhone. I can connect to the app, and download the new firmware through DFU service.

- With the same firmware, my application cannot connect to nRF Connect on both PC and Android phone. The application has a HardFault a few seconds after connected.

+ I did monitor the log, and it stops after the "BLE_GAP_EVT_DATA_LENGTH_UPDATE" event. There is no error message. I can show you the whole log if you need.

+ When I used nRF Connect on Android to connect to my application, I received "Error 133 (0x85): GATT ERROR" message on the Android app.

+ When I ran debugger with IAR, I got the message "The processor has escalated a configurable-priority exception to HardFault. Exception occured at PC = 0x2dd22, LR = 0x2dd71". The memory locations are shown in the comment above.

+ This problem is not related to the DFU bootloader I believe, because I took out the bootloader and the problem still exists.

[Vu]

Since it's not related to the original question, do you want me to open a new thread for it?

[Edvin]

Does this mean that sd_ble_gap_conn_param_update() returns something other than 0? If so, what does it return?

Did you do any changes to the bootloader project other than the pin configurations to match your custom PCB?

Have you tried to do a sniffer trace? I suspect that the nRF just stops responding if it is in fact a hardfault.

Have you possibly done any changes to the files that are common in the SDK? Can you try to unzip a new SDK, and copy paste the bootloader project into this SDK? Does the issue still occur?

What was the connection parameters that the phone or PC wants in the connection parameter update? A sniffer trace will show this, or you can try to debug, and look at the p_new_conn_params.

So:

1: Can you try with an unmodified SDK?

2: What is the p_new_conn_params in the send_update_request()? (and what is it when you connect with the iPhone?)

3: What does sd_ble_gap_conn_param_update() return?

[Vu]

The p_new_conn_params is:

When I connect with iPhone the send_update_request() is never called as it never reached my breakpoint there.

sd_ble_gap_conn_param_update() does not return as the hardfault is at 0x2dd76:

[Vu]

I want to clarify again that this has nothing with the bootloader project, the custom board only contains my own application and the soft device. The only file I change in SDK for my application project is the bsp.c in sdk\component subfolder.

[Edvin]

Oh, I am sorry. I thought the HardFault was in when the bootloader was running, but I see, it is in the application. I didn't see the comment that you took out the bootloader.

Can you try to turn off optimization and check what function call that is the last one that is called? Are you sure sd_ble_gap_conn_param_update() is called? Because the address that it refers to looks like it is outside the softdevice. You are using s132v6.0.0, right? Can you confirm that sd_ble_gap_conn_param() is called? If not, what is the last call that is called before the hardfault?

I can't say that I have seen this message before:

"The processor has escalated a configurable-priority exception to HardFault. Exception occured at ..." Where does this message come from?

Are there any functions that returns something other than NRF_SUCCESS? Have you removed  any of the APP_ERROR_CHECK(); calls that are softdevice related? Does the log say anything other that suggests that something is wrong? Can you send a copy of the log?

Is there any way for me to reproduce this?

Best regards,

Edvin