LAN of LPC4337 can no longer communicate

[XoR]

Hello,

I have been using the original board of LPC4337JET100 for 5 years and it was no problem.
The ADC is connected to SSP0, the DAC is connected to SSP1, and LAN communication is performed with LAN8720A.

This time, I made a new board that does not connect DAC and ADC.

Then, I wrote the same program with LPC-Link, but LAN communication became impossible.

Writing with LPC-Link seems to be possible.
However, It can no longer return a ping response.

P2_7(C10) remains open.

What's wrong?

Best regards,

[frank_m]

There isn't really much information to work with. Neither about the schematics, nor about the firmware.

> This time, I made a new board that does not connect DAC and ADC.

> Then, I wrote the same program with LPC-Link, but LAN communication became impossible.

A redesign or new design requires you to verify it. Did you check all all connection to the PHY, power consumption and and logic levels ?

Then, take a debugger and check where it goes wrong.

[XoR]

Thank you, frank_meyer.

I checked all connection by logic levels.
But there was no difference or problem.

Are there any other points to note?
Especially for issues related to the cpu specification.

best,

[frank_m]

Nobody except you has the hardware to actually test it.

> However, It can no longer return a ping response.

This is a very superficial description.

Check out all the steps involved to have you board/firmware sending a ping response.

Does the PHY initialisation succeed in the first place ?

Do ethernet transmissions actually arrive at the Rx pin of the MCU, i.e. is the line physically o.k. ?

Does the firmware receive it, and try to send a response ?

[XoR]

Hi,

This board is a very simple board.

The Ethernet physical line is fine.

On the old board, the ping response is fine, and on the new board, when the ping is received, the receiving program breaks.
However, with the new board, there are times when the reception does not break, and although it is a little strange, the cause has not been found.

Do you know the difficult specifications and problems of LPC4337?

Best regards,

[frank_m]

> Do you know the difficult specifications and problems of LPC4337?

No, I don't have any board using this MCU, and never used it before.

> However, with the new board, there are times when the reception does not break, and although it is a little strange, the cause has not been found.

This sounds very much like a software issue. I think you will need to debug your code. I guess it could be related to ethernet package sizes, or transmission errors. 

A first approach would be to tightly control the input data, i.e. ethernet packages. Desktop PC running Windows or Linux transmit dozens of transmissions for a variety of protocols totally unrelated to your board, which can cast your firmware off track.

[XoR]

Thank you so much, frank_meyer.

I will debug a little more.

Best regards,

[frank_m]

I suspect you end up in the hardfault handler.

If that is correct, you could read out the SCB registers, and evaluate the cause. See this document: https://www.keil.com/appnotes/files/apnt209.pdf

Or, you can add instrumentation code for e.g. a UART line, and watch the debug output. 

Observing the network traffic e.g. via wireshark would probably be helpful, too.

Quite often, spurious runtime crashes are caused by stack overflows, which can manifest in different and inconsistent ways. Especially clib functions like of the printf variety or protocol stacks like TCP/IP  often exacerbate this problem.