• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 79 subscribers
  • Views 318 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR2355: debugger stops but still shows connection, code still running?

Steve Wenner
Genius 3240 points
Part Number: MSP430FR2355

I am using CCS 10.0.0.00010 and Windows 10.  I have an application running on a client that is serving three hosts over an RF link.  I download the application via the debugger and can stop and probe as needed.  After I connect up the hosts (via a join process) the client is sending and receiving data quite rapidly.  It is sometime after this that I notice I can't seem to place a breakpoint to catch anomalies.  I can still hit buttons on the client and it reacts so I know the firmware hasn't gone off in limbo.  If I stop the debugger it stops right after my LPM3; line ....It appears I can see variables although I am not sure how current / accurate they are given the debugger won't break where I set breakpoints.  Can anyone comment on this?  It seems the internal JTAG is fighting to keep up with the ISRs going off and just doesn't work anymore.....Thoughts?

Thanks

  • 0
    Guru 95705 points

    The other day you were working with the WDT. Is it possible that triggered? The debugger sometimes has trouble with an unexpected reset.

    Try setting a breakpoint at the second line of main().

  • 0 in reply to Bruce McKenney
    Genius 3240 points

    Well I don't think so because I disabled that IRQ for testing (this IRQ was put into code so I could handle lock-ups at the client side gracefully).....  It appears that the radio ID in MSP memory is getting corrupted and then written to the radio....Hence the client radio ID is different than the hosts ....ie. all comms stop.

    There are two places I write this ID .....one during boot (which your idea will catch) and the second time is in main....I put a break point at both.  Time will tell...I've found it takes up to 7 hours to fail....The incoming messages the client has to support are many and varied so trying to think that comms won't get corrupt messages every now and again is naive especially as I add to the network....The best I can do is handle the bad messages smoothly.

  • 0 in reply to Steve Wenner
    TI__Mastermind 28516 points

    Hi Steve,

    I think maybe you can try to add the below code where you want to set a breakpoint:

        __no_operation();                       // For debugger

    Thanks!

    Best Regards

    Johnson

  • 0 in reply to Johnson He
    Genius 3240 points

    I believe the debugger stops working here.....I ran system all night with debugger connected.  In the morning the logic analyzer was still capturing data but the client was not communicating (debugger is connected to the client), although I could still see some (erroneous) activity on the UART of the client via the logic analyzer.  I pushed a button on the client and tried to break within the port ISR but to no avail.  I then pushed the button a few more times taking logic analyzer snapshots and the client began to re-communicate with the hosts.  The logic analyzer supported this as well.  The debugger was running as indicated by the green play button greyed out and the pause button active.  I tried to set a breakpoint again within the code at a CRC message check (which happens anytime a mssg comes in) but to no avail...The debugger didn't stop.  I hit pause and I can see the debugger pause AND the code seems to stop....Hit play again and I get a complete configuration of the radio which ONLY occurs at the beginning of main before LPM3.  I set a breakpoint here but it never breaks and the logic analyzer clearly shows a re-configuration of the radio....

    I believe the debugger stops communicating with the MSP JTAG?  comments??

  • 0 in reply to Steve Wenner
    TI__Mastermind 28516 points

    Hi Steve,

    Please check if this EEM bug will cause this issue. (FR2355 ERRATA)

    Thanks!

    Best Regards

    Johnson

**Attention** This is a public forum