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
Parents
  • Hello,

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

     There shouldn't be.

    Are you completely sure that the application is actually is starting? I see that the log says it is, so I do believe you, but the line CRC check of app failed. Return 1 concerns me. Why did it return this? I see that this function is called from two different places. Can you please check the call stack of the execution of this? Where was it called from?

    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

    Have you tried to analyze the UART pins after adding the bootloader using a logic analyzer? Is there any data going on the pins? What GPIOS do you use for the UART?

    How do you determine it isn't working? Do you debug? Have you dealt with bootloader settings when you debug? How do you generate the bootloader settings or the DFU image of your application?

    Did you do any changes to the bootloader project? Or is it identical to the project in a new unmodified unzip of the SDK, other than the public and private key set? 

    I get almost the same log, but in mine it doesn't have the "CRC check of app failed" : 

    00> <info> app: Inside main
    00> 
    00> <debug> app: In nrf_bootloader_init
    00> 
    00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    00> 
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> 
    00> <debug> nrf_dfu_settings: Using settings page.
    00> 
    00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <debug> app: Enter nrf_bootloader_fw_activate
    00> 
    00> <info> app: No firmware to activate.
    00> 
    00> <debug> app: App is valid
    00> 
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <debug> app: Running nrf_bootloader_app_start with address: 0x00001000
    00> 
    00> <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0
    00> 

    Sorry, this was a bit messy. A short summary:

    1: Any changes in the bootloader project?

    2: Callstack to "CRC check of app failed. Return 1"?

    3: Did you analyze the UART after adding the bootloader?

    4: How do you upload your application? Have you tried to debug the application after adding the bootloader? If not, are you sure that it is the UART that doesn't work, and that there aren't any other bugs in the application causing it to stop before it reaches the UART part? Are you able to see any logging from the application?

    Best regards,

    Edvin

Reply
  • Hello,

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

     There shouldn't be.

    Are you completely sure that the application is actually is starting? I see that the log says it is, so I do believe you, but the line CRC check of app failed. Return 1 concerns me. Why did it return this? I see that this function is called from two different places. Can you please check the call stack of the execution of this? Where was it called from?

    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

    Have you tried to analyze the UART pins after adding the bootloader using a logic analyzer? Is there any data going on the pins? What GPIOS do you use for the UART?

    How do you determine it isn't working? Do you debug? Have you dealt with bootloader settings when you debug? How do you generate the bootloader settings or the DFU image of your application?

    Did you do any changes to the bootloader project? Or is it identical to the project in a new unmodified unzip of the SDK, other than the public and private key set? 

    I get almost the same log, but in mine it doesn't have the "CRC check of app failed" : 

    00> <info> app: Inside main
    00> 
    00> <debug> app: In nrf_bootloader_init
    00> 
    00> <debug> nrf_dfu_settings: Calling nrf_dfu_settings_init()...
    00> 
    00> <debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    00> 
    00> <debug> nrf_dfu_settings: Using settings page.
    00> 
    00> <debug> nrf_dfu_settings: Copying forbidden parts from backup page.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <debug> app: Enter nrf_bootloader_fw_activate
    00> 
    00> <info> app: No firmware to activate.
    00> 
    00> <debug> app: App is valid
    00> 
    00> <info> nrf_dfu_settings: Backing up settings page to address 0x7E000.
    00> 
    00> <debug> nrf_dfu_settings: Destination settings are identical to source, write not needed. Skipping.
    00> 
    00> <debug> app: Running nrf_bootloader_app_start with address: 0x00001000
    00> 
    00> <debug> app: Disabling interrupts. NVIC->ICER[0]: 0x0
    00> 

    Sorry, this was a bit messy. A short summary:

    1: Any changes in the bootloader project?

    2: Callstack to "CRC check of app failed. Return 1"?

    3: Did you analyze the UART after adding the bootloader?

    4: How do you upload your application? Have you tried to debug the application after adding the bootloader? If not, are you sure that it is the UART that doesn't work, and that there aren't any other bugs in the application causing it to stop before it reaches the UART part? Are you able to see any logging from the application?

    Best regards,

    Edvin

Children
Related