Sign in
Search msp430
Subscribe to msp430
Ads
Discussion Groups
See Also
Discussion Groups | MSP430 | MSP430F427A rebooting itself
The purpose of this group is to foster exchange of information on the Texas Instruments MSP430 family of microcontrollers and related tools. Everyone welcome, all levels of familiarity/expertise.
MSP430F427A rebooting itself - ckue...@primexinc.com - Sep 17 16:32:30 2009
Hello,
I am working on an MSP430F427A design. The code is built on known working code written for an MSP430F413.
I am using the IAR Embedded Workbench and the MSP430 USB debugger. I've done a few projects using various MSP430 devices, but this one has thrown me a curve.
The program starts out, initializes the clock and WDT as an interval timer, and then enables interrupts. Everything runs great until the first WDT interrupt. When the code reaches the reti instruction at the end of the IRQ handler, it goes to the reset vector and restarts. The debugger shows a normal call stack.
I've never seen this behavior on any other MSP430 project I've been involved with. As I said, the code worked well on the MSP430F413, and I've modified it as needed to run on the '427A.
Any suggestions would be greatly appreciated.
Chuck Kuecker
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
I am working on an MSP430F427A design. The code is built on known working code written for an MSP430F413.
I am using the IAR Embedded Workbench and the MSP430 USB debugger. I've done a few projects using various MSP430 devices, but this one has thrown me a curve.
The program starts out, initializes the clock and WDT as an interval timer, and then enables interrupts. Everything runs great until the first WDT interrupt. When the code reaches the reti instruction at the end of the IRQ handler, it goes to the reset vector and restarts. The debugger shows a normal call stack.
I've never seen this behavior on any other MSP430 project I've been involved with. As I said, the code worked well on the MSP430F413, and I've modified it as needed to run on the '427A.
Any suggestions would be greatly appreciated.
Chuck Kuecker
------------------------------------
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430F427A rebooting itself - OneStone - Sep 17 16:47:20 2009
You've missed something in the change over. Either a vector address, or
the wrong ISR order. Assuming you've changed no other code of course.
Al
c...@primexinc.com wrote:
> Hello,
>
> I am working on an MSP430F427A design. The code is built on known working code written for an MSP430F413.
>
> I am using the IAR Embedded Workbench and the MSP430 USB debugger. I've done a few projects using various MSP430 devices, but this one has thrown me a curve.
>
> The program starts out, initializes the clock and WDT as an interval timer, and then enables interrupts. Everything runs great until the first WDT interrupt. When the code reaches the reti instruction at the end of the IRQ handler, it goes to the reset vector and restarts. The debugger shows a normal call stack.
>
> I've never seen this behavior on any other MSP430 project I've been involved with. As I said, the code worked well on the MSP430F413, and I've modified it as needed to run on the '427A.
>
> Any suggestions would be greatly appreciated.
>
> Chuck Kuecker
> ------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
the wrong ISR order. Assuming you've changed no other code of course.
Al
c...@primexinc.com wrote:
> Hello,
>
> I am working on an MSP430F427A design. The code is built on known working code written for an MSP430F413.
>
> I am using the IAR Embedded Workbench and the MSP430 USB debugger. I've done a few projects using various MSP430 devices, but this one has thrown me a curve.
>
> The program starts out, initializes the clock and WDT as an interval timer, and then enables interrupts. Everything runs great until the first WDT interrupt. When the code reaches the reti instruction at the end of the IRQ handler, it goes to the reset vector and restarts. The debugger shows a normal call stack.
>
> I've never seen this behavior on any other MSP430 project I've been involved with. As I said, the code worked well on the MSP430F413, and I've modified it as needed to run on the '427A.
>
> Any suggestions would be greatly appreciated.
>
> Chuck Kuecker
> ------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430F427A rebooting itself - old_cow_yellow - Sep 18 2:11:02 2009
--- In m...@yahoogroups.com, ckuecker@... wrote:
>
> Hello,
>
> I am working on an MSP430F427A design. The code is built on known working code written for an MSP430F413.
>
> I am using the IAR Embedded Workbench and the MSP430 USB debugger. I've done a few projects using various MSP430 devices, but this one has thrown me a curve.
>
> The program starts out, initializes the clock and WDT as an interval timer, and then enables interrupts. Everything runs great until the first WDT interrupt. When the code reaches the reti instruction at the end of the IRQ handler, it goes to the reset vector and restarts. The debugger shows a normal call stack.
>
> I've never seen this behavior on any other MSP430 project I've been involved with. As I said, the code worked well on the MSP430F413, and I've modified it as needed to run on the '427A.
>
> Any suggestions would be greatly appreciated.
>
> Chuck Kuecker
>
Not clear to me what you mean by "The debugger shows a normal call stack." Did you examine the top two words in the stack before the WDT-ISR reaches the reti? Those two words could cause a crash when reti is executed.
After a reset, the c start-up code mess up a few things. Is the code in question written in c?
Also note that F427A uses WDT+ while F417 uses WDT. I don't know if that makes much differences.
-- OCY
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
>
> Hello,
>
> I am working on an MSP430F427A design. The code is built on known working code written for an MSP430F413.
>
> I am using the IAR Embedded Workbench and the MSP430 USB debugger. I've done a few projects using various MSP430 devices, but this one has thrown me a curve.
>
> The program starts out, initializes the clock and WDT as an interval timer, and then enables interrupts. Everything runs great until the first WDT interrupt. When the code reaches the reti instruction at the end of the IRQ handler, it goes to the reset vector and restarts. The debugger shows a normal call stack.
>
> I've never seen this behavior on any other MSP430 project I've been involved with. As I said, the code worked well on the MSP430F413, and I've modified it as needed to run on the '427A.
>
> Any suggestions would be greatly appreciated.
>
> Chuck Kuecker
>
Not clear to me what you mean by "The debugger shows a normal call stack." Did you examine the top two words in the stack before the WDT-ISR reaches the reti? Those two words could cause a crash when reti is executed.
After a reset, the c start-up code mess up a few things. Is the code in question written in c?
Also note that F427A uses WDT+ while F417 uses WDT. I don't know if that makes much differences.
-- OCY
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: MSP430F427A rebooting itself - ckue...@primexinc.com - Sep 18 10:05:43 2009
The call stack window in the IAR IDE shows only the startup call to
main(); the call to the function being executed when the interrupt hits, and the interrupt itself.
I tried changing the code around and got different stack contents, but the return address for the ISR is always wrong.
The code is in C. We do little assembly here.
The WDT+ seems to only be different in watchdog mode - the enhancements are disabled in interval timer mode.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
main(); the call to the function being executed when the interrupt hits, and the interrupt itself.
I tried changing the code around and got different stack contents, but the return address for the ISR is always wrong.
The code is in C. We do little assembly here.
The WDT+ seems to only be different in watchdog mode - the enhancements are disabled in interval timer mode.
------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Re: MSP430F427A rebooting itself - OneStone - Sep 18 10:24:40 2009
Try this. Instead of using the WDT as an interval timer use the timer
overflow, bypassing the WDT. this will at least allow you to pin down
whether or not you have a WDT issue or a generic interrupt issue. The
fact that the WDT's are different might be a big clue. Also try making
the WDT timer interval as long as possible so that some processing gets
done first, or at least don't enable it until the first function has
been executed at least once. At present you don't seem to know where you
are. Find a starting point at least then take it from there. Start from
basics. Disabe the WDT interrupt, if all goes smoothly extend the timing
if you can, or the point at which it activates. if the WDT isr causes an
issue wherever it is activated and you can't figure out why, then
disable it again and see if other isr's will do the same, try a similar
ISR like a timer overflow, if that doesn't do it then look for the
unexpected.
you probably don't have any unused ISR's enabled or handled, for
example. if one of those is occurring, like, say an oscillator fault,
with no oscillator fault interrupt handler, your program will exhibit
exactly this sort of behaviour, or an NMI with no NMI handler. that is
why it is ALWAYS a good thing to have at least some kind of handler for
every possible interrupt, especially the non maskable ones. so, try
putting those in place, just put in a stub handler at it. You'll be
amazed what turns up. I wouldn't be at all surprised if your problem was
a screwy clock! The NMI/OCF/Flash vector for example and trap on it
Al
c...@primexinc.com wrote:
> The call stack window in the IAR IDE shows only the startup call to
> main(); the call to the function being executed when the interrupt hits, and the interrupt itself.
>
> I tried changing the code around and got different stack contents, but the return address for the ISR is always wrong.
>
> The code is in C. We do little assembly here.
>
> The WDT+ seems to only be different in watchdog mode - the enhancements are disabled in interval timer mode.
>
> ------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
overflow, bypassing the WDT. this will at least allow you to pin down
whether or not you have a WDT issue or a generic interrupt issue. The
fact that the WDT's are different might be a big clue. Also try making
the WDT timer interval as long as possible so that some processing gets
done first, or at least don't enable it until the first function has
been executed at least once. At present you don't seem to know where you
are. Find a starting point at least then take it from there. Start from
basics. Disabe the WDT interrupt, if all goes smoothly extend the timing
if you can, or the point at which it activates. if the WDT isr causes an
issue wherever it is activated and you can't figure out why, then
disable it again and see if other isr's will do the same, try a similar
ISR like a timer overflow, if that doesn't do it then look for the
unexpected.
you probably don't have any unused ISR's enabled or handled, for
example. if one of those is occurring, like, say an oscillator fault,
with no oscillator fault interrupt handler, your program will exhibit
exactly this sort of behaviour, or an NMI with no NMI handler. that is
why it is ALWAYS a good thing to have at least some kind of handler for
every possible interrupt, especially the non maskable ones. so, try
putting those in place, just put in a stub handler at it. You'll be
amazed what turns up. I wouldn't be at all surprised if your problem was
a screwy clock! The NMI/OCF/Flash vector for example and trap on it
Al
c...@primexinc.com wrote:
> The call stack window in the IAR IDE shows only the startup call to
> main(); the call to the function being executed when the interrupt hits, and the interrupt itself.
>
> I tried changing the code around and got different stack contents, but the return address for the ISR is always wrong.
>
> The code is in C. We do little assembly here.
>
> The WDT+ seems to only be different in watchdog mode - the enhancements are disabled in interval timer mode.
>
> ------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
Re: Re: MSP430F427A rebooting itself - OneStone - Sep 18 10:36:55 2009
In fact one of the commonest faults on the MSP is clock start up failure
and this is how it manifests itself. I'm so used to having clock
recovery in all my code i forgot about it.
Al
OneStone wrote:
> Try this. Instead of using the WDT as an interval timer use the timer
> overflow, bypassing the WDT. this will at least allow you to pin down
> whether or not you have a WDT issue or a generic interrupt issue. The
> fact that the WDT's are different might be a big clue. Also try making
> the WDT timer interval as long as possible so that some processing gets
> done first, or at least don't enable it until the first function has
> been executed at least once. At present you don't seem to know where you
> are. Find a starting point at least then take it from there. Start from
> basics. Disabe the WDT interrupt, if all goes smoothly extend the timing
> if you can, or the point at which it activates. if the WDT isr causes an
> issue wherever it is activated and you can't figure out why, then
> disable it again and see if other isr's will do the same, try a similar
> ISR like a timer overflow, if that doesn't do it then look for the
> unexpected.
>
> you probably don't have any unused ISR's enabled or handled, for
> example. if one of those is occurring, like, say an oscillator fault,
> with no oscillator fault interrupt handler, your program will exhibit
> exactly this sort of behaviour, or an NMI with no NMI handler. that is
> why it is ALWAYS a good thing to have at least some kind of handler for
> every possible interrupt, especially the non maskable ones. so, try
> putting those in place, just put in a stub handler at it. You'll be
> amazed what turns up. I wouldn't be at all surprised if your problem was
> a screwy clock! The NMI/OCF/Flash vector for example and trap on it
>
> Al
>
> c...@primexinc.com wrote:
>> The call stack window in the IAR IDE shows only the startup call to
>> main(); the call to the function being executed when the interrupt hits, and the interrupt itself.
>>
>> I tried changing the code around and got different stack contents, but the return address for the ISR is always wrong.
>>
>> The code is in C. We do little assembly here.
>>
>> The WDT+ seems to only be different in watchdog mode - the enhancements are disabled in interval timer mode.
>>
>> ------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )
and this is how it manifests itself. I'm so used to having clock
recovery in all my code i forgot about it.
Al
OneStone wrote:
> Try this. Instead of using the WDT as an interval timer use the timer
> overflow, bypassing the WDT. this will at least allow you to pin down
> whether or not you have a WDT issue or a generic interrupt issue. The
> fact that the WDT's are different might be a big clue. Also try making
> the WDT timer interval as long as possible so that some processing gets
> done first, or at least don't enable it until the first function has
> been executed at least once. At present you don't seem to know where you
> are. Find a starting point at least then take it from there. Start from
> basics. Disabe the WDT interrupt, if all goes smoothly extend the timing
> if you can, or the point at which it activates. if the WDT isr causes an
> issue wherever it is activated and you can't figure out why, then
> disable it again and see if other isr's will do the same, try a similar
> ISR like a timer overflow, if that doesn't do it then look for the
> unexpected.
>
> you probably don't have any unused ISR's enabled or handled, for
> example. if one of those is occurring, like, say an oscillator fault,
> with no oscillator fault interrupt handler, your program will exhibit
> exactly this sort of behaviour, or an NMI with no NMI handler. that is
> why it is ALWAYS a good thing to have at least some kind of handler for
> every possible interrupt, especially the non maskable ones. so, try
> putting those in place, just put in a stub handler at it. You'll be
> amazed what turns up. I wouldn't be at all surprised if your problem was
> a screwy clock! The NMI/OCF/Flash vector for example and trap on it
>
> Al
>
> c...@primexinc.com wrote:
>> The call stack window in the IAR IDE shows only the startup call to
>> main(); the call to the function being executed when the interrupt hits, and the interrupt itself.
>>
>> I tried changing the code around and got different stack contents, but the return address for the ISR is always wrong.
>>
>> The code is in C. We do little assembly here.
>>
>> The WDT+ seems to only be different in watchdog mode - the enhancements are disabled in interval timer mode.
>>
>> ------------------------------------
(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )