pmonchip section not loaded

Mary Frantz

I am running BIOS 5.41.10.36 and Linux on a OMAPL128. The program is based on the HelloDSP DSPLink example. The ARM code runs and loads the DSP code using the DSPLink library. This has been running successfully for months.

Suddenly, while testing a new SATA drive, without code changes, the DSP code is hanging.

After some debugging, I found that the startup code is causing a reset. The DSP code initializes the McBSP1 during DEV_init() , and as part of that calls PMI_setModuleState() which is located at 0x118140E0 (IRAM). This code is assigned to the .pmonchip section by the linker. Looking at the memory at this location shows that it contains a repeating pattern of 0x00FFFFFF. In fact all of the .pmonchip section contains nothing but 0x00FFFFFF. Attempting to execute this code causes the DSP to reset. So, it never reaches main().

I opened the .out file and can see definitions for all the other memory sections (.bss, .far, .text , etc) but there is no definition for .pmonchip. This is true for the HelloDSP.out in the original example as well. There are trampoline functions that direct the DSP to the appropriate location in L2 Ram but the code is not there.

How does the pmonchip section get loaded? Should is load when the rest of the code get loaded? Or does the BIOS startup code load it at run time?

Why would this problem occur in working code?

Mary

over 12 years ago

0 Karl Wechsler over 12 years ago

TI__Mastermind 20805 points

I have never heard of a section named '.pmonchip'.

If you look at your .map file you should see which .obj file contributes that section.

Are you getting a warning from the linker? If your .cmd file doesn't specify this section, you will get a linker warning and the linker will place it at the first location it can find. You can add another linker.cmd file to your project and place the .pmonchip section. CCS can take more than one linker .cmd file.

Do you know if you have cache enabled for your application? The on-chip memory can be used for either RAM or CACHE. You might be placing this section in a cached memory region.

-Karl-

0 Mary Frantz over 12 years ago in reply to Karl Wechsler

Intellectual 580 points

From the platform file:

/* Specify the L1 and L2 memory settings */

var device_regs = {

l1PMode: "32k",

l1DMode: "32k",

l2Mode: "128k"

// l2Mode: "0k"

};

prog.module("GBL").C64PLUSCONFIGURE = true ;

prog.module("GBL").C64PLUSL2CFG = "128k" ;

prog.module("GBL").C64PLUSL1DCFG = "32k" ;

prog.module("GBL").C64PLUSMAR192to223 = 0xFFFFFFFF ; // all of DDR memory

prog.module("GBL").C64PLUSMAR128to159 = 0x00000001 ; // shared memory

From the .tcf file:

bios.GBL.C64PLUSMAR192to223 = 0xffffffc0; // 0xC0000000 - 0xC5FFFFFF not cached, ARM & shared DDR memory
bios.GBL.C64PLUSMAR128to159 = 0x00000000; // L3_CBA_RAM not cached

From the .cmd file:

.pmonchip: {} > IRAM

From the .map file:

.pmonchip

* 0 11813a20 000007c0

11813a20 00000300 pmi.a674 : pmi_relock1.o674 (.pmonchip)

11813d20 00000180 bios6748.a674 : pwrm_rdb6748.o674 (.pmonchip) [fill = 0]

11813ea0 00000140 pmi.a674 : pmi_onchip.o674 (.pmonchip)

11813fe0 00000100 : pmi_pll.o674 (.pmonchip:slp)

118140e0 000000c0 : pmi_ms.o674 (.pmonchip)

118141a0 00000020 rts6740.lib : divu.obj ($Tramp$L$PI$$__divu)

118141c0 00000020 pmi.a674 : pmi_pll.o674 ($Tramp$L$PI$$_PMI_calcWaitBypass)

There are no warnings from the linker. I do not have a compile issue. My question is: What is the mechanism for getting this code loaded into RAM? Does it happen at load time or does BIOS load it at run time? What would prevent that from happening?

Mary

0 Mary Frantz over 12 years ago in reply to Mary Frantz

Intellectual 580 points

Found the problem. My bss and far sections are also in IRAM. Failure to initialize a pointer caused the code to overwrite the pmonchip section with bad data.

I note that the pmonchip section is last in the SECTIONS list.

From the .cmd file:

SECTIONS {

.hwi_vec: {

*(.hwi_vec)

} align = 0x400, RUN_START(HWI_A_VECS) > DDR

.sysdata: {} > DDR

.dio: {} > DDR

.dsm: {} > DDR

.udev: {} > DDR

frt: {} > DDR

.mem: {} > DDR

.bios: {} > DDR

.cio: {} > DDR

.data: {} > DDR

.gio: {} > DDR

.pinit: {} > DDR

.sys: {} > DDR

.sysregs: {} > DDR

.text: {} > DDR

.cinit: {} > DDR

.devtable: {} > DDR

.switch: {} > DDR

.gblinit: {} > DDR

.sysinit: {} > DDR

.trcdata: {} > DDR

.hwi: {} > DDR

.rtdx_text: {} > DDR

.TSK_idle$stk: {

*(.TSK_idle$stk)

} > DDR

.taskMcBspInput$stk: {

*(.taskMcBspInput$stk)

} > DDR

/* LOG_system buffer */

.LOG_system$buf: align = 0x1000 {} > DDR

/* DVTEvent_Log buffer */

.DVTEvent_Log$buf: align = 0x8000 {} > DDR

/* trace buffer */

.trace$buf: align = 0x1000 {} > DDR

.rtdx_data: align = 0x40 { . += 0x80; *(.rtdx_data) } > DDR

/* RTA_fromHost buffer */

.hst1: align = 0x4 {} > DDR

/* RTA_toHost buffer */

.hst0: align = 0x4 {} > DDR

GROUP {

.const: align = 0x8 {}

.printf (COPY): {}

} > DDR

.args: align=4 fill=0 {

*(.args)

. += 0x4;

} > DDR

.trace: fill = 0x0 align = 0x4 {

_SYS_PUTCBEG = .;

. += 0x200;

_SYS_PUTCEND = . - 1;

} > DDR

.hst: RUN_START(HST_A_TABBEG), RUN_START(_HST_A_TABBEG), RUN_END(HST_A_TABEND), RUN_END(_HST_A_TABEND) {

} > DDR

.log: RUN_START(LOG_A_TABBEG), RUN_START(_LOG_A_TABBEG), RUN_END(LOG_A_TABEND), RUN_END(_LOG_A_TABEND) {

} > DDR

.pip: RUN_START(PIP_A_TABBEG), RUN_START(_PIP_A_TABBEG), RUN_END(PIP_A_TABEND), RUN_END(_PIP_A_TABEND) {

} > DDR

.sts: RUN_START(STS_A_TABBEG), RUN_START(_STS_A_TABBEG), RUN_END(STS_A_TABEND), RUN_END(_STS_A_TABEND) {

} > DDR

.stack: align = 0x8 {

GBL_stackbeg = .;

*(.stack)

GBL_stackend = GBL_stackbeg + 0x1000 - 1;

_HWI_STKBOTTOM = GBL_stackbeg + 0x1000 - 8;

_HWI_STKTOP = GBL_stackbeg;

} > DDR

.DDR$heap: {

. += 0x100000;

} RUN_START(DDR$B), RUN_START(_DDR_base), RUN_SIZE(DDR$L), RUN_SIZE(_DDR_length) > DDR

.bss: {} > IRAM

.far: {} > IRAM

.pmonchip: {} > IRAM

}

It would be nice if it could be placed in memory before the bss and far section. Less chance of a buffer overrun writing over code.

Mary

Processors

Processors forum

pmonchip section not loaded