Bad UDP behavior after migrating fsl_enet from 2.2.4 to 2.2.5 version

[embeddeddavid]

Good morning,

We have a UDP/IP stack code that has started to misbehave on a K64 after migrating fsl_enet driver from 2.2.4 to 2.2.5 version. This is the result of updating SDK from version 2.6 to 2.7. We have observed that our device keeps repeating UDP messages in response to a single UDP request. Has anybody experienced something similar? I have surfed the NXP website but I haven't found any document or patch concerning this issue.

Thanks in advance.

Regards,

[embeddeddavid]

Hi kerryzhou‌,

The attached file is the modified version from SDK2.7. Those are the minimum amount of changes required for our application to behave ok. In theory, the code function should be the same; in practice, the code behaves different. I have already discarded whether it is a compiler optimization level issue.

Regards,

[kerryzhou]

Hi embeddeddavid,

   That's really strange, what's the IDE you are using now? Any optimizaton, debug mode or the release mode?

   This is really difficult to find the root issue, how do you find this modified points to make it work? Porting from SDK2.6.0?

  Really thanks so much for your effort.

Best Regards,

Kerry

[embeddeddavid]

Hi kerryzhou‌,

I am using MCUXpresso IDE v11.0.1 [Build 2563] [2019-09-01] and ARM Cross GCC Toolchain (optimization level: optimize size (-Os), release mode).

I got to the attached file by comparing fsl_enet.c files from SDKs 2.6 and 2.7, modifying little by little the one corresponding to SDK 2.7 and giving it a try on our HW.

Regards,

[kerryzhou]

Hi embeddeddavid

  Do you try the debug mode, still have any issues with these two files? Because from the code function side, I really didn't find any difference, totally the same, just different write method.

Best Regards,

Kerry

[embeddeddavid]

Hi kerryzhou‌,

I have updated to SDK 2.8 and I think I have found the cause of this headache. I suspect SDK 2.7 should work allright, although I have not tested it. I had been trying to optimize the ENET DMA by setting a larger amount of buffers of a smaller size. This seems ok for the Rx buffers, but somehow not for the Tx buffers.

On the image below you can see a snippet of enet_ethernetif.h under lwip/port folder. The right side shows my previous code, whereas the left side illustrates my current code. Do you have any idea why having 24 Tx buffers of 64 bytes is not valid, whereas 1 Tx buffers of 1518 bytes seems allright?

Best Regards,

[kerryzhou]

Hi embeddeddavid

   Thanks for the information sharing.

   You mean, the right side your previous code is working, but the left side your current code is not working, right?

Best Regards,

Kerry

[embeddeddavid]

Hi kerryzhou‌,

Just the other way around: the left-side code is currently working. Do you have any clue why?

Best Regards,

[kerryzhou]

Hi embeddeddavid,  

  I will check more details about the reason internally, please give me more time, thanks.

Best Regards,

Kerry

[embeddeddavid]

Hi @kerryzhou ,

I wonder whether this topic is still active or not. Dou you have any new information? Please let me know.

Best Regards,

[kerryzhou]

Hi embeddeddavid,

    So sorry for my later reply.

    I checked the SDK2.8.0, the ENET_TXBD_NUM is 3.

Do you use the SDK2.8.0 driver directly? Whether it works with the ENET_TXBD_NUM=3, and the ENET_TXBUFF_SIZE as 1518?

Or you still need ENET_TXBD_NUM to 24, I think maybe this number has the limit, but the ENET_TXBUFF_SIZE can large. Do you try any other  ENET_TXBD_NUM data below 24, whether it works or not?

Best Regards,

Kerry

[embeddeddavid]

Hi @kerryzhou ,

Thanks for the support. We are just wondering what is the minimum allowed value for ENET_TXBUFF_SIZE. Is it ENET_RX_MIN_BUFFERSIZE as well?

Best Regards,

[kerryzhou]

Hi  embeddeddavid,

In some of our internal side, I find one of our expert modify the code like the following, define the ENET_TXBUFF_SIZE to 256, and can make it works.

So, make be you can use 256, you can try it.

#ifndef ENET_RXBD_NUM
    #define ENET_RXBD_NUM (8)  //(5)
#endif
#ifndef ENET_TXBD_NUM
#if defined(FSL_FEATURE_SOC_LPC_ENET_COUNT) && (FSL_FEATURE_SOC_LPC_ENET_COUNT > 0)
    #define ENET_TXBD_NUM (5)
a
#else
    #define ENET_TXBD_NUM (8)  //(3)
#endif
#endif

#ifndef ENET_RXBUFF_SIZE
//a
    #define ENET_RXBUFF_SIZE 256//(ENET_FRAME_MAX_FRAMELEN)
#endif

//a

#ifndef ENET_TXBUFF_SIZE
    #define ENET_TXBUFF_SIZE 256//(ENET_FRAME_MAX_FRAMELEN)
#endif

In fact, I didn't find the detail TX Min limit content now, you can try 256, whether it works with the above code?

Best Regards,

Kerry

[embeddeddavid]

Hi @kerryzhou ,

It's been a while since the last time we talked. Do you hace any news concerning the minimum supported value of ENET_TXBUFF_SIZE  definition?

Thanks in advance.

Best Regards,

[embeddeddavid]

Hi @kerryzhou ,

Your suggested code does not work. It seems that 256 is not an appropiate value.

Regards,

[embeddeddavid]

Hi @kerryzhou ,

It's been a while since we talked. Any news concerning this issue?

Best Regards,

[kerryzhou]

Hi embeddeddavid

   Do you test the SDK2.7.0 lwip udp project directly, without the driver migrating , just test the SDK2.7.0 project directly, any issues?

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[embeddeddavid]

Hi kerryzhou,

The UDP Echo example seems to work allright on a FRDMK64F.

Regards,

[kerryzhou]

Hi embeddeddavid ,

   Thanks for your updated information.

   So, do you mind use the newest SDK2.7.0 platform and drivers directly? Maybe your issue is caused by the driver updating. It's better to use the newest SDK drivers and related files directly.

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[embeddeddavid]

Hi kerryzhou‌,

We are already using SDK 2.7.0 and lwIP 2.1.2.0 (associated middleware). This is causing the bad UDP communication.

Regards,

[kerryzhou]

Hi embeddeddavid

  Do you have any testing result for the bad UDP communication with the newest SDK2.7.0.

  And please share me the detail steps to reproduce your issues, when I have time, I will help you to check it.

Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------