This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Serial not working after DFU through BLE and nrfconnect

Good day,

I have done DFU using the secure bootloader example in sdk16 using the nrf connect app. The DFU process completes successfully and the controller runs the new application firmware on the device. But I have a strange issue after DFU the serial port stopped working. There is an RFID reader attached to the serial port and stopped working after DFU even we debug the RFID after erasing the controller's flash and bootloader memory then again the serial port did not respond.

My main concern here is:

Is there any impact of the DFU/bootloader on the serial of the controller(nrf52832 chip)?

What should I do to track the issue?

Also when we completed the DFU after the restart we had some prints RTT viewer.

it gives following prints on the RTT viewer.
<info> app: Inside main
00> <debug> app: In nrf_bootloader_init
00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
00> <debug> nrf_dfu_settings: Using settings page.
00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <debug> app: Enter nrf_bootloader_fw_activate
00> <info> app: No firmware to activate. 
00> <debug> nrf_dfu_validation: CRC check of app failed. Return 1
00> <debug> app: App is valid
00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
00> <debug> app: Running nrf_bootloader_app_start with address: 0x00001000
00> <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0
  • If you can't see anything on the RX lines for the nRF, that doesn't have anything to do with the bootloader, right? Because that comes from an external device?

    Does the RFID send anything over UART to the nRF if the nRF doesn't send anything? Or does it? If it is waiting for a command from the nRF before it transmit anything, and you are not able to TX over UART, then that would at least explain that.

    Have you tried the ble_app_uart example together with a bootloader? You will see that this should work. Can you compare the ble_app_uart with your application? Do you set up the UART in a different way?

    Is there any way for me to reproduce this issue on a DK? Remember that I don't have your RFID device, so is it possible to reproduce with just a UART terminal?

  • I just want to show something that befor DFU when I burn the bootloader file to my nrf controller  I checked the memory layout of my board it is showing the following details.

    It's showing the soft device region in hex file becomes the application region when burning to the controller. do you think this might be an issue?

    Before DFU Memory Layout

    After DFU Memory Layout becomes

    Please suggest.

    Thanks

  • Hello,

    The DFU doesn't change the softdevice. If you read out the memory in the softdevice area, you will see that it isn't touched. It should be identical. (unless you actively update the softdevice over DFU, of course).

    It is only nRF Connect for Desktop that doesn't always understand what is placed in the specific sections.

    BR,
    Edvin

  • Okay, but my issue still persists.

    I just want you to know that my configuration and hardware are following

    I have nrf52832 chip on custom board

    I'm using secure bootloader ble with s112

    Now my concern is that I have seen in the bootloader project file

    but my custom board consist of the nrf52832. could this be the issue that the bootloader is using different chip pins configuration. 

    I also tried to change this nrf52810_xxA to nrf52832 but it seems that it gave me some error.

  • Ok, one step back:

    Your application is starting after the DFU? Do you see any log output from the application? Do you check the return codes for your UART calls? Did you try to debug it?

     

    Edvin said:
    Does the RFID send anything over UART to the nRF if the nRF doesn't send anything? Or does it? If it is waiting for a command from the nRF before it transmit anything, and you are not able to TX over UART, then that would at least explain that.

     

    Edvin said:
    Have you tried the ble_app_uart example together with a bootloader? You will see that this should work. Can you compare the ble_app_uart with your application? Do you set up the UART in a different way?

     

    Edvin said:
    Is there any way for me to reproduce this issue on a DK? Remember that I don't have your RFID device, so is it possible to reproduce with just a UART terminal?
Related