nrf52820 dfu

[shsh]

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 0x3E000.
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> <warning> nrf_dfu_settings: No additional data erased
00> 
00> <info> nrf_dfu_settings: Backing up settings page to address 0x3E000.
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

C:\Users\Wzc\Desktop\nrf52820>nrfutil settings generate --family NRF52QFAB --application nrf52820_xxaa.hex --application-version 1 --bootloader-version 1 --bl-settings-version 2 settings.hex

Note: Generating a DFU settings page with backup page included.
This is only required for bootloaders from nRF5 SDK 15.1 and newer.
If you want to skip backup page generation, use --no-backup option.

Generated Bootloader DFU settings .hex file and stored it in: settings.hex

Bootloader DFU Settings:
* File:                     settings.hex
* Family:                   nRF52QFAB
* Start Address:            0x0003F000
* CRC:                      0x23A3546F
* Settings Version:         0x00000002 (2)
* App Version:              0x00000001 (1)
* Bootloader Version:       0x00000001 (1)
* Bank Layout:              0x00000000
* Current Bank:             0x00000000
* Application Size:         0x00001BA0 (7072 bytes)
* Application CRC:          0x3D49775F
* Bank0 Bank Code:          0x00000001
* Softdevice Size:          0x00000000 (0 bytes)
* Boot Validation CRC:      0x2CE0301F
* SD Boot Validation Type:  0x00000000 (0)
* App Boot Validation Type: 0x00000001 (1)

This is the command I used to generate setting.hex.The primary address of my app is 0x19000.

This is my hex distribution. The library used is nRF5_SDK_17.1.0_ddde560.
Now the app is not functioning properly. Why is that?
The log indicates that the jump has been made, but the app did not execute.
thanks

[Vidar Berg]

Hello,

The settings page looks to be correctly generated. The bootloader also sees it as valid since it does try to jump to the application. Please try to read out the CPU registers after the jump to see if this may provide us with some more clues as to what's wrong.

Reading the CPU register with nrfutil from command line:

$ nrfutil device cpu-register-read  

Best regards,

Vidar

[shsh]

What about this one?

nrfutil device cpu-register-read
error: unrecognized subcommand 'cpu-register-read'

[Vidar Berg]

Hi,

Thanks. The readout shows that a fault exception has been raised. Are you building the bootloader with the default optimization setting? Reason for asking is that the jump_to_addr() function is known to fail if compiler optimization is not enabled.  It's because the implementation assumes that the input arguments will not be pushed on stack.

If you need to troubleshoot this further, I suggest you start a debug session with your bootloader project and place a breakpoint in jump_to_addr() and try to single step from there to see if you can see when the fault is triggered.

Regarding the failing nrfutil command, it seems like you are using and older version. To upgrade, run: nrfutil self-upgrade && nrfutil upgrade.

[shsh]

uint32_t err_code;
	clocks_start();
	    const app_uart_comm_params_t comm_params =
      {
          RX_PIN_NUMBER,
          TX_PIN_NUMBER,
          RTS_PIN_NUMBER,
          CTS_PIN_NUMBER,
          UART_HWFC,
          false,
#if defined (UART_PRESENT)
          NRF_UART_BAUDRATE_921600
#else
          NRF_UARTE_BAUDRATE_115200
#endif
      };

    APP_UART_FIFO_INIT(&comm_params,
                         UART_RX_BUF_SIZE,
                         UART_TX_BUF_SIZE,
                         uart_error_handle,
                         APP_IRQ_PRIORITY_LOWEST,
                         err_code);

   // APP_ERROR_CHECK(err_code);

//#ifndef ENABLE_LOOPBACK_TEST
    //printf("\r\nUART example started.\r\n");
	
	nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
    spi_config.ss_pin   = SPI_SS_PIN;
    spi_config.miso_pin = SPI_MISO_PIN;
    spi_config.mosi_pin = SPI_MOSI_PIN;
    spi_config.sck_pin  = SPI_SCK_PIN;
	spi_config.frequency  = NRF_DRV_SPI_FREQ_8M;
    nrf_drv_spi_init(&spi, &spi_config, spi_event_handler, NULL);
		
    
//    err_code = esb_init();
//    APP_ERROR_CHECK(err_code);

//    NRF_LOG_DEBUG("Enhanced ShockBurst Receiver Example started.");

//    err_code = nrf_esb_start_rx();
//    APP_ERROR_CHECK(err_code);

    while (true)
    {
		
		//nrf_gpio_pin_clear(SPI_SS_PIN);
		m_tx_buf[0]++;
		//printf("%d\r\n",m_tx_buf[0]);
		nrf_drv_spi_transfer(&spi, m_tx_buf, m_length, NULL, NULL);
		//nrf_gpio_pin_set(SPI_SS_PIN);
//		app_uart_put((uint8_t)m_tx_buf[0]);
		nrf_delay_ms(1);
    }
}

您好，我刚刚做了一个调试，发现应用程序可以启动，但只执行一次就卡住了。这很奇怪，因为它不会发生在裸机应用程序中。

[shsh]

Look at this picture. There is an abnormal situation in this picture. That is, after I download the program on the left into the chip, the chip will generate three programs of approximately the same size occupying bytes in the "setting file" area. Is this normal?

[Vidar Berg]

Please debug the application then to see where the program hangs. 

shsh said:

您好，我刚刚做了一个调试，发现应用程序可以启动，但只执行一次就卡住了。这很奇怪，因为它不会发生在裸机应用程序中。

Please repost this in English.

shsh said:

Look at this picture. There is an abnormal situation in this picture. That is, after I download the program on the left into the chip, the chip will generate three programs of approximately the same size occupying bytes in the "setting file" area. Is this normal?

The settings and MBR parameter page are updated by the bootloader at runtime, so yes, it is expected to change.