HTTP(s) web server using Zephyr in FRDM-MCXN947 board

[elby]

Hi, I am relatively new to embedded development and NXP FRDM MCXN947 board. I followed HTTP Server example to setup a http server within the board. However I am now having issues with "TX packet too large".

How I fix this?

What I wanted to achieve is a decent HTTP  server without any issues and then jump on to https server.

[ekwus]

Hey

I've raised the following issue in the Zephyr Github project.

https://github.com/zephyrproject-rtos/zephyr/issues/92652

Hopefully with enough interest the NXP guys will pick it up.

Cheers

[ekwus]

Hey

I've managed to recreate the same/similar issue in the TCP Echo demo app. I consistently get "No new RX buf available" after a few hundred send payloads when the data size is above 131 bytes!

Below 132 bytes and I haven't managed to get things to break yet but as soon as I increase the buffer it breaks.

Cheers

[Hoog-V]

That was also the case with my code, atleast when adding more services or sending larger frames the whole stack seems to crash. With messages "No new RX buf available" spamming my console.

[Hoog-V]

Ran into the same issue, but managed to fix it by increasing CONFIG_ETH_NXP_ENET_QOS_TX_BUFFER_DESCRIPTORS and CONFIG_ETH_NXP_ENET_QOS_RX_BUFFER_DESCRIPTORS to a value higher than 5. The default is 4 hence why it fails by default. As the HTTP server seems to require at least 5 buffer descriptors in the driver.

My educated guess (though I haven’t looked too deeply into the internals) is that these descriptors act like storage pools or slots for the Ethernet MAC driver to queue complete Ethernet frames or fragments. When the number of available descriptors is too low, the driver is unable to buffer or transmit frames correctly, leading to errors like TX packet too large.

These options can be set by either:

A) Using menuconfig:
Go to Device Drivers → Ethernet drivers → NXP ENET QOS Ethernet Module Driver
Then change:

• Number of TX buffer descriptors

• Number of RX buffer descriptors
  to a value higher than 5 (I used 16).

B) Or, by adding the following lines to your prj.conf:

CONFIG_ETH_NXP_ENET_QOS_TX_BUFFER_DESCRIPTORS=16
CONFIG_ETH_NXP_ENET_QOS_RX_BUFFER_DESCRIPTORS=16

After that, the web server should run fine.

Hope this helps anyone else searching for answers on why the sample doesn’t work out of the box.

[ekwus]

Hey

looks like the default value for the 

CONFIG_ETH_NXP_ENET_QOS_TX_BUFFER_DESCRIPTORS
CONFIG_ETH_NXP_ENET_QOS_RX_BUFFER_DESCRIPTORS

in the latest 4.2.0-rc1 tag version is now 16 so this hasn't fixed it for me.

[Hoog-V]

Nice! NXP has fixed something atleast, three weeks ago this commit got merged which fixed the RX/TX Buffer descriptors issue:
https://github.com/zephyrproject-rtos/zephyr/commit/34f9cd94904518c507a5bc28d483f3f7695db0dc

It doesn't fix the DMA issues though, this forum ticket was actually a double-issue with the QOS driver. I hope they will fix this DMA issue soon!

[elby]

Hi, Thanks for your response. Yes, I did the same and I managed to get it work however I still have the same issue where sometimes (not every time) I get the network buffer error. 

The error says ""Tx packet too large" or "Rx packet too large".

If this anything to do with Zephyr libraries/dependencies or MCXN947 board itself? I don't think it's an MCXN94& board issue. 

Thanks in Advance!

[Hoog-V]

Hi Elby,

I ran into the same issue while working with MQTT/Webserver on the MCXN947. It appears to be a bug in the Ethernet driver that has been upstreamed into the Zephyr project.

Unfortunately, this is just a hobby project for me (I'm not affiliated with NXP), so I haven’t had the time to dive into the driver code yet. As a quick workaround, I noticed that Zephyr currently has two Ethernet drivers for the MCXN947, and oddly enough, the newer one in the main branch seems more buggy than the older one. You might want to try checking out Zephyr version 4.1. As the older driver seemed more stable in my limited experience.

I had to put the project on hold for now due to other commitments. My suggestion would be to open a GitHub issue in the Zephyr project.  I’ll gladly support it to help give it more visibility. Alternatively, if you're up for it, you could attempt a fix and submit a pull request.

Interestingly, the original MCUXpresso drivers don’t have this issue, which suggests that something is indeed broken in the Zephyr implementation. It’s a bit disappointing that driver quality and testing are lacking in this case.

Let me know if you take any action on GitHub! I’m happy to support you, since I’d love to see this resolved too!

[elby]

Thanks for your response much appreciated.

While working did you come across any error like:

<err> eth_nxp_enet_qos_mac: RX descriptor does not have first descriptor flag, drop
<err> eth_nxp_enet_qos_mac: could not allocate new RX pkt
<err> eth_nxp_enet_qos_mac: could not allocate new RX pkt
<err> eth_nxp_enet_qos_mac: could not allocate new RX pkt
<err> eth_nxp_enet_qos_mac: could not allocate new RX pkt
<err> eth_nxp_enet_qos_mac: could not allocate new RX pkt

Recently, I am seeing this error as well.

And Yes, as you said I will open a topic in Github and see if I could get some support from the Zephyr community itself.

I will keep you posted.

Many Thanks!

[Hoog-V]

There seems to be an earlier pr which tried to fix it. But did not fix it :). How wonderful...

https://github.com/zephyrproject-rtos/zephyr/pull/91312

Seems to be related to issue: https://github.com/zephyrproject-rtos/zephyr/pull/90181

and

https://github.com/zephyrproject-rtos/zephyr/issues/89435