Folks,
On the current version of the imxrt SDK (2.4.2) in ethernetif.c around lines 1133 or so (in ethernetif0_init) I think the transit buffers need to be declared in non-cached memory as follows;
From;
SDK_ALIGN(static rx_buffer_t rxDataBuff_0[ENET_RXBD_NUM], FSL_ENET_BUFF_ALIGNMENT); SDK_ALIGN(static tx_buffer_t txDataBuff_0[ENET_TXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);
To;
AT_NONCACHEABLE_SECTION_ALIGN(static rx_buffer_t rxDataBuff_0[ENET_RXBD_NUM], FSL_ENET_BUFF_ALIGNMENT); AT_NONCACHEABLE_SECTION_ALIGN(static tx_buffer_t txDataBuff_0[ENET_TXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);
...at least for me this reduces my flood ping losses from 70% to 0% ...please let me know if I've misunderstood something.
Regards
DAVE
Simply doing this does not seem to be enough for lwip to work properly:
AT_NONCACHEABLE_SECTION_ALIGN(static rx_buffer_t rxDataBuff_0[ENET_RXBD_NUM], FSL_ENET_BUFF_ALIGNMENT); AT_NONCACHEABLE_SECTION_ALIGN(static tx_buffer_t txDataBuff_0[ENET_TXBD_NUM], FSL_ENET_BUFF_ALIGNMENT); I am trying to run lwip_mqtt_freertos demo from NXP, which I modified to put the heap on the SDRAM (instead of SRAM_DTC). Even with the suggested solution above(move the ethernet tx/rx buffers to non-cacheable SDRAM area), the code still gets memory for the buffers from cacheable SDRAM area. I am still trying to figure out what other configurations/code must be corrected. Any help will be appreciated.
I wonder if these bits are set that the transactions will be cachable (not needing uncached memory)
IOMUXC_GPR_GPR13 CACHE_USB, CACHE_ENET, AWCACHE_USDHC etc
It seems the reset default is with the Cacheable Attribute OFF
Tom
I am now seeing similar issues with the SD card driver, which I have been able to resolve in a similar manner by using non-cacheable memory...but it confuses me why you guys haven't seen these issues? Are your samples only running from close coupled memories that don't have caches (I can/will go look, but I really need to get some sleep after fighting this all day)?
Regards
DAVE
I am running into the same thing with sdmmc. Do you remember what fixes you had to make?
I think the samples are all using DTCM (non-cached), so the problem doesn't present itself with the samples.
Hi Jack,
It's a long time ago, I'd like to think the drivers have been updated since then!
However, I have taken a quick look, and I see AT_NONCACHEABLE_SECTION_ALIGN definitions added in the following places;
fsl_sdmmc_host.c:112: AT_NONCACHEABLE_SECTION_ALIGN(uint32_t g_usdhcAdma2Table[USDHC_ADMA_TABLE_WORDS], USDHC_ADMA2_ADDR_ALIGN);
fsl_usdhc.c:59: AT_NONCACHEABLE_SECTION_ALIGN(uint32_t s_usdhcBootDummy, USDHC_ADMA2_ADDRESS_ALIGN);
Hope this lot is some use. Personally, I'm playing with NuttX at the moment which gives me a whole OS and driver stack where these kinds of issues are dealt with inside the OS.
Good luck!
DAVE
Hi Dave,
Yes it reduces a lot, but is non-cache, I will mention to developer to make both functions and the costumer choose.
Regards
Hi,
I'm sorry, but I'm afraid I don't understand your reply ... are you saying that this is indeed a bug, or that there is some other configuration possibility that I haven't considered?
Regards
DAVE