SIMPLELINK-OPENOCD: Issues stepping though code using OpenOCD and GDB on CC1352P1

Hi,

I have forwarded your query to the relevant team. They will get back to you as soon as possible.

Thanks

The TI support to OpenOCD was to add configuration files for the supported devices and LaunchPads, and to add code to enable flashing the targets. This stepping issue from within GDB is part of the Cortex M support already present in OpenOCD and not code that we modified, or even delved into.  You may need to forward this question on to the OpenOCD forums to find someone more knowledgeable on the inner workings.

A quick test though: what happens when you set a breakpoint on the following instruction and continue?  That should essentially be what GDB is doing when stepping over, but maybe there's something else happening. Also, would the SPI calls need interrupts active?  Is it possible that stepping over isn't enabling interrupts, and so you don't get the result you're expecting?

Hi Edward,

Thanks for your response. The behaviour is the same when I set a breakpoint at say main and continue. As in, some of the basic functions such as GPIO LED blink work, but any of the functions involving SPI transfers don't work. It's not that the SPI transfer itself fails, but it seems like I step over the function and any of the registers that I am supposed to be reading do not return the values that I am expecting. (To clarify, this all works in a free run - If I use OpenOCD tp just flash the code onto the board and then reset the board). Any buffer memory tests fail. However, I can confirm that I am actually stepping through code on the target since GPIO_LED_blink happens correctly for LED0 and LED1 when I step over the relevant piece of code. I am running SPI in blocking mode, so I don't think that is using interrupts - and I am able to debug correctly through when I use TI's inbuilt debugger. 

Is there any setup that TI's internal debugger does before starting to debug? What other options do I have here - is there a way I can use an external binary file (say one compiled with cmake makefiles) with TI's debugger?

Warm regards,

Samyukta

I don't know of any specific Cortex M initialization that would be different.  There are board and device specific initialization steps though that may be the issue. You can inspect the GEL files attached to the CCS configuration, in particular for the events on connect, on program load, and may be on reset to see if something is being done that might affect SPI operation.

Hi Edward,

Thanks for your response.

I can see some memory map files that look a little different from what I can see using openocd : 

(gdB) maintenance info sections 

[0]     0x0000->0x0000 at 0x00000000: .intvecs READONLY 

 [1]     0x0000->0x0000 at 0x00000000: .TI.ramfunc READONLY

 [2]     0x0000->0x0000 at 0x00000000: .constdata READONLY

 [3]     0x0000->0x0000 at 0x00010448: .rodata ALLOC READONLY

 [4]     0x0000->0x0000 at 0x00010448: .binit ALLOC LOAD READONLY DATA HAS_CONTENTS

 [5]     0x10180->0x10410 at 0x000101b8: .cinit ALLOC LOAD READONLY DATA HAS_CONTENTS

 [6]     0x0000->0x0000 at 0x00000000: .pinit READONLY

 [7]     0x0000->0x0000 at 0x00010448: .init_array ALLOC

 [8]     0x0000->0x0000 at 0x00000000: .emb_text READONLY

 [9]     0x0000->0x0000 at 0x00000000: .ccfg READONLY

 [10]     0x0000->0x0000 at 0x00000000: .vtable READONLY

 [11]     0x0000->0x0000 at 0x00000000: .vtable_ram READONLY

 [12]     0x0000->0x0000 at 0x00000000: vtable_ram READONLY

 [13]     0x20001110->0x20001688 at 0x00010448: .data ALLOC

 [14]     0x20001b20->0x20003afd at 0x00010458: .bss ALLOC

 [15]     0x0000->0x0000 at 0x00000000: .sysmem READONLY

[16]     0x20013c00->0x20014000 at 0x00010448: .stack ALLOC

 [17]     0x0000->0x0000 at 0x00000000: .nonretenvar READONLY

 [18]     0x20000110->0x20001110 at 0x00010448: .priheap ALLOC READONLY

 [19]     0x0000->0x0000 at 0x00000000: .gpram READONLY

 [20]     0x20000104->0x20000108 at 0x0001044c: .data:xdcRomExternFuncPtr ALLOC

 [21]     0x20000108->0x2000010c at 0x00010450: .data:xdcRomStatePtr ALLOC

 [22]     0x20000100->0x20000104 at 0x00010448: .data:xdcRomConstPtr ALLOC

 [23]     0x0000->0x0008 at 0x00010448: .bootVecs READONLY

 [24]     0x0000->0x003c at 0x00000038: .resetVecs ALLOC LOAD READONLY DATA HAS_CONTENTS

 [25]     0x20000000->0x200000d8 at 0x00010448: .vecs READONLY

 [26]     0x0000->0x011f at 0x00010448: xdc.meta READONLY HAS_CONTENTS

 [27]     0x0000->0x0000 at 0x00000000: xdc.noload READONLY

 [28]     0x0000->0x0000 at 0x00000000: .TI.noinit READONLY

 [29]     0x0000->0x0000 at 0x00000000: .TI.persistent READONLY

 [30]     0x20001840->0x20001850 at 0x00010448: .TI.bound:dmaSpi0TxControlTableEntry ALLOC

 [31]     0x20001830->0x20001840 at 0x00010448: .TI.bound:dmaSpi0RxControlTableEntry ALLOC

 [32]     0x20001910->0x20001920 at 0x00010448: .TI.bound:dmaSpi1TxControlTableEntry ALLOC

 [33]     0x20001900->0x20001910 at 0x00010448: .TI.bound:dmaSpi1RxControlTableEntry ALLOC

[34]     0x20001a40->0x20001a50 at 0x00010448: .TI.bound:dmaSpi0TxAltControlTableEntry ALLOC

 [35]     0x20001a30->0x20001a40 at 0x00010448: .TI.bound:dmaSpi0RxAltControlTableEntry ALLOC

 [36]     0x20001b10->0x20001b20 at 0x00010448: .TI.bound:dmaSpi1TxAltControlTableEntry ALLOC

 [37]     0x20001b00->0x20001b10 at 0x00010448: .TI.bound:dmaSpi1RxAltControlTableEntry ALLOC

 [38]     0x0000->0xf4ef2 at 0x00010567: .debug_info READONLY HAS_CONTENTS

 [39]     0x0000->0x2aa59 at 0x00105459: .debug_line READONLY HAS_CONTENTS

 [40]     0x0000->0xacb2 at 0x0012feb2: .debug_frame READONLY HAS_CONTENTS

 [41]     0x0000->0x1c44e at 0x0013ab64: .debug_abbrev READONLY HAS_CONTENTS

 [42]     0x0000->0x71f98 at 0x00156fb2: .debug_str READONLY HAS_CONTENTS

 [43]     0x0000->0x3cd0 at 0x001c8f4a: .debug_aranges READONLY HAS_CONTENTS

 [44]     0x0000->0x8590 at 0x001ccc1a: .debug_pubnames READONLY HAS_CONTENTS

 [45]     0x0000->0x9d38b at 0x001d51aa: .debug_pubtypes READONLY HAS_CONTENTS

 [46]     0x003c->0xf7c4 at 0x00000074: .text ALLOC LOAD READONLY CODE HAS_CONTENTS

 [47]     0xf7c4->0x1017c at 0x0000f7fc: .const ALLOC LOAD READONLY DATA HAS_CONTENTS

 [48]     0x0000->0x0058 at 0x00272535: .ARM.attributes READONLY HAS_CONTENTS

 [49]     0x0000->0x0041 at 0x002a0da0: .TI.section.flags READONLY HAS_CONTENTS

Here's what my memory map in code composer studio has: 

It looks a little different.

Here's what my GEL file shows : 

    /*
     * Syntax for GEL_MapAddStr.
     * GEL_MapAddStr(address, page, length, "attribute", waitstate);

    Basic Attribute Types           Derived Attribute Types
    String      Description         String      Description
    R           Read                NONE        No memory/protected
    W           Write               RAM         Read and write
    P           Port                ROM         Read only
    EX          External            WOM         Write only
    EM          Emulator            INPORT      Port read only
    PR          Programmable        OUTPORT     Port write only
    ER          Erasable            IOPORT      Port read and write
    DA          Dual access         SARAM       Single access RAM
    ASn         Access size         DARAM       Dual access RAM
    SHnC        Shared              FLASH       Flash ROM
    CACHE       Cache               EXRAM       External RAM
    TX          Text                EXROM       External ROM
    MN          Monitor             EPROM       Erasable write-able EPROM
    SA          Single access       MONITOR     Monitor ROM
    FL          Flash               PRAM        Program RAM
    MR          Memory mapped       PROM        Program ROM
    NULL        NULL                NULL        NULL
    */
    GEL_MapAddStr(0x00000000, 0, 0x00058000, "R", 0);       /* Flash */
    GEL_MapAddStr(0x10000000, 0, 0x00040000, "R", 0);       /* ROM */
    GEL_MapAddStr(0x11000000, 0, 0x00002000, "R|W", 0);     /* GPRAM */
    GEL_MapAddStr(0x20000000, 0, 0x00014000, "R|W", 0);     /* SRAM */
    GEL_MapAddStr(0x21000000, 0, 0x00001000, "R|W", 0);     /* RFC_SRAM */
    GEL_MapAddStr(0x21004000, 0, 0x00004000, "R|W", 0);     /* RFC_ULL */
    GEL_MapAddStr(0x21008000, 0, 0x00000800, "R|W", 0);     /* MDM_RAM */
    GEL_MapAddStr(0x2100C000, 0, 0x00000800, "R|W", 0);     /* RFE_RAM */
    GEL_MapAddStr(0x40000000, 0, 0x000E1028, "R|W", 0);     /* Peripherals */
    GEL_MapAddStr(0x40031000, 0, 0x00001000, "NONE", 0);    /* Protected */
    GEL_MapAddStr(0x50001000, 0, 0x00000800, "R", 0);       /* FCFG1 */
    GEL_MapAddStr(0x50002000, 0, 0x00000800, "R", 0);       /* FCFG2 */
    GEL_MapAddStr(0x50003000, 0, 0x00002000, "R", 0);       /* CCFG */
    GEL_MapAddStr(0xE0000000, 0, 0x00003000, "R|W", 0);     /* CPU_ITM, CPU_DWT, CPU_FPB */
    GEL_MapAddStr(0xE000E000, 0, 0x00001000, "R|W", 0);     /* CPU_SCS */
    GEL_MapAddStr(0xE0040000, 0, 0x00001000, "R|W", 0);     /* CPU_TPIU */
    GEL_MapAddStr(0xE00FE000, 0, 0x00001000, "R|W", 0);     /* CPU_TIPROP */

    GEL_TextOut("Memory Map Initialization Complete.\n");

So, is there a way to use CCS's debugger with my own binary?

Another question I wanted to ask - has TI endorsed openOCD as an alternative to it's own debugger? If so, are there any examples of projects which use Code Composer Studio projects with peripherals that work successfully? I attempted to use a project compiled with Code Composer Studio with openOCD and that did not work as I expected it to either. Is there an example of using openOCD with an example code with a peripheral that is sure to work?

Warm regards,

Samyukta

Another thing I noticed - when I use Code Composer Studio's debugger and step into SPI_transfer function, I can see the source code in SPI.c, whereas in openOCD and GDB it says no source found ... could this be relevant?

You should be able to use CCS to debug a binary that was compiled with a different toolset.  As long as the binary was built with symbols, it should work.  When a source file is required, CCS will ask you find that file should CCS not be able to find the file.

OpenOCD is being offered as an alternative to, but it isn't currently supported to the same level as the CCS debugger.  However, most examples I have seen can be built using GCC as the toolset instead of the CCS compilers, and may be more compatible with OpenOCD.

GDB should required the source file to successfully step over the function.  And when stepping into it, isn't there a command to let you locate and load the source file for GDB?  I'm not an expert with GDB, so not sure on that point.