[SOLVED] GDBServer RTOS plugin development

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] GDBServer RTOS plugin development

    Hello,

    I'm developing a RTOS plugin for gdb server. Our os is based on FreeRTOS.

    I'm working with
    SEGGER J-Link GDB Server V6.34c Command Line Version
    JLinkARM.dll V6.34c (DLL compiled Aug 23 2018 10:59:29)

    During a debugging I found strange things.

    Loading RTOS plugin: /opt/SEGGER/JLink_V634c/GDBServer/RTOSPlugin_yOS_Debug.so...
    RTOS_GetVersion
    RTOS plugin (API v1.0) loaded successfully
    RTOS_Init(0x0x64fb60, 0x0e0000ff)
    RTOS plugin initialized successfully.
    RTOS_GetSymbols
    Received symbol: pxCurrentTCB (0x1FFF0548)
    Received symbol: pxReadyTasksLists (0x1FFF054C)
    Received symbol: xDelayedTaskList1 (0x1FFF0678)
    Received symbol: xDelayedTaskList2 (0x1FFF068C)
    Received symbol: pxDelayedTaskList (0x1FFF06DC)
    Received symbol: pxOverflowDelayedTaskList (0x1FFF06E0)
    Received symbol: xPendingReadyList (0x1FFF06A0)
    Received symbol: xTasksWaitingTermination (0x1FFF06B4)
    Received symbol: xSuspendedTaskList (0x1FFF06C8)
    Received symbol: uxCurrentNumberOfTasks (0x1FFF0544)
    Received symbol: uxTopUsedPriority (0x00000000)
    Received symbol: uxTopReadyPriority (0x1FFF06EC)
    Received symbol: vPortEnableVFP (0x000066C4)
    Received symbol: FreeRTOSDebugConfig (0x00000000)
    All mandatory symbols successfully loaded.
    ....
    Downloading 8 bytes @ address 0x0001D580 - Verified OK
    Downloading 1512 bytes @ address 0x0001D588 - Verified OK
    RTOS_SetThreadReg(0x7f4712bf6e53, 15, 0x00000000)
    Compare method "Programmed sectors, fastest method" is not supported for this device.
    ......
    Starting target CPU...
    ...Breakpoint reached @ address 0x00000B0C
    RTOS_UpdateThreads
    ERROR: Could not read FreeRTOS thread count from target @ 0x1fff0544(err = 0x1fff0500).
    RTOS_GetNumThreads() = 0
    Reading all registers


    Here is a list of questions:
    1. Why does gdbserver call RTOS_SetThreadReg with threadID = 0 in the middle of flashing?
    2. Why does gdbserver call RTOS_SetThreadReg before RTOS_ThreadUpdate call?

    3. Why does gdbserver return a positive error code for the following call?

    err = _pAPI->pfReadU32(addr, &thread_count);
    if (err != 0) {
    _pAPI->pfErrorOutf(
    "Could not read FreeRTOS thread count from target @ 0x%08x"
    "(err = 0x%08x).\n", addr, err);
    return err;
    }
    According to the doc int TARGET_ReadU32(U32 Addr, U32* pData);
    Return value
    = 0 Reading memory Ok.
    < 0 Reading memory failed.
    here is a report from gdbserver
    ERROR: Could not read FreeRTOS thread count from target @ 0x1fff0544(err = 0x1fff0500).
  • Hello,

    1. + 2. The GDB server is not aware of tasks (therefore you are writing the plug-in). So it just sends any "read register" or
    "write register" request to the plug-in first, which should decide by itself whether to handle or to reject it.

    The GDB server is not aware of the flash loading process, too. It calls RTOS_SetThreadReg() whenever the GDB client
    wants it to set a register.

    3. This is a typo. The pfReadUxx() functions return a char instead of an integer, this will be corrected for the next
    release of the manual. Thanks for the hint.

    Best regards
    Arne
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • xx = any number (8, 16 32)
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • An additional question:

    In the RTOSPlugin_embOS.c I saw a such structure.

    typedef struct {
    signed short offset;
    unsigned short bits;
    } STACK_REGS;

    static const STACK_REGS _CortexM4FStackOffsets[] = {
    { 0x28, 32 }, // R0
    { 0x2C, 32 }, // R1
    { 0x30, 32 }, // R2
    { 0x34, 32 }, // R3
    { 0x04, 32 }, // R4
    { 0x08, 32 }, // R5
    { 0x0C, 32 }, // R6
    { 0x10, 32 }, // R7
    { 0x14, 32 }, // R8
    { 0x18, 32 }, // R9
    { 0x1C, 32 }, // R10
    { 0x20, 32 }, // R11
    { 0x38, 32 }, // R12
    { -2, 32 }, // SP
    { 0x3C, 32 }, // LR
    { 0x40, 32 }, // PC
    { 0x44, 32 }, // XPSR
    { -1, 32 }, // MSP
    { -1, 32 }, // PSP
    { -1, 32 }, // PRIMASK
    { -1, 32 }, // BASEPRI
    { -1, 32 }, // FAULTMASK
    { -1, 32 }, // CONTROL
    };

    where can I get more info about it?
    what is this offset from?
  • The pfWriteUxx() functions do not return anything (void), this will be corrected as well.

    The structure of the stack layout partially depends on the exception stack frame (CPU dependent) and additionally saved registers by the OS.
    For the Cortex-M4, refer to the ARM documentation: infocenter.arm.com/help/index.…oc.dui0553a/Babefdjc.html


    Best regards

    Arne
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.