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.

Does g_pfnVectors layout change between TiVa variants?

Other Parts Discussed in Thread: TM4C1290NCPDT, TM4C1237H6PZ

I am working on several TiVa based platforms using different chips.  I am considering the startup_ccs.c file and the many unused ISR entries I have in g_pfnVectors.  My questions below follow from thinking through whether the unused peripheral interrupts can be handled in a generic fashion for all chips, or if each chip needs knowledge of the chip's specific g_pfnVectors.

Are the vectors the same (for implemented peripherals) for all chips?  In other words,

Is GPIO_Port_A_ISR at location 16 for all chips?

Is GPIO_Port_S_ISR at location 105 (guessing!) on chips with PortS implemented and 0 (reserved) for those with no PortS?

What happens if additional peripherals are added to future TiVa family variants?  Where would GPIO_Port_V_ISR go?

What happens if there is a PWM_5_Generator_0_ISR implemented?  Does some other vector have to go, a reserved space used, or the vector table extended?

  • The CCS 5.5 ccsv5\ccs_base\arm\include directory contains <devicename>_startup_ccs.c files, which are customized to specific Tiva devices. Comparing a random sets of files show some have the same g_pfnVectors arrays and some have different g_pfnVectors arrays.

    E.g.: 

    - tm4c1290ncpdt_startup_ccs.c has "GPIO Port S"at offset 109

     - tm4c1237h6pz_startup_ccs.c has "GPIO Port S" at offset 149

    I am not sure if there is a TI document which contains a list of the ISR vector differences between Tiva devices, or if you have to manually compare different CCS 5.5 <devicename>_startup_ccs.c files and/or device datasheets.

  • Thanks for your time.  I was hoping... but knew the answer would likely be to look at every chip's vector table.

  • I can make things a bit easier for you. Every Tiva C series part prior to TM4C129 and all LM3S parts used exactly the same interrupt vector layout. If a given peripheral was not available on a part, we left a blank word in the vector table. This worked fine but, with the number of peripherals expanding, the vector table was getting to be rather enormous so, for TM4C129, we compressed it and this caused the layout to change. The upside to this is that you no longer need to waste quite as much space for the VTABLE if you need only a few vectors and some of them have high numbers. The downside is that, if you wanted to have a single binary that will run on two different classes of part, you would need to build the VTABLE dynamically based on the part class in use. Given class-to-class differences (pinouts and peripheral mix, for example), though, I suspect there can't be too many applications where it's practical to use an identical binary for 2 different part classes.