Serial not working after DFU through BLE and nrfconnect

[Muhammad]

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

[Edvin]

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

[Muhammad]

Hi,

I have connected an RFID reader to the microcontroller and my board is also custom. Like button 4 of the development kit is used for something else in my custom board. That's why I have changed the button to some other pin to go to DFU mode. and it is working. but the issue is that the UART is not responding when I transmit some data through RFID. 

Now my application performs the DFU successfully and runs the application But the only issue is that the RFID is notr responding.  Should I need to change some configuration for UART in bootloader? if yes what should it be? 

[Edvin]

Have you tried to debug?

Since you talk about RFID and UART as they are the same thing, does your RFID reader use UART to communicate with the nRF? Did you change the UART pins in the application? Did you change them in the bootloader as well?

[Muhammad]

Hi,

Yes the RFID reader uses UART to communicate with nrf.

I have defined the UART pins in my custom application but I think I have not changed it in bootloader, can you guide me how to change it in bootloader?

I mean please guide me what should be the procedure to change the uart pins.

Thank you. 

[Edvin]

Does your bootloader use UART at all? Do you use a serial or a BLE bootloader? If you use a BLE bootloader, then that doesn't affect it. If you use a serial bootloader, then you should look in your function uart_dfu_transport_init() in nrf_dfu_serial_uart.c.

Or do you mean that the UART doesn't work in your application? Have you tried to debug? Does it give any information on why it doesn't work? Does anything else work?

[Muhammad]

I'm using the BLE bootloader. My application uses the UART and it's not working in applications after dfu. However everything else works fine.

If I run my application without bootloader then UART works fine

[Edvin]

Edvin said:

Have you tried to debug?

 Have you tried to debug the application? Does the UART initialize as expected? Perhaps you have a bug in your UART implementation in the new application that makes you believe that the uart isn't responding? 

I feel that I am working blind here. Can you be a bit more specific? Have you ensured that the UART is properly initialized? Have you tried to debug for UART interrupts? Do you get any? Perhaps you get the communication error from the UART event handler? The UART HW peripheral doesn't care if there is a bootloader present or not.

[Muhammad]

But why the UART works fine when we burn only the application to the nrf?

Also, I have debugged the application after adding bootloader, it seems that the UART does not respond when we push some data to it.  

it seems that the UART initializes but the responses I get are 

00> app_uart_put Response: NRF_SUCCESS
00> app_uart_put Error code : 0

in the UART event handler, I get the event APP_UART_TX_EMPTY.

But there is no error event in the event handler and nothing response from the UART.

Thanks

[Muhammad]

In event handler, the event APP_UART_DATA is not happening, it seems UART is not responding

[Muhammad]

Hi,

I have debugged the UART again using the Logic Analyser, it shows that when I try to push some data to UART it does not show on the logic analyzer and similar in case of receiving.

But when I run the same application without bootloader it shows data communication through the logic analyzer.

I'm a bit confused about tracking the main issue. My finding says maybe there is something on a bootloader that is affecting the UART in the new application, please guide me on this what could be the possible issue with the bootloader + application combined with the UART?

Thanks.