UART changes Ethernet behaviour

cancel
Showing results for 
Search instead for 
Did you mean: 

UART changes Ethernet behaviour

Jump to solution
410 Views
giusloq
Contributor III

I have a project that runs on a custom LPC1768 board. The project uses Ethernet (with lwip in NO_SYS=1 mode) and UART for debug.

It works well many times. However I noticed a strange relation between UART and Ethernet.

Normally I can communicate with a server (MQTT over TLS). I can see frames/packets out and in and the communication is ok.

When I add some debug output in LPC Ethernet driver (for example in low_level_output() in lpc17xx_40xx_emac.c), Ethernet works differently. It seems some incoming frames that are normally received, aren't received now.

I know it's a very big question, however what could be the relation between UART and Ethernet?

Tags (2)
0 Kudos
1 Solution
354 Views
giusloq
Contributor III

I found the problem. It's in LWIP_DEBUGF macro in lpc_low_level_output(). In my application, when a pbuf chain is passed to the function, the while loop prepare the descriptor of each fragment and increment the TxProduceIndex. When LWIP_DEBUGF is enabled and takes some time to finish (as in my case), it is possible that the first fragment is transmitted before the second descriptor is configured

Because the first fragment is configured without ENET_TCTRL_LAST flag, I think the DMA starts transmitting a second corrupted fragment.

I solved increasing TxProduceIndex after the while loop, so the descriptor are all correctly configured.

View solution in original post

0 Kudos
1 Reply
355 Views
giusloq
Contributor III

I found the problem. It's in LWIP_DEBUGF macro in lpc_low_level_output(). In my application, when a pbuf chain is passed to the function, the while loop prepare the descriptor of each fragment and increment the TxProduceIndex. When LWIP_DEBUGF is enabled and takes some time to finish (as in my case), it is possible that the first fragment is transmitted before the second descriptor is configured

Because the first fragment is configured without ENET_TCTRL_LAST flag, I think the DMA starts transmitting a second corrupted fragment.

I solved increasing TxProduceIndex after the while loop, so the descriptor are all correctly configured.

0 Kudos