Missing code?

If I build there are no errors. If I launch the debug, I have the message "No source available for 0xf8832200".

I dont't know what to do.

  • 0xf8832200 i not a valid address for the Program COunter on a Synergy device, hence there will be no source code available for that address. What is the base address your program is linker to, is it 0? Are you using a bootloader?
  • In reply to Jeremy:

    This software that I want to use has the function of bootloader.
  • In reply to stage:

    The program that you are currently debugging, what is the base address it is linked to? If it is not 0, then additional steps are required to set up a debug session in e2studio. Since the Cortex-M boots from address 0, the intial stack pointer and inital program counter are fetched from the vector table that starts at address 0.
  • In reply to Jeremy:

    I don't know where I can find this info... Can you explain me? Thanks
  • In reply to stage:

    If you have not edited the default linker script, then the application will be linked at the default location, starting at address 0. This will be shown in the linker script :-

    /* Linker script to configure memory regions. */
    MEMORY
    {
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x0200000 /* 2M */
    RAM (rwx) : ORIGIN = 0x1FFE0000, LENGTH = 0x00A0000 /* 640K */
    DATA_FLASH (rx) : ORIGIN = 0x40100000, LENGTH = 0x0010000 /* 64K */
    QSPI_FLASH (rx) : ORIGIN = 0x60000000, LENGTH = 0x4000000 /* 64M, Change in QSPI section below also */
    SDRAM (rwx) : ORIGIN = 0x90000000, LENGTH = 0x2000000 /* 32M */
    ID_CODES (rx) : ORIGIN = 0x0100A150, LENGTH = 0x10 /* 16 bytes */
    }

    The flash address range starts from 0. Also in the .map file the vectors start at address 0 :-

    .text 0x00000000 0x38b4
    0x00000000 __ROM_Start = .
    *(.vectors)
    .vectors 0x00000000 0x40 ./synergy/ssp/src/bsp/cmsis/Device/RENESAS/S5D9/Source/startup_S5D9.o
    0x00000000 __Vectors
    *(SORT(.vector.*))
    0x00000040 __Vectors_End = .
  • In reply to Jeremy:

    This is what I have found.
    The lenght of QSPI_FLASH has been modified.

    /* Linker script to configure memory regions. */
    MEMORY
    {
    FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x0400000 /* 4M */
    RAM (rwx) : ORIGIN = 0x1FFE0000, LENGTH = 0x00A0000 /* 640K */
    DATA_FLASH (rx) : ORIGIN = 0x40100000, LENGTH = 0x0010000 /* 64K */
    QSPI_FLASH (rx) : ORIGIN = 0x60000000, LENGTH = 0x250000 /* 4MB */
    SDRAM (rwx) : ORIGIN = 0x90000000, LENGTH = 0x2000000 /* 32M */
    }



    .text 0x00000000 0x14b84
    0x00000000 __ROM_Start = .
    *(.vectors)
    .vectors 0x00000000 0x1c0 ./synergy/ssp/src/bsp/cmsis/Device/RENESAS/S7G2/Source/startup_S7G2.o
    0x00000000 __Vectors
    0x000001c0 __Vectors_End = .
    0x000001c0 __Vectors_Size = (__Vectors_End - __Vectors)
    0x000001c0 __end__ = .
  • In reply to Jeremy:

    When the debugger is connected, if you open a memory window at address 0, what do you see. E.g. :-

     

  • In reply to Jeremy:

    Something like this

  • In reply to stage:

    And this is what I see from debug window:

  • In reply to stage:

    A segmentation fault has occured, the execution of the code has gone wrong and ended up at an illegal address. This could be caused by a thread stack being too small, or a pointer being used that hasn't been intialised correctly.

    To check for a stack over flow put a breakpoint in bsp_group_irq.c:-

     

     

    and see if the HW stack monitor generates an NMI interrupt.

  • In reply to Jeremy:

    I put breakpoints inside the NMI Handler but execution never stops in one of them.
  • In reply to stage:

    A segmentation fault has occured, these can be difficult to track down. However this looks a little strange :-

     

     

    The address of g_qspi_ctrl() is in RAM. Is this function actually linked to a RAM address?

  • In reply to Jeremy:

    I checked and in the .map file I can read this:

    g_qspi_ctrl 0x18 ./src/synergy_gen/main_thread.o


    COMMON 0x1ffe1eb8 0x1ac ./src/synergy_gen/main_thread.o
    0x1ffe1eb8 g_main_to_source_queue
    0x1ffe1ef0 g_error_queue
    0x1ffe1f28 g_data_in_queue
    0x1ffe1f60 main_thread
    0x1ffe2010 g_source_to_main_queue
    0x1ffe2048 g_flash_ctrl
    0x1ffe204c g_qspi_ctrl
  • In reply to stage:

    Are those variables? If so why does it appear that g_qspi_ctrl() is a function at 0x1ffe1d80?
  • In reply to Jeremy:

    I also would say that they are functions.