FreeRTOS+TCP on RT1021 EVK

[salva214]

Hi,

I'm working on an official RT1021 EVK board to experiment with FreeRTOS and Ethernet communication.

As I'm new to both NXP and FreeRTOS, I started with your TCP Echo example provided in the SDK of the EVK, which is based on LwIP. However, I didn't feel comfortable with that library (it usually runs out of memory after some editing, I don't know why), and I wanted to try the FreeRTOS+TCP one.

I soon discovered that your SDK doesn't provide any working examples based on FreeRTOS+TCP, nor a NetworkInterface suitable for that processor. Luckily, while searching the web, I found that a user on the FreeRTOS forum had done something similar by porting a NetworkInterface for the RT1064: https://forums.freertos.org/t/freertos-tcp-ip-port-for-nxp-imx-rt1064/10175/3

However, for some strange reason, the latest version of the SDK (2.15) for the EVK used a different implementation of the "fsl_enet" driver. Moreover, I was unable to fully understand what the IDE automatically edits when I import something (usually, I discover more modules/drivers imported than I need), and the import of FreeRTOS and the TCP library lacks some directories/files compared to the GitHub repos. So, I decided to do it the old-fashioned way, importing the things I needed into the source folder of my project.

So, I have externally imported the following:
- "enet" driver & "phy" component from https://github.com/nxp-mcuxpresso/mcux-sdk/tree/MCUX_2.12.0_UPDATE
- "freertos-plus-tcp" source from https://github.com/FreeRTOS/FreeRTOS/tree/main/FreeRTOS-Plus (with the relevant NetworkInterface for NXP1060)

After making the necessary changes to the interface (mainly the PHY address) and following the official FreeRTOS-plus-TCP docs (https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/TCP_Networking_Tutorial_Initialising_TCP.up...), I successfully built the project and uploaded it to the board. The project starts up, correctly configures the PHY (I checked with an oscilloscope, bit-to-bit, that the data is the same as the LwIP example), configures the Endpoint (MAC, IP, GW, DNS), and starts the "Main Network Task" (in the project, it's the "phyksz8081_thread").

I tried to ping the EVK from my PC (having already set the "ipconfigREPLY_TO_INCOMING_PINGS" flag), but nothing happens, at least in the code (via the oscilloscope, I see that the PHY is sending the data to the MCU).

Digging into the issue, it seems that the required "kENET_RxFrameInterrupt" never fires, and even looking for a "kENET_RxBufferInterrupt" doesn't work. Before going further (I need to implement some UDP tests), I decided to ask for some help, mainly because I've lost myself in this, and also because I read on the web that at least the ICMP response or the ARP packets should come out of the board with my ipconfig settings.

I've attached my project.
Can someone, please, help me find the issue?

Thanks

PS: I used the MCUXpresso IDE v11.9.0_2144 for building this project.

[salva214]

Hi all,

thanks to the guys on the FreeRTOS forum, I did some step further into the issue...

At first I was focusing on the ENET_INT pun, but analyzing again the LwIP demo code I found that it wasn't used at all for detecting new packets incoming.

It seems instead that the phy component/driver (fsl_phyksz8081.c) i was using from the SDK 2.12 was lacking some of the function regarding the interrupts:

#define PHY_INTR_CONTROL_STATUS_REG (0x1BU) /*!< The PHY interrupt control/status register. */
...
status_t PHY_KSZ8081_EnableLinkInterrupt(phy_handle_t *handle, phy_interrupt_type_t type)
status_t PHY_KSZ8081_ClearInterrupt(phy_handle_t *handle)

which were present into the driver used into the LwIP demo.

Infact, upon reanalyzing the MDIO transaction that occurs during the LwIP demo execution, compared to my own, it seems that my code is missing a poll to the aforementioned register (the register address is 0b11011 or 0x1B).

By using the latest version of the SDK for VSCode (mcux-sdk), it presents the missing functions, but a phy_handle structure that is not compatible.
Essentially, the NetworkInterface.c file requires that phy_handle has a structure like this:

/*! @brief PHY device handle. */

struct _phy_handle
{
uint32_t phyAddr; /*!< PHY address. */
mdio_handle_t *mdioHandle; /*!< The MDIO handle used by the phy device, it is specified by device. */
const phy_operations_t *ops; /*!< The device related operations. */
};

instead, I find myself with this:

/*! @brief PHY device handle. */
struct _phy_handle
{
uint8_t phyAddr; /*!< PHY address. */
void *resource; /*!< PHY specific resource supporting operation of PHY hardware. */
const phy_operations_t *ops; /*!< PHY operational method. */
};

After importing such driver, i found that the code fails in NetworkInterface.c at this lines:

// r. 202
static phy_handle_t phyHandle = { .phyAddr = 0x00, .mdioHandle = &mdioHandle, .ops = &EXAMPLE_PHY_OPS };

// r. 852
sysClock = phyHandle.mdioHandle->resource.csrClock_Hz;

which I tried to readapt like this (based on the assumption that the member mdio_handle_t *mdioHandle is changed to void *resource) :

// r. 202
static phy_handle_t phyHandle = { .phyAddr = 0x00, .resource = ( void * )&mdioHandle, .ops = &EXAMPLE_PHY_OPS };

// r. 852
mdio_handle_t *mdioHandle = ( mdio_handle_t * )( phyHandle.resource );
sysClock = mdioHandle->resource.csrClock_Hz;

the code builds but it crashes when executing this:

static inline status_t PHY_Init(phy_handle_t *handle, const phy_config_t *config)
{
handle->ops = config->ops;
return handle->ops->phyInit(handle, config);
}

this is what I get into the debug console:

Temporary breakpoint 18, main () at ../source/MIMXRT1021_Project.c:199
199 BOARD_ConfigMPU();

Breakpoint 14, pxNXP1060_FillInterfaceDescriptor (xEMACIndex=0, pxInterface=0x2000608c <xInterfaces>) at ../source/external/freertos-plus-tcp/source/portable/NetworkInterface/NXP1060/NetworkInterface.c:311
311 return pxInterface;

Breakpoint 8, main () at ../source/MIMXRT1021_Project.c:249
249 vTaskStartScheduler();

Breakpoint 10, PHY_Init (handle=0x2000000c <phyHandle>, config=0x2000001c <xConfig>) at ..\source\external\phy/fsl_phy.h:202
202 handle->ops = config->ops;

Program received signal SIGSTOP, Stopped (signal).
HardFault_Handler () at ../source/semihost_hardfault.c:53
53 __asm( ".syntax unified\n"

I’m not so skilled in C to identify the issue, but I hope that someone will be able to catch the issue with the provided information...

EDIT:

moreover, I tried to update the Driver > Enet from the last version of mcux-sdk (i was still using the driver from v.2.12 in the previous build).
But, after changing the driver, I'm not able anymore to build, receiving the following error: 

../source/external/phy/mdio/enet/fsl_enet_mdio.c: In function 'ENET_MDIO_WriteExt':
../source/external/phy/mdio/enet/fsl_enet_mdio.c:125:5: error: too few arguments to function 'ENET_StartExtC45SMIWriteReg'
125 | ENET_StartExtC45SMIWriteReg(base, phyAddr, devAddr);
    | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../source/external/phy/mdio/enet/fsl_enet_mdio.h:11,
from ../source/external/phy/mdio/enet/fsl_enet_mdio.c:8:
..\source\external\enet/fsl_enet.h:1061:20: note: declared here
1061 | static inline void ENET_StartExtC45SMIWriteReg(ENET_Type *base, uint8_t portAddr, uint8_t devAddr, uint16_t regAddr)
     |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
../source/external/phy/mdio/enet/fsl_enet_mdio.c: In function 'ENET_MDIO_ReadExt':
../source/external/phy/mdio/enet/fsl_enet_mdio.c:155:5: error: too few arguments to function 'ENET_StartExtC45SMIWriteReg'
155 | ENET_StartExtC45SMIWriteReg(base, phyAddr, devAddr);
    | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
..\source\external\enet/fsl_enet.h:1061:20: note: declared here
1061 | static inline void ENET_StartExtC45SMIWriteReg(ENET_Type *base, uint8_t portAddr, uint8_t devAddr, uint16_t regAddr)
     |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [source/external/phy/mdio/enet/subdir.mk:20: source/external/phy/mdio/enet/fsl_enet_mdio.o] Error 1
make[1]: *** Waiting for unfinished jobs....
Finished building: ../startup/startup_mimxrt1021.c

I also tried to use the IDE SDK (downloaded from MCUXpresso SDK Builder) but in that case also the MDIO driver disappear, making the NetworkInterface unusable. 

Is possible that drivers and components are not compatible if pulled from the same version of the repository? 

Thanks

[salva214]

duplicated message

[Kan_Li]

Hi @salva214 ,

How did you implement the mdioHandle()? if you call it directly in the code, will such error happen again?

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

[salva214]

Hi @Kan_Li,
thanks for the reply!

the mdioHandle() is implemented in the NetworkInterface.c file inside the NXP1060 folder of the portable folder section of FreeRTOS+TCP source, exactly @ line 200 of the file. The relevant portion of that file (whith some adapt attempt) is the following: 

static mdio_handle_t mdioHandle = { .ops = &EXAMPLE_MDIO_OPS };

//static phy_handle_t phyHandle = { .phyAddr = 0x00, .mdioHandle = &mdioHandle, .ops = &EXAMPLE_PHY_OPS };
// static phy_handle_t phyHandle = { .phyAddr = 0x00, .ops = &EXAMPLE_PHY_OPS };
static phy_handle_t phyHandle = { .phyAddr = 0x00, .resource = ( void * )&mdioHandle, .ops = &EXAMPLE_PHY_OPS };

//static phy_handle_t phyHandle = { .phyAddr = BOARD_ENET0_PHY_ADDRESS, .mdioHandle = &mdioHandle, .ops = &EXAMPLE_PHY_OPS };

but i don't get any error using the 2.12 version of the ksdk, simply i don't get any packet incoming. with the latest version of the ksdk I get the error because of the rearrangement of the driver provided for the PHY. 
Hence I'm not able to call directly mdioHandle() from my code because I'm not able to build and run my code with the latest drivers...