LAUNCHXL-F280049C: PIEVECTTABLE odd data

Hi GI,

Is the InitPieVectTable() function called in the program? The InitPieVectTable is used to initializing the Pievecttable.

I could see a warning related to it.

The InitPieVectTable() is declared in f28004x_examples.h file.

Thanks

Aswin

Hi Aswin,

Aswin P said:

I could see a warning related to it.

No the warning is not there after adding the extern to the c file as explained in the previous thread. 

Why does the table have seemingly incorrect data pertaining to the table being loaded is the question being asked?

Note the reserved ISR words are showing as negative offset addresses by 6 words or so.

Hi Gi,

The PIEVECTTABLE memory browser should have the updated address. Only the first few which are reserved should have the same repeating address.

Can you try out any bitfield example, probably the LED blink example and check before and after running the program, whether the same result is observed.

And can you send the memory browser details of the PIVECTTABLE after running the LED example.

The first 3 - 32bit locations are for Boot ROM initialization., hence those are skipped.

Thanks

Aswin

Aswin P said:

And can you send the memory browser details of the PIVECTTABLE after running the LED example

The project PIVECTTABLE has SCI ISR context functions with strut members used as Boolean flags and unions of project variables fail to assert or pass any data. Otherwise, the left hand suspect table seems to load but the data is not the same as the right hand table. Although the very same IER's are executed and nested in both projects in the exact same functions. Should not both PIE tables be exactly the same?

There is another older post where someone had issues with end of the table being truncated due to GEL file, shows reserved words 0x0 starting at 0xd00. Hence the other question was why reserved words are seemingly shifted downward in the addresses. If they are reserved words they would seemingly be 0x0 - correct? Are you saying the reserved words start below 0xd00?

The other interesting point is the memory allocation tool is showing PIEVECTTABLE UNION-1 in the working project. Shows UNION-5 in the project that is failing to assert any of the struct member Boolean flags or union variables in the SCI ISR context called functions. Why is the UNION number different and what does it signify?

Hi GI,

Genatco said:

Should not both PIE tables be exactly the same?

Since it is two different projects, it will be having different PIEVECTTABLE addresses.

But I tried from my side and was not able to get the repetition issue that you have observed.

The reserved ISR had same address and different for others.

I will analyze the issue in deep.

Thanks

Aswin

Hi Aswin,

Perhaps PIEVECTTABLE UNION_5 is due to the f28004x_headers_nonbios.cmd Group having 5 members? Yet the project with UNION_1 has the same ~nonbios.cmd group members. Oddly the SCI IER interrupts seem to be asserting without a vector table in memory. Seemingly since the keyword (__cregister) the compiler writes/reads direct into CPU registers IER/IFR flags?

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

Hi GI,

The __cregister keyword is used to access the control register. 

Please have a look at section 6.6.2 in TMS320C28x Optimizing C/C++ Compiler v18.12.0.LTS User's Guide (Rev. R) for further details on the keyword.

I will map the query on the PIEVECTTABLE UNION_5 in the memory allocation tool to another expert.

Thanks

Aswin

Aswin P said:

Please have a look at section 6.6.2 in

Yet compiler and TRM text has limited scope of what exactly PIE or CPU does with IER/IFR flags relative to the VECTTABLE being in memory. 

We are using compiler guide for v22.6.0.LTS and any driverlib bugs or CMD file directive issues should have been reported this forum by the time of this compiler version release. 

Aswin P said:

I will map the query on the PIEVECTTABLE UNION_5

Need to know why the same group listing produces UNION_1 versus UNION_5 from the very same CMD file directives in both projects.

Hi Gl,

Genatco said:

Yet compiler and TRM text has limited scope of what exactly PIE or CPU does with IER/IFR flags relative to the VECTTABLE being in memory. 

This is a good point, and feedback we can take for future devices. CPU controls PIE, PIE sets the IER/IFR flags, flags cause vecttable entries to get called.

Regards,

Vince

Hi Vince,

Vince said:

flags cause vecttable entries to get called.

That makes sense but the vector table was not loaded and the IER/IFR flags were asserting in debug CPU registers. Though it seems even with table being loaded there is no difference and IER/IFR flags are not fowling the CPU control states for peripheral core priority ordering. So the nesting rules that work with SDK4.01 are being ignored in this newer universal MCSDK project for the same SCI coded functions in both projects.

Hi Gl,

It is possible the nesting example code may be different in different versions of the SDK. This could be what you are seeing.

Regards,

Vince

Vince said:

It is possible the nesting example code may be different in different versions of the SDK

It is loading the same pievect.c file in both projects that being UNION_5 the only difference all the others are UNION_1. Confusing is f28004x _defaultisr.c is part of the build but my nesting RX/TX FIFO are not added in this file as it suggests. Oddly It can't be excluded from the build or compile time symbol errors occur. Yet piectrl.c/h and pievect.h all exist in the build.

Do we really need to insert ADCC1 and SCIB ISR functions in these default handlers? If not, seemingly text could say if your project has a function with nesting rules for these peripherals then there is no need to add code snips into this file defaultisr.h

//
// ADCC1_ISR - ADCC Interrupt 1
//
__interrupt void
ADCC1_ISR(void)
{
    //
    // Insert ISR Code here
    //

    //
    // To receive more interrupts from this PIE group,
    // acknowledge this interrupt.
    //
    // PieCtrlRegs.PIEACK.all = PIEACK_GROUP1;

    //
    // Next two lines for debug only to halt the processor here
    // Remove after inserting ISR Code
    //
    ESTOP0;
    for(;;);
}

//
// SCIB_TX_ISR - SCIB Transmit Interrupt
//
__interrupt void
SCIB_TX_ISR(void)
{
    //
    // Insert ISR Code here
    //

    //
    // To receive more interrupts from this PIE group,
    // acknowledge this interrupt.
    //
    // PieCtrlRegs.PIEACK.all = PIEACK_GROUP9;

    //
    // Next two lines for debug only to halt the processor here
    // Remove after inserting ISR Code
    //
    ESTOP0;
    for(;;);
}

Genatco said:

So the nesting rules that work with SDK4.01 are being ignored in this newer universal MCSDK project for the same SCI coded functions in both projects.

It appears that is occurring but in reality SCI ISR nesting seems to be working in both projects with ADCC1 ISR. Oddly some other timing issue is suspect. Seemingly CPUTM0 is unaware of group nesting and it pops the stack on SCI ISR group 9 nested time slots, group 1 ADCC having priority.

Hi Vince,

Vince said:

The ISR can be modified if desired, but provides a starting point.

Yet the ISR are registered to  three functions being the confusing part (defaultisr.c) is even a Required part of the build. I say that having past experience with TM4C Tivaware vector tables example projects do not have two assignment files and the table addresses lineup with CPU exception pointers and peripheral ISR's address space.

Vince said:

Do we really need to insert ADCC1 and SCIB ISR functions in these default handlers?

Why can't we remove the two default ISR (snips) if they are later registered to a function in the project?

Perhaps pievect.c/h should only be called after the ISR's are registered by the application and before asserting EINT? It seems to me the example projects TI is releasing have not correctly established a proper vector table to build upon. That is not true of the Tivaware example projects and makes it highly confusing C2000 projects for adding any peripherals to the examples.