Hi,
We're running a program in a while loop and we believe we disable the
Watchdog correctly in the beginning. The program runs correctly and never
resets the CPU (by never I mean for at least 24 hours). However, when we go
into a specific state and execute a specific block of code afterwards we
get interrupted but it seems that it's stuck in the main loop.
We're using mspgcc and mspdebug, and the chip is the MSP430F5340. When
hitting CTRL+C while in the "stuck" state this is what it shows:
(mspdebug) run
Running. Press Ctrl+C to interrupt...
^C
( PC: 03ffe) ( R4: 00482) ( R8: 04ab0) (R12: 00004)
( SP: 03388) ( R5: 04ab0) ( R9: 022a6) (R13: 0000c)
( SR: 00009) ( R6: 00000) (R10: 02308) (R14: 0412e)
( R3: 00000) ( R7: 0431f) (R11: 0418b) (R15: 04ab0)
__wdt_clear_value+0x14cc:
03ffe: ff 3f JMP __wdt_clear_value+0x14cc
04000: ff 3f JMP __wdt_clear_value+0x14ce
04002: ff 3f JMP __wdt_clear_value+0x14d0
04004: ff 3f JMP __wdt_clear_value+0x14d2
04006: ff 3f JMP __wdt_clear_value+0x14d4
04008: ff 3f JMP __wdt_clear_value+0x14d6
0400a: ff 3f JMP __wdt_clear_value+0x14d8
0400c: ff 3f JMP __wdt_clear_value+0x14da
(mspdebug)
Any ideas what's going on?
Thanks!
-Mohammad
Watchdog timer issue
Started by ●December 11, 2012
Reply by ●December 11, 20122012-12-11
First, I do not think you have a Watchdog timer issue.
Second, I do not think you are stuck your main loop because the code dump you provide starting at your PC location does not look like main loop code. It looks like uninitialized or non-existing RAM. (I could look up the memory map for the 5340, but I won't because YOU need to know where your resources are, I don't.) And, no I do not know why mspdebug is disassembling the 3f as referring things to the wdt_clear_value, but I do believe it is spurious.
Third, your stack pointer should be point to RAM and should contain useful information about where a subroutine or interrupt routine should return. In fact, it is such an odd number for the stack pointer, I wonder whether you have over or under flowed the stack.
Fourth, do the register values >R3 tell you anything about the state of your specific block of code.
Fifth, (maybe this should have been first) do you have a handler for every interrupt vector? If not, make sure that you do so you can determine whether an accidently enabled interrupt is sending your program into unknown territory.
Sixth, any more questions about your offending block of code should probably include the code in question.
Emmett Redd, Ph.D., Professor mailto:E...@MissouriState.Edu
Physics, Astronomy, and Materials Science Office: 417-836-5221
Missouri State University Dept: 417-838-5131
901 S NATIONAL AVENUE FAX: 417-836-6226
SPRINGFIELD, MO 65897 USA Lab: 417-836-3770
It is clear that thought is not free if the profession of certain opinions make it impossible to earn a living. -- Bertrand Russell
> -----Original Message-----
> From: m... [mailto:m...] On Behalf
> Of Mohammad Afaneh
> Sent: Monday, December 10, 2012 5:18 PM
> To: m...
> Subject: [msp430] Watchdog timer issue
>
> Hi,
>
> We're running a program in a while loop and we believe we disable the
> Watchdog correctly in the beginning. The program runs correctly and
> never resets the CPU (by never I mean for at least 24 hours). However,
> when we go into a specific state and execute a specific block of code
> afterwards we get interrupted but it seems that it's stuck in the main
> loop.
>
> We're using mspgcc and mspdebug, and the chip is the MSP430F5340. When
> hitting CTRL+C while in the "stuck" state this is what it shows:
>
> (mspdebug) run
> Running. Press Ctrl+C to interrupt...
> ^C
> ( PC: 03ffe) ( R4: 00482) ( R8: 04ab0) (R12: 00004)
> ( SP: 03388) ( R5: 04ab0) ( R9: 022a6) (R13: 0000c)
> ( SR: 00009) ( R6: 00000) (R10: 02308) (R14: 0412e)
> ( R3: 00000) ( R7: 0431f) (R11: 0418b) (R15: 04ab0)
> __wdt_clear_value+0x14cc:
> 03ffe: ff 3f JMP __wdt_clear_value+0x14cc
> 04000: ff 3f JMP __wdt_clear_value+0x14ce
> 04002: ff 3f JMP __wdt_clear_value+0x14d0
> 04004: ff 3f JMP __wdt_clear_value+0x14d2
> 04006: ff 3f JMP __wdt_clear_value+0x14d4
> 04008: ff 3f JMP __wdt_clear_value+0x14d6
> 0400a: ff 3f JMP __wdt_clear_value+0x14d8
> 0400c: ff 3f JMP __wdt_clear_value+0x14da
> (mspdebug)
>
> Any ideas what's going on?
>
> Thanks!
>
> -Mohammad
>
>
>
Second, I do not think you are stuck your main loop because the code dump you provide starting at your PC location does not look like main loop code. It looks like uninitialized or non-existing RAM. (I could look up the memory map for the 5340, but I won't because YOU need to know where your resources are, I don't.) And, no I do not know why mspdebug is disassembling the 3f as referring things to the wdt_clear_value, but I do believe it is spurious.
Third, your stack pointer should be point to RAM and should contain useful information about where a subroutine or interrupt routine should return. In fact, it is such an odd number for the stack pointer, I wonder whether you have over or under flowed the stack.
Fourth, do the register values >R3 tell you anything about the state of your specific block of code.
Fifth, (maybe this should have been first) do you have a handler for every interrupt vector? If not, make sure that you do so you can determine whether an accidently enabled interrupt is sending your program into unknown territory.
Sixth, any more questions about your offending block of code should probably include the code in question.
Emmett Redd, Ph.D., Professor mailto:E...@MissouriState.Edu
Physics, Astronomy, and Materials Science Office: 417-836-5221
Missouri State University Dept: 417-838-5131
901 S NATIONAL AVENUE FAX: 417-836-6226
SPRINGFIELD, MO 65897 USA Lab: 417-836-3770
It is clear that thought is not free if the profession of certain opinions make it impossible to earn a living. -- Bertrand Russell
> -----Original Message-----
> From: m... [mailto:m...] On Behalf
> Of Mohammad Afaneh
> Sent: Monday, December 10, 2012 5:18 PM
> To: m...
> Subject: [msp430] Watchdog timer issue
>
> Hi,
>
> We're running a program in a while loop and we believe we disable the
> Watchdog correctly in the beginning. The program runs correctly and
> never resets the CPU (by never I mean for at least 24 hours). However,
> when we go into a specific state and execute a specific block of code
> afterwards we get interrupted but it seems that it's stuck in the main
> loop.
>
> We're using mspgcc and mspdebug, and the chip is the MSP430F5340. When
> hitting CTRL+C while in the "stuck" state this is what it shows:
>
> (mspdebug) run
> Running. Press Ctrl+C to interrupt...
> ^C
> ( PC: 03ffe) ( R4: 00482) ( R8: 04ab0) (R12: 00004)
> ( SP: 03388) ( R5: 04ab0) ( R9: 022a6) (R13: 0000c)
> ( SR: 00009) ( R6: 00000) (R10: 02308) (R14: 0412e)
> ( R3: 00000) ( R7: 0431f) (R11: 0418b) (R15: 04ab0)
> __wdt_clear_value+0x14cc:
> 03ffe: ff 3f JMP __wdt_clear_value+0x14cc
> 04000: ff 3f JMP __wdt_clear_value+0x14ce
> 04002: ff 3f JMP __wdt_clear_value+0x14d0
> 04004: ff 3f JMP __wdt_clear_value+0x14d2
> 04006: ff 3f JMP __wdt_clear_value+0x14d4
> 04008: ff 3f JMP __wdt_clear_value+0x14d6
> 0400a: ff 3f JMP __wdt_clear_value+0x14d8
> 0400c: ff 3f JMP __wdt_clear_value+0x14da
> (mspdebug)
>
> Any ideas what's going on?
>
> Thanks!
>
> -Mohammad
>
>
>
Reply by ●December 11, 20122012-12-11
Just to eliminate the WDT issue, you are using the following line:
void main(void)
{
WDTCTL = WDTPW+WDTHOLD; // Stop WDT
while(1) {
/* Your code */
}
}
On Mon, Dec 10, 2012 at 5:18 PM, Mohammad Afaneh wrote:
> **
> Hi,
>
> We're running a program in a while loop and we believe we disable the
> Watchdog correctly in the beginning. The program runs correctly and never
> resets the CPU (by never I mean for at least 24 hours). However, when we go
> into a specific state and execute a specific block of code afterwards we
> get interrupted but it seems that it's stuck in the main loop.
>
> We're using mspgcc and mspdebug, and the chip is the MSP430F5340. When
> hitting CTRL+C while in the "stuck" state this is what it shows:
>
> (mspdebug) run
> Running. Press Ctrl+C to interrupt...
> ^C
> ( PC: 03ffe) ( R4: 00482) ( R8: 04ab0) (R12: 00004)
> ( SP: 03388) ( R5: 04ab0) ( R9: 022a6) (R13: 0000c)
> ( SR: 00009) ( R6: 00000) (R10: 02308) (R14: 0412e)
> ( R3: 00000) ( R7: 0431f) (R11: 0418b) (R15: 04ab0)
> __wdt_clear_value+0x14cc:
> 03ffe: ff 3f JMP __wdt_clear_value+0x14cc
> 04000: ff 3f JMP __wdt_clear_value+0x14ce
> 04002: ff 3f JMP __wdt_clear_value+0x14d0
> 04004: ff 3f JMP __wdt_clear_value+0x14d2
> 04006: ff 3f JMP __wdt_clear_value+0x14d4
> 04008: ff 3f JMP __wdt_clear_value+0x14d6
> 0400a: ff 3f JMP __wdt_clear_value+0x14d8
> 0400c: ff 3f JMP __wdt_clear_value+0x14da
> (mspdebug)
>
> Any ideas what's going on?
>
> Thanks!
>
> -Mohammad
>
>
>
>
>
void main(void)
{
WDTCTL = WDTPW+WDTHOLD; // Stop WDT
while(1) {
/* Your code */
}
}
On Mon, Dec 10, 2012 at 5:18 PM, Mohammad Afaneh wrote:
> **
> Hi,
>
> We're running a program in a while loop and we believe we disable the
> Watchdog correctly in the beginning. The program runs correctly and never
> resets the CPU (by never I mean for at least 24 hours). However, when we go
> into a specific state and execute a specific block of code afterwards we
> get interrupted but it seems that it's stuck in the main loop.
>
> We're using mspgcc and mspdebug, and the chip is the MSP430F5340. When
> hitting CTRL+C while in the "stuck" state this is what it shows:
>
> (mspdebug) run
> Running. Press Ctrl+C to interrupt...
> ^C
> ( PC: 03ffe) ( R4: 00482) ( R8: 04ab0) (R12: 00004)
> ( SP: 03388) ( R5: 04ab0) ( R9: 022a6) (R13: 0000c)
> ( SR: 00009) ( R6: 00000) (R10: 02308) (R14: 0412e)
> ( R3: 00000) ( R7: 0431f) (R11: 0418b) (R15: 04ab0)
> __wdt_clear_value+0x14cc:
> 03ffe: ff 3f JMP __wdt_clear_value+0x14cc
> 04000: ff 3f JMP __wdt_clear_value+0x14ce
> 04002: ff 3f JMP __wdt_clear_value+0x14d0
> 04004: ff 3f JMP __wdt_clear_value+0x14d2
> 04006: ff 3f JMP __wdt_clear_value+0x14d4
> 04008: ff 3f JMP __wdt_clear_value+0x14d6
> 0400a: ff 3f JMP __wdt_clear_value+0x14d8
> 0400c: ff 3f JMP __wdt_clear_value+0x14da
> (mspdebug)
>
> Any ideas what's going on?
>
> Thanks!
>
> -Mohammad
>
>
>
>
>
Reply by ●December 11, 20122012-12-11
The PC is pointing to the last word of SRAM. This is more likely to be the
result of a crash rather than the reason for a crash (which there is no clue in
your what you post).
--- In m..., "Redd, Emmett R" wrote:
>
> First, I do not think you have a Watchdog timer issue.
>
> Second, I do not think you are stuck your main loop because the code dump you provide starting at your PC location does not look like main loop code. It looks like uninitialized or non-existing RAM. (I could look up the memory map for the 5340, but I won't because YOU need to know where your resources are, I don't.) And, no I do not know why mspdebug is disassembling the 3f as referring things to the wdt_clear_value, but I do believe it is spurious.
>
> Third, your stack pointer should be point to RAM and should contain useful information about where a subroutine or interrupt routine should return. In fact, it is such an odd number for the stack pointer, I wonder whether you have over or under flowed the stack.
>
> Fourth, do the register values >R3 tell you anything about the state of your specific block of code.
>
> Fifth, (maybe this should have been first) do you have a handler for every interrupt vector? If not, make sure that you do so you can determine whether an accidently enabled interrupt is sending your program into unknown territory.
>
> Sixth, any more questions about your offending block of code should probably include the code in question.
>
> Emmett Redd, Ph.D., Professor mailto:EmmettRedd@...
> Physics, Astronomy, and Materials Science Office: 417-836-5221
> Missouri State University Dept: 417-838-5131
> 901 S NATIONAL AVENUE FAX: 417-836-6226
> SPRINGFIELD, MO 65897 USA Lab: 417-836-3770
>
> It is clear that thought is not free if the profession of certain opinions make it impossible to earn a living. -- Bertrand Russell
>
> > -----Original Message-----
> > From: m... [mailto:m...] On Behalf
> > Of Mohammad Afaneh
> > Sent: Monday, December 10, 2012 5:18 PM
> > To: m...
> > Subject: [msp430] Watchdog timer issue
> >
> > Hi,
> >
> > We're running a program in a while loop and we believe we disable the
> > Watchdog correctly in the beginning. The program runs correctly and
> > never resets the CPU (by never I mean for at least 24 hours). However,
> > when we go into a specific state and execute a specific block of code
> > afterwards we get interrupted but it seems that it's stuck in the main
> > loop.
> >
> > We're using mspgcc and mspdebug, and the chip is the MSP430F5340. When
> > hitting CTRL+C while in the "stuck" state this is what it shows:
> >
> > (mspdebug) run
> > Running. Press Ctrl+C to interrupt...
> > ^C
> > ( PC: 03ffe) ( R4: 00482) ( R8: 04ab0) (R12: 00004)
> > ( SP: 03388) ( R5: 04ab0) ( R9: 022a6) (R13: 0000c)
> > ( SR: 00009) ( R6: 00000) (R10: 02308) (R14: 0412e)
> > ( R3: 00000) ( R7: 0431f) (R11: 0418b) (R15: 04ab0)
> > __wdt_clear_value+0x14cc:
> > 03ffe: ff 3f JMP __wdt_clear_value+0x14cc
> > 04000: ff 3f JMP __wdt_clear_value+0x14ce
> > 04002: ff 3f JMP __wdt_clear_value+0x14d0
> > 04004: ff 3f JMP __wdt_clear_value+0x14d2
> > 04006: ff 3f JMP __wdt_clear_value+0x14d4
> > 04008: ff 3f JMP __wdt_clear_value+0x14d6
> > 0400a: ff 3f JMP __wdt_clear_value+0x14d8
> > 0400c: ff 3f JMP __wdt_clear_value+0x14da
> > (mspdebug)
> >
> > Any ideas what's going on?
> >
> > Thanks!
> >
> > -Mohammad
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
--- In m..., "Redd, Emmett R" wrote:
>
> First, I do not think you have a Watchdog timer issue.
>
> Second, I do not think you are stuck your main loop because the code dump you provide starting at your PC location does not look like main loop code. It looks like uninitialized or non-existing RAM. (I could look up the memory map for the 5340, but I won't because YOU need to know where your resources are, I don't.) And, no I do not know why mspdebug is disassembling the 3f as referring things to the wdt_clear_value, but I do believe it is spurious.
>
> Third, your stack pointer should be point to RAM and should contain useful information about where a subroutine or interrupt routine should return. In fact, it is such an odd number for the stack pointer, I wonder whether you have over or under flowed the stack.
>
> Fourth, do the register values >R3 tell you anything about the state of your specific block of code.
>
> Fifth, (maybe this should have been first) do you have a handler for every interrupt vector? If not, make sure that you do so you can determine whether an accidently enabled interrupt is sending your program into unknown territory.
>
> Sixth, any more questions about your offending block of code should probably include the code in question.
>
> Emmett Redd, Ph.D., Professor mailto:EmmettRedd@...
> Physics, Astronomy, and Materials Science Office: 417-836-5221
> Missouri State University Dept: 417-838-5131
> 901 S NATIONAL AVENUE FAX: 417-836-6226
> SPRINGFIELD, MO 65897 USA Lab: 417-836-3770
>
> It is clear that thought is not free if the profession of certain opinions make it impossible to earn a living. -- Bertrand Russell
>
> > -----Original Message-----
> > From: m... [mailto:m...] On Behalf
> > Of Mohammad Afaneh
> > Sent: Monday, December 10, 2012 5:18 PM
> > To: m...
> > Subject: [msp430] Watchdog timer issue
> >
> > Hi,
> >
> > We're running a program in a while loop and we believe we disable the
> > Watchdog correctly in the beginning. The program runs correctly and
> > never resets the CPU (by never I mean for at least 24 hours). However,
> > when we go into a specific state and execute a specific block of code
> > afterwards we get interrupted but it seems that it's stuck in the main
> > loop.
> >
> > We're using mspgcc and mspdebug, and the chip is the MSP430F5340. When
> > hitting CTRL+C while in the "stuck" state this is what it shows:
> >
> > (mspdebug) run
> > Running. Press Ctrl+C to interrupt...
> > ^C
> > ( PC: 03ffe) ( R4: 00482) ( R8: 04ab0) (R12: 00004)
> > ( SP: 03388) ( R5: 04ab0) ( R9: 022a6) (R13: 0000c)
> > ( SR: 00009) ( R6: 00000) (R10: 02308) (R14: 0412e)
> > ( R3: 00000) ( R7: 0431f) (R11: 0418b) (R15: 04ab0)
> > __wdt_clear_value+0x14cc:
> > 03ffe: ff 3f JMP __wdt_clear_value+0x14cc
> > 04000: ff 3f JMP __wdt_clear_value+0x14ce
> > 04002: ff 3f JMP __wdt_clear_value+0x14d0
> > 04004: ff 3f JMP __wdt_clear_value+0x14d2
> > 04006: ff 3f JMP __wdt_clear_value+0x14d4
> > 04008: ff 3f JMP __wdt_clear_value+0x14d6
> > 0400a: ff 3f JMP __wdt_clear_value+0x14d8
> > 0400c: ff 3f JMP __wdt_clear_value+0x14da
> > (mspdebug)
> >
> > Any ideas what's going on?
> >
> > Thanks!
> >
> > -Mohammad
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
