Non plugged ISR

Hi Marc,

what device are we dealing with here?

Sorry.  MSP4305310.

Marc,

have you checked if you have your watchdog timer disabled?

See if you have this in your .cfg file

var Boot = xdc.useModule('ti.catalog.msp430.init.Boot');
Boot.disableWatchdog = true;

See this page for the MSP430 startup sequence for SYS/BIOS.

http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_MSP430

I added the lines above, and the code still jumps to the non-plugged ISR.  I am about to read the above linked page.  Thank you.  It appears to me that this function is called when an interrupt fires that has not been given an ISR to jump to.  Is this correct?  If so, how do I find out which interrupt?

I have been able to determine that a portion of my code is causing this problem.  It would be great if I could find out how the non-plugged ISR is called so that I can zero in on suspected areas.  Thank you.

Marc,

You are correct, this is a trap mechanism to detect firing of interrupts that have not been configured for SYS/BIOS.  The numeric value indicates the interrupt vector priority number from the device data sheet, in this case, the vector with priority “0”, corresponding to the vector at 0xFF80.

In a typical CCS project build you can find the generated interrupt stubs in a file named “HwiFuncs.c”, typically in a project subdirectory “src\sysbios”.  You’ll probably see this in your file:

#pragma vector = 0;
__interrupt Void ti_sysbios_family_msp430_Hwi0(Void)
{
    while(1){};
}

If you want to disable SYS/BIOS' plugging of unused interrupts (and plug individual interrupts on your own), you can turn off the auto-fill, as described here: http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_MSP430#Disable_auto-fill_of_unused_interrupt_vectors_with_traps

Also, you can set a breakpoint on the interrupt stub entry: http://processors.wiki.ti.com/index.php/SYS/BIOS_for_the_MSP430#Set_a_breakpoint_at_the_entry_to_a_SYS.2FBIOS_interrupt_stub

Hope this helps…

Scott

Hi Marc,

Marc Bunyard said:

It appears to me that this function is called when an interrupt fires that has not been given an ISR to jump to.  Is this correct?

This is correct.

I'm not sure which version of SYS/BIOS you are using, but if it is possible I'd recommend upgrading to at least BIOS 6_33_04_39. Starting with this version, you wouldn't see the "nonPlugged" anymore, but instead you'd see a stub function will spinning on a while(1) loop. The name of the stub function allows you to identify which interrupt was generated.

If you can't upgrade your SYS/BIOS, you can use the disassembly window to manually find these stub functions:

ti_sysbios_family_msp430_Hwi0 for interrupt vector 0

ti_sysbios_family_msp430_Hwi1 for interrupt vector 1

...

ti_sysbios_family_msp430_Hwin for interrupt vector n

By inserting a breakpoint and running your code you can see with which stub functions the interrupt was triggered.

Getting closer I believe.  The code section that runs is actually:

/*
 *  ======== Hwi_nonPluggedIsr ========
 */
Void Hwi_nonPluggedIsr(UArg intNum)
{
    while(TRUE);
}

This appears to be called through:

Void ti_sysbios_family_msp430_Hwi0(Void)
{
    ti_sysbios_family_msp430_Hwi_nonPluggedIsr__I(0);
}

but I can't verify this.  The breakpoint set at ti_sysbios_family_msp430_Hwi_nonPluggedIsr__I(0); doesn't fire.  This is making me think it's a different vector. 

Thanks Tom,

I'm using SYS/BIOS 6.33.05.46.  That looks like it should be up to date.  If I set the breakpoints in assembly, one of them should fire correct?

Scott and Tom,

Hah! I'm getting somewhere.  I had the above version of BIOS but wasn't pointing to it! :( ID10T error. I pointed to the 6.33 version, and got the code that tells me which vector caused this.  It's 57 WDTIFG.  I inserted the watchdog disable lines in the cfg script, but this still appears to be active.  Suggestions?

Thank you.

Marc

Marc,

Where are you seeing the code for Hwi_nonPluggedISR()?  This function was removed last March, in favor of the while(1) call for the interrupt traps.  (This was done to avoid elimination of the traps for  ELF builds, and to shrink the footprint of the traps.)  If you are using 6.33.05.46 you should *not* be seeing this function anymore.  Is it possible this program was built with an older version of SYS/BIOS?

In either case, you should be able to set the breakpoint on “ti_sysbios_family_msp430_Hwi0”.  Did you try this label?  

Thanks,
Scott

Marc,

Ahhh, OK! 

Are you using the WDT in interval timer mode somewhere in your code?  Is it possible you’ve integrated some code that is using the WDT, for example, for key debouncing?  

The WDT disable lines Tom sent are used to halt the WDT when it is running in watchdog mode coming out of reset.  (This is actually done automatically earlier in the boot, and you don’t need to add these lines to your application configuration.)  This will simply disable the watchdog from its default behavior of reseting the CPU after a short interval of not being serviced.

If the WDT “interval timer mode” interrupt is going off, some code has reconfigured and started the WDT running.  Or, the CPU could have just branched to this trap location too.  Is the GIE bit in the SR “1”?  If so, then it must have been an errant CPU branch.  If GIE is “0” it still could be an errant branch, but from some point where interrupts were disabled.  If so, maybe look at the stack for a return address?

Scott

Scott,

I don't know if you had the chance to see the post before yours, but I was NOT using 6.33.05.46 when I saw this code.  I was using 6.32.05.54.  Sorry, my fault. I'm not sure what happened, but the wrong box was checked. I checked the right one and got my answer!

I just tried adding  WDTCTL = WDTPW+WDTHOLD;                   // Stop WDT
to my initialization code (I'm getting vector 57 Watchdog Timer A interval timer) and it didn't stop the interrupt.  Hmm. Timer A, not the watchdog timer.  Time to read.

Now that I've changed to 6.33.05.46, I'm getting a warning that I've seen before, and thought I fixed.  ti.??? targets.MSP430 is incompatible with 6.33.05.46.  What needs to be upgraded? 

I have to take off, so I'll be able to view any responses in the morning.

Thanks again.  Very helpful.

Marc

Marc,

Watchdog “Timer A” indicates that the watchdog timer on the device is the “A” revision of the WDT (a WDT_A).  

Timers A0, A1 and A2 are separate peripherals with capture compare, etc., and separate interrupt vectors.

For the new warning, I’m guessing you need to point to an updated XDCtools.  For SYS/BIOS 6.33.05.46 you should use XDCtools 3.23.02.47 or later (available here if you don’t have it: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/3_23_02_47/index_FDS.html).

Scott

Scott,

Thank you for the link.  Downloading now.  I'm still curious about this watchdog timer.  I have the following line in my *cfg script:

var Boot = xdc.useModule('ti.catalog.msp430.init.Boot');
Boot.disableWatchdog = true;

Shouldn't this prevent the interrupt from occurring? If it should, then somewhere in the code I'm re-enabling this interrupt.  I should point out that this is not interrupt 63, the Watchdog Timer interrupt.  It's interrupt 57, the Watchdog Timer_A Interval Timer Mode.  Is there something different that needs to be done?

Marc

Marc,

Coming out of reset the WDT is running in “watchdog mode” and if it is not dealt with it will *reset* the CPU after about 32msec.  The two lines in your configuration script are to tell the Boot module to immediately disable the watchdog during the boot process.  (And these lines can be removed, because this is already the default behavior for the Boot module).  This simply stops the WDT from counting:  

/*
 *  ======== Boot_disableWatchdog ========
 */
Void Boot_disableWatchdog(UInt address)
{
    REG(address) = WDTPW + WDTHOLD;     /* disable watchdog */
}

It does not configure the WDT into an alternate “interval mode” that will generate an *interrupt* (on vector 57) after a timeout interval.  If this interrupt is indeed triggering then somewhere else in the application the WDT is being setup and started in interval mode.

There is a good description of the WDT in chapter 14 in the family user’s guide (http://www.ti.com/lit/ug/slau208j/slau208j.pdf):

...

Scott

Scott,

Thanks.  Time to dig.  Now I know what I'm looking for.  Timer is getting started, and the interrupt is unmasked.  I will let you know what I find.

Scott,

I don't know if this is related or not. I upgraded to xdctools_3_23_02_47, and I'm still getting the following warning:

Warning: xdc.cfg.INCOMPATIBLE_TARGET_VERSION: current target 'ti.targets.msp430.MSP430X' [1,0,4.0,0] is not compatible with targets used to build the following packages; package ti.sysbios.family.msp430 [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/family/msp430/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]
; package ti.sysbios [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]
; package ti.sysbios.hal [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/hal/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]
; package ti.sysbios.knl [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/knl/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]
; package ti.sysbios.gates [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/gates/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]
; package ti.sysbios.xdcruntime [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/xdcruntime/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]
; package ti.sysbios.heaps [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/heaps/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]
; package ti.sysbios.utils [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/utils/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]

Now the new mystery.  I checked SRFIE1 after breaking at the first instruction in main, and at breakpoints at the beginning of each task.  WDTIE is 0.  So SYS/BIOS is behaving correctly, and as far as I know I am making zero calls to change WDTIE.  About 20 seconds later, WDTIE is set and I get the interrupt.  Can this be related to the incompatibility?

Marc

Marc,

It looks like the older version of XDCtools is still being used for the build.  Did you update the project properties to use the new version of XDCtools?  If not, you can right click on the project, select properties, then General, click the RTSC tab, select 3.23.02.47 from the drop down list for “XDCtools version”, then Apply, OK, and then clean and rebuild the project.  I think the warning should go away then.

I can’t think of any way this mismatch could cause a write of WDTIE.

Scott

Scott,

The following is in the console output from the compile:

'Invoking: XDCtools'
"E:/ti/xdctools_3_23_02_47/xs" --xdcpath="E:/ti/ipc_1_24_03_32/packages;E:/ti/bios_6_33_05_46/packages;E:/ti/bios_6_33_05_46/packages;" xdc.tools.configuro -o configPkg -t ti.targets.msp430.MSP430X -p ti.platforms.msp430:MSP430F5310 -r release -c "E:/ti/ccsv5/tools/compiler/msp430" --compileOptions "-g --optimize_with_debug" "../920_SensorBoard_RTOS.cfg"
making package.mak (because of package.bld) ...
generating interfaces for package configPkg (because package/package.xdc.inc is older than package.xdc) ...
configuring 920_SensorBoard_RTOS.x430X from package/cfg/920_SensorBoard_RTOS_p430X.cfg ...
Warning: xdc.cfg.INCOMPATIBLE_TARGET_VERSION: current target 'ti.targets.msp430.MSP430X' [1,0,4.0,0] is not compatible with targets used to build the following packages; package ti.sysbios.family.msp430 [in E:/ti/bios_6_33_05_46/packages/ti/sysbios/family/msp430/] was built using 'ti.targets.msp430.MSP430X' [1,0,4.1,0]

It looks like I have the recommended combination.  Am I missing something?  Also, any suggestions on how to find out where the WDTIE is getting set?  I wish I could set a breakpoint for when SRFIE is written.

Marc,
the warning you are getting is just saying that the XDCtools runtime library is built with the MSP430 compiler (4.0.0) that is different from the compiler used to build SYS/BIOS libraries (4.1.0). You could rebuild XDCtools runtime library to avoid the warning, but it's not very likely that the difference between two compiler versions would cause the problem with the watchdog timer.
I'll leave to Scott to help you with the timer problem, but if you decide to rebuild the library, here are the instructions: http://rtsc.eclipse.org/docs-tip/Working_with_xdc.runtime#Re-building_xdc.runtime_Support_Packages. 

Thank you for the re-build info.  I'll try that. 

Marc,
wait just a little, I could have been wrong. Maybe you just need to switch to 4.1.0 compiler, in case you are using 4.0.0.

Edit: I confirmed that the warning is caused by the compiler version used to build files in the project. SYS/BIOS libraries are built with a compiler newer than the compiler you are using.  You should switch to 4.1.0 to avoid the warning.

How do I upgrade to 4.1?  I've been poking around and can't figure this one out.

If you click on Help->Check for Updates, you should get an option to install a newer MSP430 compiler. Then, in Project->Properties->CCS General, you can switch between compiler versions under the Compiler Version drop-down list.