TMDS64EVM: Ethernet Loop Back MAC Address Read Failure

Hi Huynh Nguyen,

Thanks for your query.

Which SDK are you working on ?

This is out of box SDK example or you have made some changes and getting this error ?

Regards

Ashwani

mcu_plus_sdk_am64x_10_01_00_32

Out of the box examples for both MAC and PHY loopback

ti\mcu_plus_sdk_am64x_10_01_00_32\source\networking\enet\core\examples\enet_loopback\enet_cpsw_loopback.

As indicated these examples for ENET loopback is not changed.

What changed was the example I2C_memory_read as described to do the exercise of FILE write/read. However;

the smaller file to write/read to I2C (6KB) then it was no issue with running ENET loopback. But when run the big file (128KB) to I2C and then go to the ENET example projects, the error was flagged as shown.

What happened to the board is repeated at the same failure over and over again. I changed the board to a new 64EVM board and run the ENET loopback exercises and it ran OK. I also tried to run I2C exercise with smaller file(6KB) and after rerun the ENET loopback exercises, the board is working fine. What I DID NOT want to do is to run the big file (128KB) to I2C because I am afraid it might cause the same problem with ENET exercises. 

Hi,

I am looking from ethernet point of view. Adding I2C expert here.

Regards

Ashwani

Hi Huynh,

Huynh Nguyen said:

What changed was the example I2C_memory_read as described to do the exercise of FILE write/read. However;

Are you able to write the data properly via I2C? Are you facing any issues while writing large file?

Also have you verified the content after writing?

Regards,

Tushar

The FILE write/read routines are as follows : 

1. Prompt for file name input either on CIO or from TeraTerm I/F on the CONSOLE uart.

2. fseek () todetermine the file size and Malloc the buffer accordingly.

3. fread(*buffer, 1 *fileSize, file) to the buffer appropriately.

4. Set the remainder = fileSize % 256 //this is the last I2C write after 256byte pages.

5. Prepare the loop of count for 256bytes increment and transfer the *buffer in (3) to tx_buffer_256[] accrodingly

6. Within the count loop, set the I2C memory transaction as : 

    mem_transaction.buffer = txBuffer_256; // this is the 256 byte buffer

    mem_transaction.size = ((count+256)>(uint32_t)fileSize) ? remainder : (uint32_t)256;   

    mem_transaction.memDataDir = I2C_MEM_TXN_DIR_TX;

7. On the read back, do the reverse and malloc the *rxBuffer of the fileSize;

8. Similar loop of count for read of the 256 byte read pages into rxBuffer_256;

    mem_transaction.buffer = rxBuffer_256;

    mem_transaction.size = ((count+256)>(uint32_t)fileSize) ? remainder : (uint32_t)256;

    mem_transaction.memDataDir = I2C_MEM_TXN_DIR_RX;

9. After each page read transfer rxBuffer_256[] into *rxBuffer until the end (of remainder count)

10. Read back the rxBuffer in the Log and compare to original file.

As stated the file size of around 6KB the operation was good with confirmation of Write/Read verify OK.

But the test of ENET loopback (MAC/PHY - A53 and R5F) after was OK.

However; the I2C write/read for file of around 128KB generated some errors on file compare.

Right after I2C operation on the large file, The ENET loopback fails to work as shown on all instances.

Note that in the example.syscfg the MEMORY CONDFIGURATOR - General was set the stack and heap accordingly to satisfy the malloc() 

Hi Huynh,

Huynh Nguyen said:

However; the I2C write/read for file of around 128KB generated some errors on file compare.

For me it looks like the data is not completely written to the I2C EEPROM. Can you please check how many pages of the memory are correctly written and after which page the data inconsistency happens?

The The AT24CM01 EEPROM is internally organized as 512 pages of 256 bytes each(~128KB). 

Regards,

Tushar

It was written correct number of pages to I2C. However; this is not the issue of I2C BUT the issue of ENET loopback.

The only I2C mentioned herein is because after write/read the large file (~128KB, not exact), the ENT loop back had this issue.

Why is it having this problem on all 4 examples of MAC and PHY loop back with A53 and R5F using FreeRTOS : 

MAIN_Cortex_R5_0_0: Assertion @ Line: 287 in syscfg/ti_board_config.c: ENET_GET_NUM_MAC_ADDR(numMacMax) <= ENET_BOARD_NUM_MACADDR_MAX : failed !!!

My question is where the MAC addresses stored in the non-volatile memory ?

Hi Huynh,

Huynh Nguyen said:

It was written correct number of pages to I2C. However; this is not the issue of I2C BUT the issue of ENET loopback

Thanks for the confirmation that I2C read/writes are happening properly.

I am reassigning your thread to Ethernet expert for further comments.

Regards,

Tushar

Further investigation, the problem will disappear if in the SYSCONFIG under TI NETWORKING for Enet (CPSW), under the tab System Integration Config

I have to change "MAC Address Assignment Method" from "Auto Assign" to Manual Entry as shown here : 

After this I could run the Ethernet Loopback. So the question is on the bad board it will not work with "Auto Assign" for MAC address and on the good board it will work on both cases "Auto Assign" and "Manual Entry". Is there any situation that can cause this problem ? Could someone explain to me why it is behaving as such ?

Thanks,

Huynh

Huynh Nguyen said:

Originally EVM test on Ethernet loopback test was working fine until the I2C device 0x50 (Board_ID EEPROM) was tested with writing large file (

It seems that you have overwritten original MAC address of the EVM.

I am adding HW expert here to help you out if there is a way.

Please allow him some time to work with EVM team and get back to you.

Regards

Ashwani

Where were the MAC addresses stored in ? Was it in the the I2C (Board_ID) EEPROM that I mentioned ?

If it was the case then I already gave the clue the MAC addresses read invalid after exercise large file write/read

to I2C device and it was supposed to be identified already the problem.

So I wait for the solution to write them back to the device somehow.

Thanks,

Huynh

Hello Huynh

I have been assigned the query.

Can you please summarize the issue for me to follow-up in case this is related to hardware.

Regards,

Sreenivasa

If you follow the posts you should be able to identify if it is HW or SW related. Please read all the posts and here is the summary : 

- I changed the i2c_memory_read example (from simple 10 counts) to exercise the file write/read of a file. The original file size for I2C exercise was 6KB.

- At the same time I ran the of ethernet loop back exercise and everything was fine. 

- I changed the file size of I2C exercise to a larger file of 128KB which is the maximum of the I2C device capacity.

- After that the ethernet loop back exercise failed as : 

MAIN_Cortex_R5_0_0: ============================
MAIN_Cortex_R5_0_0: Enet Loopback : Iteration 1
MAIN_Cortex_R5_0_0: ============================

MAIN_Cortex_R5_0_0: CPSW_3G Test
MAIN_Cortex_R5_0_0: Enabling clocks!
MAIN_Cortex_R5_0_0: Assertion @ Line: 287 in syscfg/ti_board_config.c: ENET_GET_NUM_MAC_ADDR(numMacMax) <= ENET_BOARD_NUM_MACADDR_MAX : failed !!!

- I suspected the MAC addresses were saved in this I2C (addr 0x50) device somehow but no one in your team seemed to understand why it was related.

- I then changed the MAC add setting from "auto assign" to "manual entry" shown in the previous post and the ethernet loopback works but only works if the MAC addresses for 2 instances are set manually and would not work if set "auto assign" again.

- It confirmed to me that these MAC addresses must be saved in some locations high up in the I2C device which were wiped out during I2C read/write exercise of a large file. I do not know for sure but usually the MAC addresses of the board are normally saved in the I2C

Hello Huynh

Thank you.

Let me review the inputs and check with the team if there is a way to recover or restore the MAC id to the EEPROM.

Regards,

Sreenivasa

Hello Sreenivasa,

Any update on this issue ? If indeed the MAC information was saved in the I2C EEPROM then I only need the address and the format of saving those two MAC addresses. I would be able to write them back to the I2C.

Thanks,

Huynh

Hello Huynh

Thank you for following.

I am following-up with the EVM team.

Regards,

Sreenivasa