LPC4357 MAC RX engine hangs & cannot be recovered

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC4357 MAC RX engine hangs & cannot be recovered

470 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by peterrq on Wed Sep 17 09:50:43 MST 2014
I have come across a possible silicon issue.
When using the LCP 4357 PTP function.
I enable PTP with: MAC_TIMESTAMP_CTRL set to TSENA, TSCFUPDT and TSIPV4ENA (0x2003)
If I then allow the MAC unit to run out of DMA descriptors, for example connected to a network with broadcast chatter and then sleep for 1 second before the host polls LwIP & copies data and release the descriptor) then the RX engine will permanently stop receiving data.
RU is set as expected but even after releasing the DMA descriptor (OWN) and commanding DMA_REC_POLL_DEMAND reception will not restart.
I note that in this mode the MAC_DEBUG register reads 0x340.
Previously I have only ever seen the MAC_DEBUG as 0x0.
If I remove TSIPV4ENA from the initialisation code (0x03) then RX will not stall.
[s]I have yet to determine if I can live without TSIPV4ENA.[/s]
EDIT: I need IPV4 & issue also present in other modes

With TSIPV4ENA enabled the PTPd library reports that I get a good lock to the master clock although I have not yet confirmed that clocks are synchronised.
It looks therefore like the PTP functions work except when you run out of DMA descriptors.

Please recommend a work around.

As a secondary question: is there a way of generating an external event based on the PTP clock? I note that I can cause an interrupt using the TARGET TIME registers but was hoping that I could get the hardware to generate a pulse.
Labels (1)
0 Kudos
3 Replies

388 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by Arjan Kamphuis on Tue Nov 18 08:31:42 MST 2014
Had the same problem with setting PTP flags and stalling of the Ethernet receiver.

The DMA_OP_MODE.DFF solved the problem over here as well.

Although I have no idea what's their relation.

Many Thanks!

Regards


0 Kudos

388 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by peterrq on Mon Sep 22 01:16:51 MST 2014
Thanks.
DMA_OP_MODE.DFF seems to resolve.
I agree with the approach; try anything that sounds vaguely like the problem! Had missed that register though.

Thanks again.

PS I was getting the issue typically when halted in the debugger which is a major pain. I also could not take the chance that it would not happen in real life however unlikely.
0 Kudos

388 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by pierre on Sat Sep 20 07:33:05 MST 2014
Hello,

I have used MAC_TS_TSENA and MAC_TS_TSENAL but not your other flags. Maybe it is those flags that cause the problems.

I have now switched the project to be entirely USB, so I have dropped Ethernet, so don't ask me to compile some stuff and/or do some tests.

However, I may have a solution for you :

My code communicates with the Ethernet driver using two FIFOs. Those FIFOs contain packet descriptors (not DMA descriptors). Whatever code is at the other end of the FIFO doesn't know about the internal workings of the MAC, it sends a Packet* in a FIFO and that's it. You can use queues from the OS, whatever.

The RX interrupt allocates buffers from a pool, takes DMA descriptors from a ring, and keeps the DMA descriptor queue full at all times, waiting for packets.

When the RX DMA receives a completed packet, it tries to push it in the FIFO so the application can read it later. However, if the FIFO is full, because the application is too busy to read from it, it drops the packet and recycles the buffer and DMA descriptors.

It is impossible to run out of descriptors this way. It is possible to run out of buffers, if the FIFO is too large. Therefore the FIFO must be small, and the number of available buffers large enough to fill the FIFO, RX/TX rings, plus all the buffers which may be hogged somewhere in the application code.

The performance of this chip is so high it's ridiculous. Even with a quad core linux PC sending 1 byte packets at full wire speed, there were no drops.

Note, I have set this bit :

DMA_OP_MODE

Disable flushing of received frames
When this bit is set, the RxDMA does not flush any frames due to the unavailability of
receive descriptors/buffers as it does normally when this bit is reset. (See).

Check it... who knows...
0 Kudos