Calling ENET_QOS_SetPtp1588 breaks the whole ENET_QOS subsystem

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

Calling ENET_QOS_SetPtp1588 breaks the whole ENET_QOS subsystem

1,750 Views
erling
Contributor III

I am using iMXRT1170 EVK this has been tested on both MCUXpresso 11.4.1+SDK2.10.1 and MCUXpresso 11.5.0+SDK 2.11.0. I am using Ubuntu 18.04 with following info

erling@ubuntu-ntnu ~> uname -a
Linux ubuntu-ntnu 5.4.0-99-generic #112~18.04.1-Ubuntu SMP Thu Feb 3 14:09:57 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux


I am using the example: "lwip_udpecho_enet_qos_freertos_cm7" my EVK is connected through a switch to my host computer which sends UDP packages to it. I have confirmed that the "echo" works.

If I pause the software, quite often this will result in that the whole ENET_QOS subsystem will break. I observe it by not receiving any more packages. It does not seem to matter where I pause the software. After it is resumed, the application break. It happens in different ways. I have observed:

1. No further frames are received. If I but a breakpoint inside ENET_QOS_ReadFrame nothing happens. In other word, packets don't make it through the ENET_QOS subsystem. By inspecting different registers in ENET_QOS it is not clear to me what has happened.

2. "Buffer returned by ENET_GetRxFrame() doesn't match any RX buffer descriptor"
Assertion in enet_ethernetif_qos.c:567 in lwip/port fails. This has so far only been observed in SDK2.11

3. "p->tot_len != rxFrame->totLen"
Assertion in enet_ethernetif_qos.c:587 in lwip/port fails. This is only observed in SDK2.10.1

If I comment out line 425 of enet_ethernetif_qos.c such that the enet_qos_config_t struct has a value 0x00 for the field ptpConfig. This will stop the ENET_QOS_Init from calling ENET_QOS_SetPtp1588. This will fix the problem described above. Now I can pause the debugger anywhere without breaking the ENET_QOS subsystem. This is very wierd.

There are additional transient bugs that have occurred after running our application minutes or hours related to the ENET_QOS subsystem that I think can be related. These occurred without pausing the software but less predictably.

1. Multicast packages are note received anymore. Causing our PTP client to stop working. I could observe IGMP packages being sent updating multicast group membership. And also see the multicast messages being sent by PTP grand master. But nothing received at NXP side.

2. ARP responses not received. Causing UDP transmits to be dropped (since no ARP entries found). I could observe ARP requests and responses, but ENET_QOS subsystem did not properly receive ARP response.

I have not been able to test whether this errors disappear because I need the PTP functions of ENET_QOS to run these applications. It appears to be specific to ENET_QOS as these errors are not occurring with the "lwip_udpecho_freertos_cm7" example.

0 Kudos
Reply
5 Replies

1,624 Views
erling
Contributor III

Hi. Any updates on this? I would be more than happy to support you in reproducing this error.

0 Kudos
Reply

1,670 Views
erling
Contributor III

I have now tested this on 2 NXP iMXRT1170 EVK so a fault on my EVK is ruled out. Both has the same behaviour:

1. With ENE_QOS_SetPtp1588 the app crashes when receing new data over ethernet after pausing the debugger anywhere.
2. Without ENE_QOS_SetPtp1588 I can pause the debugger without breaking the ENET subsystem.

Shoud be very easy to reproduce just follow my instructions. I am open for a zoom meeting where I walk you through it also if you need help.

 

0 Kudos
Reply

1,701 Views
erling
Contributor III

Any updates on this?

0 Kudos
Reply

1,693 Views
danielchen
NXP TechSupport
NXP TechSupport

Hi erling:

 

I would suggest you check if data cache is disabled. (SCB_DisableDCache function).

If not, please disable it right after hardware initialization code and rerun the tests.

 

Regards

Daniel

0 Kudos
Reply

1,688 Views
erling
Contributor III

Hi Daniel and thanks for your reply.

I tried disabling the data cache using "SCB_DisableDCache()", after the hardware initialization in main. This had no effect.

Any other suggestions? I will also see if I can get my hand on another EVK and rule out whether this is a HW bug specific to my EVK.

Thanks,
Erling

0 Kudos
Reply