NetXDuo samples break when Global Data Placement is set to SDRAM

[max3]

Steps to reproduce:

Import the netx_duo_iperf sample project into your workspace.

Go to project settings -> C/C++ Build -> Settings -> MCU Linker -> Managed Linker Script

Set Global Data Placement to BOARD_SDRAM

Go to project settings -> C/C++ Build -> Settings -> MCU C Compiler -> Preprocessor

Ensure the preprocessor has the following items. If any are missing add them. 

XIP_BOOT_HEADER_ENABLE=1
SKIP_SYSCLK_INIT=1
XIP_BOOT_HEADER_DCD_ENABLE=1

DHCP can be disabled and a static IP assigned if desired.

You will note that when navigating the the URL: http://STATIC_OR_DYNAMIC_IP the page loads extremely slowly, and often fails to load. Checking wireshark its clear that many packets get dropped on transmission.

If the project is instead set to place global data in SRAM_OC, everything works fine again.

This is confusing to me, as non-cache regions are still used correctly and the packet pool (netx_duo_iperf.c) and enet descriptors (within nx_driver_imxrt) are being placed in those regions using the linker macros.

Even more confusing, disabling D/I Cache entirely (using SCB_DisableD/ICache()) say after BOARD_InitDebugConsole() within next_duo_iperf.c still has the same behaviour of slow loading and dropped packets when global data is set to BOARD_SDRAM.

Any ideas?

[Kan_Li]

Hi @max3 ,

I have followed your steps to reproduce this issue, but the web page was loaded extremely fast, the host on my side is a Win10 64bit system, was it the same from your side? Please kindly refer to the following for details.

Have a great day,
Kan

-------------------------------------------------------------------------------
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.
-------------------------------------------------------------------------------

[max3]

Sorry for not updating this post, but I did determine it is a hardware issue of some sort with our custom design.

Strangely, the resolution was reducing the SDRAM drive strength and reducing the ENET drive strength.