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]

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.

[Edvin]

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?

[Muhammad]

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

[Edvin]

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

[Muhammad]

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.

[Edvin]

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?