RT1064 Enet ENET_SendFrame execution time

cancel
Showing results for 
Search instead for 
Did you mean: 

RT1064 Enet ENET_SendFrame execution time

Jump to solution
119 Views
Contributor III

I use RT1064 and have two board(A and B)and found a problem: Board A send  a message to Board B(cycle is 50us), B recieve message and  go into interrupt . In receiving interrupt handler code,Board B  send an ack-message to Board A. Packet length is 64 bytes。RXB and RXF interrupt is turned on, and TXB and TXF interrupt is disable. 

Same problem for A and B: ENET_SendFrame execution time is occasionally long。But there is no loss of messages

 

I used the PIT module in RT1064 to calculate the ENET_SendFrame execution time. In most cases, it does not exceed 1us, but occasionally exceeds 20us. there is no obvious pattern of time-consuming. I hope that the execution time of ENET_SendFrame is consistent and the difference is small。

1. What is the possible cause of this problem?

2. ENET_SendFrame call memcpy and DCACHE_CleanByRange,they occasionally take a long time. WHY?

Sometimes they take a short time, but ENET_SendFrame still takes a long time,this proves that there are other reasons

ENET_SendFrame.png

3. How to turn off all interrupts of RT1064? I checked the manual and I didn’t find the registers that mask all interrupts.I wonder if there is interrupt that I don’t know about. In Board B receiving interrupt, I disable all interrupts to check whether it can solve the problem

Thank you !

Labels (2)
0 Kudos
1 Solution
12 Views
NXP TechSupport
NXP TechSupport

Hi,

I would recommend to refer below thread to place Ethernet data buffer at noncacheable memory range, such as DTCM.

https://community.nxp.com/message/1208210?commentID=1208210#comment-1208210 

The DTCM is non-cache memory range, while OCRAM is cacheable memory range.

When ENET and core as two masters to access the same memory range in OCRAM, in fact both master will access the cache instead of access the OCRAM memory range directly. There could exists the issue when cached data is different with actual data in OCRAM. So, it need to do cache maintainance during actual application.

Make below change to set ENET data buffer memory location:

 

Original definition:(enet_ethernetif_kinetis.c)

    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);

 

Change 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);

SDK software provides DisableGlobalIRQ() funcion to disable the global interrupt.

/*!
* @brief Disable the global IRQ
*
* Disable the global interrupt and return the current primask register. User is required to provided the primask
* register for the EnableGlobalIRQ().
*
* @return Current primask value.
*/
static inline uint32_t DisableGlobalIRQ(void)

 

Wish it helps.

best regards,

Mike

View solution in original post

0 Kudos
2 Replies
13 Views
NXP TechSupport
NXP TechSupport

Hi,

I would recommend to refer below thread to place Ethernet data buffer at noncacheable memory range, such as DTCM.

https://community.nxp.com/message/1208210?commentID=1208210#comment-1208210 

The DTCM is non-cache memory range, while OCRAM is cacheable memory range.

When ENET and core as two masters to access the same memory range in OCRAM, in fact both master will access the cache instead of access the OCRAM memory range directly. There could exists the issue when cached data is different with actual data in OCRAM. So, it need to do cache maintainance during actual application.

Make below change to set ENET data buffer memory location:

 

Original definition:(enet_ethernetif_kinetis.c)

    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);

 

Change 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);

SDK software provides DisableGlobalIRQ() funcion to disable the global interrupt.

/*!
* @brief Disable the global IRQ
*
* Disable the global interrupt and return the current primask register. User is required to provided the primask
* register for the EnableGlobalIRQ().
*
* @return Current primask value.
*/
static inline uint32_t DisableGlobalIRQ(void)

 

Wish it helps.

best regards,

Mike

View solution in original post

0 Kudos
12 Views
Contributor III

Hi,Mike,

The method you provided solves the problem perfectly!

For 100M Ethernet, disable CACHE with the TX/RX packet buffer has no obvious effect on the communication efficiency

Thank you.

0 Kudos