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

Logs from the QSPI application using XiP

Hi,

I want to run QSPI application example on my nRF52840DK (PCA10056) board with logs seen via UART. I successfully uploaded QSPI bootloader example and Blinky SysTick example to my board. It's running ok and I can see the logs from QSPI bootloader on the UART. 

But when I add logs to the Blinky SysTick example then the QSPI bootloader works fine (I can see the logs from QSPI bootloader), but the program from external flash crashes on line 613 in nrf_fprintf_fmt() function from nrf_fprintf_format.c file, after NRF_LOG_FLUSH() call and I can't see the logs. 

The code snippet from modified Blinky SysTick example that I use:

/**@brief   Initialize logging. */
static void log_init(void)
{
    ret_code_t rc = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(rc);
    NRF_LOG_DEFAULT_BACKENDS_INIT();
}

int main(void)
{
    ret_code_t rc;

    /* Configure LED-pins as outputs. */
    bsp_board_init(BSP_INIT_LEDS);

    /* Init systick driver */
    nrf_drv_systick_init();

    log_init();

    while (true)
    {
        for (int i = 2; i < 4; i++)
        {
            bsp_board_led_invert(i);
            nrf_drv_systick_delay_ms(500);
            NRF_LOG_RAW_INFO("test");
            NRF_LOG_FLUSH();
        }
    }
}

I've also modified some parameters in sdk_config in comparison to sdk_config.h from the example:

#define NRF_LOG_BACKEND_RTT_ENABLED 0 
#define NRF_LOG_BACKEND_UART_ENABLED 1 
#define NRF_LOG_DEFERRED 0 
#define NRF_LOG_ALLOW_OVERFLOW 0 
#define SEGGER_RTT_CONFIG_DEFAULT_MODE 2 
#define NRFX_SYSTICK_ENABLED 1

I'm using CMake in my project. 

Parents
  • I do not see any hardfaults, but i also do not see any logs from blinky systick example pushed to uart.

    I modified the sdk_config.h file with the same variables like you did, but there is no hardfault.

    I forgot to mention that the hard fault appeared when I moved the program in the memory of external flash. To do that I changed flash origin in gcc_nrf52.ld linker script of BlinkySysTick example:
     

    MEMORY
    {
      FLASH (rx) : ORIGIN = 0x12010000, LENGTH = 0x100000
      RAM (rwx) :  ORIGIN = 0x20000000, LENGTH = 0x40000
    }

    And I've also changed QSPI_XIP_START_ADDR in qspi_bootloader main.c file to:

    #define QSPI_XIP_START_ADDR      0x12010000
         

    When the program was moved from the beginning of external flash memory as you can see above the hard fault appeared. When the program was put at the beginning of external flash memory, then there was no hard fault but the UART logs also didn't show up.

Reply
  • I do not see any hardfaults, but i also do not see any logs from blinky systick example pushed to uart.

    I modified the sdk_config.h file with the same variables like you did, but there is no hardfault.

    I forgot to mention that the hard fault appeared when I moved the program in the memory of external flash. To do that I changed flash origin in gcc_nrf52.ld linker script of BlinkySysTick example:
     

    MEMORY
    {
      FLASH (rx) : ORIGIN = 0x12010000, LENGTH = 0x100000
      RAM (rwx) :  ORIGIN = 0x20000000, LENGTH = 0x40000
    }

    And I've also changed QSPI_XIP_START_ADDR in qspi_bootloader main.c file to:

    #define QSPI_XIP_START_ADDR      0x12010000
         

    When the program was moved from the beginning of external flash memory as you can see above the hard fault appeared. When the program was put at the beginning of external flash memory, then there was no hard fault but the UART logs also didn't show up.

Children
  • I am able to reproduce your issue after changing the base address in the linker file and in the bootloader app. I am not sure yet what causes this but this needs some debugging. But why do you need to change the base address of the application? Technically it should run finie, but i am guessing that that one of the two example have a bug that do not bode well with this configuration change. 

    How are you debugging your application? Are you using a debugger with a mode to just latch to the running program? I tried to use SES which did not work. I will try using Ozone as i am not good with debugging with gdb

Related