Reply by old_cow_yellow●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
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
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
>
>
>
>
>
Reply by "Redd, Emmett R"●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
>
>
>
Reply by Mohammad Afaneh●December 11, 20122012-12-11
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: