CCS/MSP432E411Y: MSP432 crashes immediately and vtable without section warning

I suspect you are using the wrong linker command file.  An entry in that file should keep this ...

Raymond Mack said:

warning #10247-D: creating output section ".vtable" without a SECTIONS specification

... from happening.  

That diagnostic means one or more files (though probably just one) contain an input section named .vtable.  These input sections are combined into an output section also named .vtable.  That output section is allocated to memory using a default algorithm that is almost certain to be wrong.  

To see which object files (which might come from a library) contribute a .vtable input section, look in the linker map file.  Search it for .vtable.

How did you get your linker command file?  Why doesn't it contain an entry to specifically allocate the .vtable section correctly?

Thanks and regards,

-George

George:

I think I know *what* is happening now but not why. This is coming from the msp432e4_driverlib.a but for some reason my project started pulling in the FreeRTOS library instead of the TIRTOS file. Off to see what mischief happened in my linker section of properties under libraries and paths.

This project had been working just fine, but with a bunch of warnings. Somewhere along the line I must have accidentally changed one of the build parameters without realizing it.

Ray

George:

I have run down quite a few rabbit holes on this one.  I was wrong in my previous post and I am not pulling in the Free RTOS library but the generic CCS library.  The following from my map file should help:

C:/ti/simplelink_msp432e4_sdk_2_30_00_14/source/ti/devices/msp432e4/driverlib/lib/ccs/m4f/msp432e4_driverlib.a
interrupt_MSP432E411Y.obj 148 20 620
emac_MSP432E411Y.obj 756 24 0
gpio_MSP432E411Y.obj 488 72 0
sysctl_MSP432E411Y.obj 550 0 0
uart_MSP432E411Y.obj 222 64 0
flash_MSP432E411Y.obj 20 0 0
+--+-----------------------------+--------+---------+---------+
Total: 2184 180 620

The reference to .vtable is coming from interrupt_MSP432E411Y.obj. 

I have looked at TIRTOS command files and the FreeRTOS and NoRTOS command files in both the source/ti/boards tree and in the examples tree.  I have found a significant number of differences between the linker command files.

I suspect that the line:

.TI.ramfunc : {} load=FLASH, run=SRAM, table(BINIT)

conflicts with the line:

.vtable > SRAM

and it certainly conflicts with the line:

.vatble > 0x2000000

I believe the first line from numerous TI RTOS example command files is putting the interupt vectors in a .vec section rather than in the .vtable section.  My guess is that the .vec and vtable are two names for exactly the same information.

Is there some conflict between using TI RTOS and using the Tiva/MSP432 driverlib?  I suspect that using the CCS driverlib is the source of the issue.

Ray

Hi Raymond,

1, What RTOS do you want to use? TI-RTOS or FreeRTOS?

2. What SDK and version are you using?

3. Can you import an example from the SDK for the desired RTOS and build it?

4. Where did you get the project you are trying to build?

Todd

Todd:

Answers:

1) using TI RTOS.

2) using simplelink_msp432e4_sdk_2_30_00_14

3) Yes, but none of the examples use the SimplLink version of the Tiva driverlib

4) This is my own creation, based loosely on the out_of_the_box demo but using the SimpleLink Driverlib for direct connection to some peripherals like the UARTs.

I have nailed down the problem to an incompatible naming of the vector area between TI RTOS Hwi and SimpleLink Driverlib interrupts. TI RTOS uses ".vecs" and Driverlib uses ".vtable" for the exact same area of memory.

It really doesn't help much that when I look at all of the available example linker command files I see 10 different ways of doing the linker step.

After some direction from my FAE, I found the linker user guide and was able to decipher that I should make the .vtable a dummy section so the linker doesn't try to allocate space for it. It is not entirely clear that the linker will correctly glue all of the interrupt code together and actually load any statically generated data into the vector table. It seems to be OK since my UART interrupt function gets called.

The crash problem may or may not be related. I am trying to use a Mailbox to send characters back to my processing thread from the interrupt. Since my interrupts occur while the Idle task is running, the failure occurs on the stack of that task.  When I do a Mailbox_send the system generates a stack out of bounds error during the scheduling process. (It is so cool that I can step through the O/S and see what is happening!!!) I have made all of the task stacks on the order of 8192 as well as 16000 bytes of system stack. It would seem it is not a stack overflow problem from a single interrupt, but it is unclear what is happening to the stack.

I am not comfortable having something like that possible in what ought to be pretty mundane RTOS code, but I have worked around it for the time being by just having my task hog the CPU on receive rather than using interrupts.

Words of wisdom appreciated.

Ray

1. Don't use TivaWare driverlib on the MSP432E4. There is a driverlib in the SimpleLink SDK that you can use. It's in <sdk>\source\ti\devices\msp432e4\driverlib.

2. I'd recommend starting with a simple TI-RTOS application and add your items to it. 

3. When using driverlib with TI-RTOS, make sure not to not supply a vector table and do not use the IntRegister. 

4. How is the UART ISR being created? Are you using the TI Driver in the SDK? Writing it yourself? If the latter, again, make sure not to use the IntRegister function as that messes up the vector table managed by the kernel.

Todd

Todd:

1) You misunderstand.   I am using the SimpleLink Driverlib.

The SimpleLink Driverlib has the Tiva Driverlib (and Stellaris before that) as its parent. It was moved from the TIva line to the SImpleLink line, apparently with only minor changes. Makes using it really easy when moving between product lines.

2) There really isn't a simple TI RTOS example in SimpleLink.  I did basically start from scratch with pretty basic RTOS functionality. About as close as you can get to "Hello World" with a little NDK thrown in for good measure.

3) This instruction not to use the Driverlib interrupt facility in a TI RTOS environment really needs to be in both the Driverlib User Guide as well as the BIOS User Guide. It looks like one must use the Hwi_create() function to register a user interrupt with the BIOS interrupt system. I'll give it a go later today.

4) I just wrote my ISR function and registered it with the Driverlib function.  From your feedback, not the way to go.

The SDK Driver and the SDK Driverlib are two totally different "products". I *really* don't want to use the Driver because it just adds a bunch of code bloat.  The Driverlib is quite adequate for my needs if I can get it connected to the interrupts when needed. At least the SDK Driver isn't as bad as using CMSIS!

Mack,

TI-RTOS also supports zero-latency (unmanaged) interrupts. The kernel adds no latency to them (so it's basically just like bare metal). The caveat is a zero-latency interrupt cannot make any kernel calls (e.g. calling Semaphore_post is a no-no). More details here: http://processors.wiki.ti.com/index.php/SYS/BIOS_for_Stellaris_Devices#Zero_Latency_Interrupt_Support

Let me know if you hit any issues with Hwi_create(). 

Todd