This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UTL_halt() when creating static DEV

Other Parts Discussed in Thread: OMAPL138, TMS320C6748

Working with the OMAP L138 eXperimenter board, building on Linux but using CCS v3.3 for debugging, BIOS PSP version 01.30.01 (part of the "ti-dvsdk_omapl138-evm_4_02_00_06" package).

I am trying to add an SPI device to my project, based on the examples provided with the BIOS PSP. The SPI example compiles and seems to work correctly.

I added the following configuration text to the project .tcf file:

bios.UDEV.create("Spi0");
bios.UDEV.instance("Spi0").fxnTableType = "IOM_Fxns";
bios.UDEV.instance("Spi0").initFxn = prog.extern("spi_userInit");
bios.UDEV.instance("Spi0").params = prog.extern("spiParams");
bios.UDEV.instance("Spi0").fxnTable = prog.extern("Spi_IOMFXNS");
bios.UDEV.instance("Spi0").deviceId = 1;

Where:

Spi_Params       spiParams;

void spi_initParams(void)
{
 /* exactly the same parameter definition as the SPI example */
}

void spi_userInit()
{

    volatile Int i=1;

    LOG_printf(&trace, "entering spi_userInit()\n");

    while (i); //provides a CCS breakpoint, for debugging purposes

    spi_initParams();

    Spi_init();

    LOG_printf(&trace, "exiting spi_userInit()\n");

} //spi_userInit()

 

On loading the .out binary into the DSP, I can Step through the spi_userInit() function, it prints out the "entering"/"exiting" text on the Trace display. Upon returning, it goes back to DEV_init(), which calls uppMdBindDev(), where I cannot keep Stepping through (PC points to the start of the function and won't move when pressing F10/F11). But if I press F5 (Run), the program goes on to hang. When I Halt the processor, the Call Stack shows UTL_halt() and the Execution Graph Details shows: "0 SYS abort called with message 'ERROR - Device %s Config Failed' ".

 

I've also tried creating a different type of device (UPP), with the same results.

How can I get a clue as to what is causing this?

Below is the complete .tcf file for the project:

utils.importFile("dsplink-omapl138gem-base.tci");

bios.ECM.ENABLE = 1;

bios.PWRM.ENABLE = 1;


prog.module("MEM").ARGSSIZE = 50 ;


bios.UDEV.create("Spi0");

bios.UDEV.instance("Spi0").fxnTableType = "IOM_Fxns";

bios.UDEV.instance("Spi0").initFxn = prog.extern("spi_userInit");

bios.UDEV.instance("Spi0").params = prog.extern("spiParams");

bios.UDEV.instance("Spi0").fxnTable = prog.extern("Spi_IOMFXNS"); //provided by the driver

bios.UDEV.instance("Spi0").deviceId = 1;


var IRAM    = prog.module("MEM").instance("IRAM");

var L1DSRAM = prog.module("MEM").instance("L1DSRAM");


bios.setMemCodeSections (prog, prog.get("DDR")) ;

bios.setMemDataNoHeapSections (prog, prog.get("DDR")) ;

bios.setMemDataHeapSections (prog, prog.get("DDR")) ;


bios.MEM.instance("DDR").createHeap = 1;

bios.MEM.instance("DDR").heapSize = 0x300000;


bios.MEM.BIOSOBJSEG = prog.get("DDR");

bios.MEM.MALLOCSEG = prog.get("DDR");

bios.MEM.BIOSSEG = prog.get("IRAM");

bios.MEM.SYSINITSEG = prog.get("IRAM");

bios.MEM.TEXTSEG = prog.get("DDR");

 

bios.MEM.HWISEG = prog.get("DDR");

bios.MEM.HWIVECSEG = prog.get("DDR");


bios.TSK.ENABLETSK = true;

bios.TSK.OBJMEMSEG = prog.get("DDR");

bios.TSK.STACKSIZE = 1024;

bios.TSK.STACKSEG = prog.get("DDR");


bios.HWI.instance("HWI_INT7").interruptSelectNumber = 0;

bios.HWI.instance("HWI_INT8").interruptSelectNumber = 1; //includes spi INT

bios.HWI.instance("HWI_INT9").interruptSelectNumber = 2; //includes upp INT

bios.HWI.instance("HWI_INT10").interruptSelectNumber = 3;


bios.IDL.OBJMEMSEG = prog.get("DDR");


bios.LOG_system.bufSeg = prog.get("IRAM");

bios.LOG_system.bufLen = 4096;

bios.LOG_system.logType = "circular";


bios.LOG.create("trace");

bios.LOG.instance("trace").bufLen = 4096;

bios.LOG.instance("trace").bufSeg = prog.get("IRAM");


bios.LOG.create("DVTEvent_Log");

bios.LOG.instance("DVTEvent_Log").bufSeg = prog.get("IRAM");

bios.LOG.instance("DVTEvent_Log").bufLen = 128;

bios.LOG.instance("DVTEvent_Log").comment = "DVT";


bios.CLK.RESETTIMER = 1;


bios.GBL.ENABLEINST = 1;


if (config.hasReportedError == false) {

    prog.gen();

}


 


 

  • Issue is fixed. I followed the recommendations on the DSP BIOS Release Notes:

     

    Known Issues

    The following issues are known to affect this release:

    • To operate within TMS320C6748 and OMAPL138 device constraints, it must be ensured that no off-chip accesses to DDR memories occur while PLL1 is bypassed.  The BIOS Power Manager (PWRM) provides two sleep modes where this constraint is a concern: PWRM_SLEEP, when PLL1 is allowed to be bypassed, and PWRM_DEEPSLEEP. 

      PWRM, and the underlying PSCL and PMI layers have been implemented with the goal of minimizing the impact of this constraint upon the user.  However, there remain some user-domain memory placement requirements, for invoking these two sleep modes. 

      The following items must be placed in on-chip memory.  Either L2 or L3 memory (referred to as IRAM or L3_CBA_RAM in BIOS configuration) can be used.  Note that L2 memory will provide faster performance compared to L3.  Where applicable, examples of how to control this with textual configuration are shown in brackets.

      1) The .bios section. [bios.MEM.BIOSSEG = prog.get("IRAM");]
      2) The .hwi_vec section. [bios.MEM.HWIVECSEG = prog.get("IRAM");]
      3) The .bss section. [bios.MEM.BSSSEG = prog.get("IRAM");]
      4) The .pmonchip section. [bios.PWRM.ONCHIPMEMSEG = prog.get("IRAM");]
      5) The .clk section (if CLK is enabled as a wakeup interrupt). [bios.CLK.OBJMEMSEG = prog.get("DDR");]
      6) The stack of the task from which PWRM_sleepDSP is being invoked. [To default all task stacks to IRAM: bios.TSK.STACKSEG = prog.get("IRAM");]
      7) The interrupt stack (the .stack section) if the HWI dispatcher is used. [bios.MEM.STACKSEG = prog.get("IRAM");]
      8) Any user-provided CLK functions (if CLK is enabled as a wakeup interrupt) (code and data).
      9) Any user-provided wakeup ISR functions (code and data).
      10) Any runtime library functions (e.g., math routines) required by the user functions that run in the context of a wakeup ISR.
    • The new Power Manager (PWRM module) for C6748 devices optionally uses two packages (PMI and PSCL) for implementing low-level power control functionality.  When the PWRM module is enabled in your DSP/BIOS configuration, it will attempt to link to the libraries in these packages.  This requires that the paths to the PMI and PSCL libraries be included in the linker search path.  These paths are included by default in the CCSv3 project files for the DSP/BIOS examples for the evm6748 and evmOMAPL138 platforms.  If you are creating your own CCSv3 project files you should similarly include the following paths for the linker: -i"%BIOS_INSTALL_DIR%/packages/ti/pscl/lib" -i"%BIOS_INSTALL_DIR%/packages/ti/pmi/lib".  CCSv4 projects using PWRM will also require the user to add the libraries to the linker search path. 

     

    So I made sure those memory sections are defined:

    bios.MEM.BSSSEG = prog.get("IRAM");

    bios.PWRM.ONCHIPMEMSEG = prog.get("IRAM");

    bios.CLK.OBJMEMSEG = prog.get("DDR");

    bios.MEM.STACKSEG = prog.get("IRAM");

    bios.MEM.HWIVECSEG = prog.get("IRAM");

     

    Though I am having an issue with the TSK stack section:

    bios.TSK.STACKSEG = prog.get("DDR"); //cannot set it to "IRAM" for some reason, I get: IRAM is an illegal value for TSK.STACKSEG

     

    Finally I enabled the PWR module:

     

    bios.PWRM.ENABLE = 1;

    bios.PWRM.RESOURCETRACKING = 1;

    bios.PWRM.SCALING = 1;

     

    And that seems to have done the trick, devices are created and the DSP no longer hangs.

    Thanks,

    Carlos

  • Glad to see this was resolved