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.

MSP432E401Y: Ethernet breaks down every 15 seconds

Part Number: MSP432E401Y


Hello forum,

we have a PCB with a MSP432E401Y on it. We use CCS 10.0.0.00010 and simplelink_msp432e4_sdk_4_10_00_13. There should be a communication via ethernet. The PCB is connected via a switch to a PC.

After starting the program the connection is established after a while. But it breaks away, round about every 15 seconds. But the communication continous after a few seconds. The Led of the switch is blinking. When I pause the debugger then the connection does not break.

The hardware between the MSP and the RJ45 Adapter is similar to the MSPP432E401Y launchpad. And we have two other revisions of the pcb, where it worked. I havn't found any differences yet.

My idea is to debug the software. Something should cause the ethernet periphic to pause or restart the connection. It is not a restart of the MSP, because there is no stop at the breakpoint at the initialisation.

What could cause the lost of the connection?

How can I set a breakpoint at an interrupt?

There is an interrupt vector in the file startup_msp432E401y.c, but this file is grayed out, so I assume this file is not in use.

Or, how can I find out which interrupt was handled? The RTOS Object View shows me five different Adresses of interrupts, but the I can't see from the Disassembly which interrupts are handled there.

In the xPSR register is the ISRNUM field. CCS does not show the ISRNUM field, but it shows an EXCEOPTION field. Compared with slau723a.pdf, the location of the bits is the same.

But how can I stop the debugger at an interrupt? In can set breakpoints inside the file Hwi_asm.sv7M, but I'm not sure if the debugger will stop at them. With .asmfunc and .endasmfunc the part of the assembly code should be interpreted by the Debugger as C-code, but I'm not sure, if it works.

Thanks for helping.

BR Guenther

  • The MSP432E sends a http page with a timestamp to the PC. The timestamp is updated via the Simplelink function Clock_getTicks() which can be found at
    simplelink/source/ti/posix/tirtos/clock.c

    After the connection breaks down, the timer does not continue from the old value, it starts again from the beginning.

  • It sounds a bit like something is resetting the micro every 15 seconds, so the whole program is starting again. Could you have enabled a watchdog or is there an assert handler doing a reset?

  • After adding a Watchdog_clear() in the function that is executed every second it works.

    But what happens if the Watchdog timer reaches zero? I thought that the progam would starts from its beginning and would stop at the breakpoint at the initialisation. But it has'nt. So I haven't thougt that the watchdog timer is the problem.

    Thanks and best regards

    Guenther

  • Yes, that's odd. I also would have expected it to stop at the start of main(), after every reset. Perhaps there is something different about that automatic breakpoint. Out of interest, if you set a manual hardware breakpoint somewhere in main(), before starting the bios, does that then catch every reset?

    You should be able to see the last reset cause by checking the Registers - SYSCTL - [0...99] - SYSCTL_RESC.

  • I removed the Watchdog_clear and set a breakpoint at the function Board_initGeneral (have a look at the httpserver example), that is before BIOS_start(). The watchdog timer should cause restarts now.

    But this is a SW breakpoint, I'm not sure how to set a hardware breakpoint. Regarding to the help I had to add
    GEL_HWBreakPtAdd( “main” );
    But where I should place this peace of code without getting a compile error?

    I also added a SW breakpoint at _c_int00(), where each program should start before it enters the main function. After a soft reset (Control Shift R) the debugger stops there, the related position belongs to boot.asm. But after a watchdog reset the Debugger doesn't stop there...

  • Yes, it looks like a watchdog reset disconnects the debugger. You can reconnect by right clicking on the probe in the Debug window (I seemed to have to do this twice!). You can then see the Watchdog flag set as the reset cause in the SYSCTL_RESC, but it doesn't seem very helpful.

    You should be able to set hardware breakpoints by right clicking on a line of code once you are debugging. The context menu contains Breakpoints> which then gives some more options.