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.

LAUNCHXL-F280049C: PIEVECTTABLE does not load

Guru 56198 points

Part Number: LAUNCHXL-F280049C
Other Parts Discussed in Thread: C2000WARE

Hello, 

After project migration F28004x_headers_nonbios.cmd file does not seem to execute as there is no UNION or PIEVECTOR bytes showing memory allocation tool. In the original project UNION is run and I can't find anything different in projects compiler or linker settings that would force the headers CMD file to load or compile. Inevitably causes an immediate NMI since there seemingly is no vector table being loaded for other enabled ISR's groups in the project > than group 1.

Note: map file pre-migrated project indicates table loaded bytes and assembled very important peripheral file for ISR Core priority order. I past asked forum where file was loaded nobody had any idea what I was talking about. TRM and the wiki web page was just a daft about how or where to verify the files below are loaded into memory. Next assembler files print out in the project build flash_lib folder when you enable project properties to list *.asm file output. However they are missing in the migrated project build flash_lib folder thought the same PIE vector functions are called in hal.c of both projects.

f28004x_pievect.asm,  f28004x_piectrl.asm,

And the two SW prioritized asm may not be required for hardware core priority order? f28004x_sw_prioritized_pievect.asm,  f28004x_sw_prioritized_defaultisr.asm 

// initialize the interrupt controller
Interrupt_initModule();

/* Enable ePIE INTs 1-12 Clearing */
Interrupt_enablePIE();

// init vector table
Interrupt_initVectorTable();

 PIEVECTTABLE          00000d00   00000200  000001c0  00000040  RWIX

Note oddly the PIE functions are not loading any bytes.

Where might the headers CMD file be asserted in the project build?

memory map file: show pie table is not loaded in migrated project build.

 PIEVECTTABLE          00000d00   00000200  00000000  00000200  RWIX

/*** PIE Vect Table and Boot ROM Variables Structures ***/
UNION run = PIEVECTTABLE
{
PieVectTableFile
GROUP
{
   EmuKeyVar
   EmuBModeVar
   EmuBootPinsVar
   FlashCallbackVar
   FlashScalingVar
}
}

  • Hi,

    PIVECT table is loaded as part of InitPieVectTable function

    Regards,

    Veena

  • Hi Veena,

    Umm I don't have initPieVectTable() loaded in the other project where it is auto loading via the *.asm files in flash folder it seems. The project that is working had the same issue I recall now. The compiler claims init function declared implicitly when we (ctrl+click) direct to it and causes100's of symbol errors. Notice the number of bytes in the map file show it indeed has loaded. What is the required include file name as the f28004x_globaldefs.h extern path for the initPieVectTable() is not being indexed when include is added to hal.c.

    This has been an on going issue with the projects examples being released for SDK and MCSDK. Also the C2000ware_4.03 device files for x49c cause hundreds of errors when updated in the project. It seems there is no regression testing be done on the SDK motor projects to update the device files. For example lin.h we have to comment SCI_IDLE member or it causes 100's compile errors names of symbols etc. The same occurs in f28004x_globalvariabledefs.c, have to comment LIN section or it won't compile correctly. I had to put back the C2000ware_4.02 f28004x_device include/source and common-include/source files it simply cannot run with the newer device files.

  • Please use initPieVectTable() for initializing the PIVECTTABLE.

    Could you share the details of compile errors you faced in the C2000Ware / MCSDK. If it is the error you shared in the snapshot, it is due to the defaultisr.c file not being included in the project. This contains some dummy ISRs for all the interrupts. Let us know if you faced these compile errors in any example projects provided in C2000Ware / MCSDK.

    Regards,

    Veena

  • Please use initPieVectTable() for initializing the PIVECTTABLE.

    Yet that is what is causing all the errors in the image shown above. Oddly the SDK4.01 does not call the function and the table is loaded to memory. 

    the defaultisr.c file not being included in the project

    It is in the project flash folder as defaultisr.asm after deleting all the *.asm prior to recompile. 

    This contains some dummy ISRs for all the interrupts

    Still the dummy ISR table entries in memory are 0x0000 but come back both projects flash folders after deleting *.asm from the folder.

    Let us know if you faced these compile errors in any example projects provided in C2000Ware / MCSDK.

    Only when calling initPieVectorTable() in hal.c compile errors (above image) but notice the PIEVECTTABLE is loaded in memory, makes no since. 

    BTW: (lin.c) the compiler parser gets lost causes 100's of symbol errors see below example. Bigger yet  extern __cregister IER/IFR exports (f28004x_device.c) are highly troublesome. Compiler does not like IER/IFR causes symbol unresolved errors. Notice (cpu.h) has the same exports but uses unit16_t versus int. The #include "28004x_device.c" to C file that use IER or IFR symbols are unresolved by CCS code analysis. Causes symbol missing errors in other projects that use same IER/IFR flags, we go back and forth between two projects to get errors to stop. I used to copy project files into the working directory project to avoid this kind of mayhem in CCS. Stopped coping files believing driverlib updates would be easier but in fact C2000ware updates are not being regression tested cause huge issues to once working projects.

    extern cregister volatile unsigned int IFR;
    extern cregister volatile unsigned int IER;

    lin.h: when SCIB uses FIFO mode causes compiler parser failure.

    struct SCIFLR_BITS { // bits description
    bp_16 BRKDT:1; // 0 Break-detect Flag (SCI compatible mode)
    bp_16 WAKEUP:1; // 1 Wake-up Flag
    // bp_16 IDLE:1; // 2 SCI receiver in idle state (SCI compatible mode)
    bp_16 BUSY:1; // 3 Busy Flag

  • . Let us know if you faced these compile errors in any example projects provided in C2000Ware / MCSDK.

    Seems I added global export to the vector table and it compiled with a warning. Yet notice the PIEVECTTABLE is loaded in memory though it still causes NMI when SCIB FIFO asserts IER/IFR giving ADCC1 (below ISR) priority order in this MCSDK project. That does not occur in the SDK4.01 so something is not quite right in the InstaSpin ISR loop universal MCSDK project. 

    __attribute__((interrupt)) void motor1CtrlISR(void)

  • So the IER/IFR flags not being resolved was good part of the issue with SCIB no serial data besides low speed clock divisor had to be set %4 with x49c baud rate clock. Oddly SCIA was sending ASCII text out 115200KBPS so that really puzzles me how it was working with USB virtual COM port.

    The PIEVECTTABLE is still not loading any bytes into memory but the SCI module is working from the IER/IFR nested priority order controls and CPU_INT_9.

    However the ADCC1 ISR LED flash rate is much slower, 3 seconds between blinking seems to be CPU_TM0 1 millisecond is a bit more extended.

  • Hi Veena,

    Why does the PIECECTABLE not have to be loaded 0x00D00 for the PIEIER group and interrupt IER/IFR flags to execute? Oddly after I reshuffled LSRAM banks each for 8192KB as two combined 4096KB banks (0_1, 2_3, 4_7) and the vector table stopped loading as shown in above posted allocation tool and map file. Yet the ISR's and nested peripheral core priority order bits seem to be functioning without a vector table in memory.

    Oddly enough the globalvariablefefs.c has #pragma section for PieVecTableFile but is not executing anymore.

    //----------------------------------------
    #ifdef __cplusplus
    #pragma DATA_SECTION("PieVectTableFile")
    #else
    #pragma DATA_SECTION(PieVectTable,"PieVectTableFile");
    #endif
    volatile struct PIE_VECT_TABLE PieVectTable; 

  • Oddly enough the PIEVECTTABLE started to load only on the after I closed CCS and cleaned recompiled the project several times.

  • Please use initPieVectTable() for initializing the PIVECTTABLE.

    As you see in this thread the compiler thinks it was not finding the function, Though didn't seem to matter if it was loaded or not. Oddly it required to add extern void InitPieVectTable(void) to the hal.c to stop the ambiguous compiler warning. 

    Attempting to add table address plus length to flash.cmd file the headers.cmd file claim an overlap exist even though type=NOINIT. Again one project is auto loading vector table without hal.c calling it, assumed via pievect.asm. Perhaps the linker switches are different in this project. It seems plausible since after deleting pievect.asm the table bytes did not load 0x0000D00. Though map holds the address space for it until the next compile reads the *.asm files that are once again listed in the flash_lib folder.

    TI needs to post a warning about folders added to existing DOS project will be read by the IDE even though not part of build includes or links. The compiler symptoms may include several previously defined symbol conflict errors and is unexpected behavior CCS 12.3. It may have been there all along or something recently added in the search index.