MSP432E401Y: Ping/ICMP works but HTTP server does not accept connections

Hi,

I have forwarded your question to the team.

Regards,

Thank you very much, FI! Upon more detailed debugging, I narrowed down the problem to the fdSelect() function in fileuser.c. The code seems to be crashing there upon FIRST attempt to poll sockets or file descriptors. It happens even before I attempt to connect to the HTTP Server. It should just see no activity on sockets and return but instead it crashes.

I a really out of ways to debug this at kernel level and I would appreciate any help on this!

Hi,

Looking at the information you have provided, it seems like this would be a hardware and not a software issue. You mentioned that your code runs fine on the MSP432E4 launchpad, but not on your custom board. How have you ruled out a hardware issue as the root cause of the errors you are seeing?

Regards,

Michael

Hi Michael,

Thank you very much for getting back to me!

What kind of hardware issue could this be? If I build and run the "TCP echo" example, everything works fine. I understand that tcpecho accepts a connection and spins up a new thread with the new socket to hadle the communications. On the other hand, HTTP Sever uses select() to poll multiple descriptors/sockets an it dies there. I guess my question is "what in fdSelect() call could possibly kill the process"? I looks very much like the kernel is throwing an out-of-memory or SEGFAULT-like event that put the whole board into an "Idle" loop.

I am not familiar enough with the low-level stuff on TI-RTOS and means to debug it. If you could give me some hints what to look for or how to test certain things, it would be very helpful. I want to avoid re-writing the communications module using threaded TCP connections like in the tcpecho example...

Hi,

There isn't any specific hardware issue that is apparent in your case. It is good to keep in mind though that the launchpad EVMs are the reference platforms, and if your code works on the LP but not on your custom board then there is most likely something about your custom board or hardware-dependent setup that is causing this failure state.

For RTOS debug, TIRTOS has the RTOS object viewer tool that you can use to check the running state of the RTOS as your fault event occurs. You can look at my post here to see how to launch it: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/733294/2707429#2707429

From there, I advise you check the thread stacks to ensure there is no stack overflow, the heap to ensure that you're not running out of heapmem, and also the hwi->exception tab to see what precisely caused the hard fault. If you check the exception data reported in ROV, what do you see?

Regards,

Michael

Hi Michael,

Thank you for the quick response. The only difference in our hardware is the absence of 32.768-kHz crystal for RTC because we weren’t considering MCU hibernation. Does it have to be for a proper RTOS functionality?

And thank you for the hints on the deeper debugging! I will give it a try and share what I find.

Hello again,

Here is an interesting update.

We swapped the MSP432E401Y from the Evaluation Board to the custom board. With the chip from Evaluation Board, the custom board works fine but the Evaluation Board with the chip transplanted from the custom board does not! It fails exactly the same. This seems to be a problem with the chip itself.

Before I get deep with interrupt debugging, I'd like to ask a couple of questions:

1. Do all chips of this model have identical configuration stored in flash?
2. Do they have anything in ROM that could cause differences in behavior?

I'm thinking if different production batches of the same part number have some variation in stored configuration or ROM content.

We bought the Evaluation Board over six month ago. The chips for the custom boards were purchased recently.

We tested another custom board with a "recent" chip and it locks up on the HTTP Server example the same way.

Hi Michael,

I'm not sure if you saw my last message about swapping of the chips between boards. I replied to my own post and it might have not sent you a notification...

I would appreciate any advise or any contacts that I could discuss this problem with.

Here is the message for the ease of reference:

We swapped the MSP432E401Y from the Evaluation Board to the custom board. With the chip from Evaluation Board, the custom board works fine but the Evaluation Board with the chip transplanted from the custom board does not! It fails exactly the same. This seems to be a problem with the chip itself.

Before I get deep with interrupt debugging, I'd like to ask a couple of questions:

1. 1. Do all chips of this model have identical configuration stored in flash?
   2. Do they have anything in ROM that could cause differences in behavior?

I'm thinking if different production batches of the same part number have some variation in stored configuration or ROM content.

We bought the Evaluation Board over six month ago. The chips for the custom boards were purchased recently.

We tested another custom board with a "recent" chip and it locks up on the HTTP Server example the same way.

Hello Sai and Michael,

I found a solution to this problem. It was a two-fold.

First, there was a legacy problem in the project. I started developing it a while ago using CCS v8. There was no SysConfig in CCS at the time and I configured all networking stuff using hand-written code.

Second, the TCP layer does not seem to start when the MAC address has one FF byte. It only affects select() based polling of sockets. If a thread is sitting in blocking listen() call, it works fine. With select()-based approach, the TCP stack is completely "stuck", it does not even reject connection attempts to ports where nothing is listening.

Thanks again for your help!