• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 30 subscribers
  • Views 428 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMDS243EVM: Resource conflict with respect to I2C instances while trying to build a multicore project that uses both CPSW and ICSSG instances together.

Shobhit Sharma
Prodigy 31 points
Part Number: TMDS243EVM

Hi Experts,

So I wanted to implement a multicore project to use CPSW and ICSSG LWIP stack together. The motivation is as follows:
  

  1. Core r5Fss0-0: Implements the example  "enet_lwip_cpsw", source: enet_lwip_cpsw (ti.com) @ MCU+ SDK for AM243x (09.00.00.35)
  2. Core r5Fss0-1: Implements the eaxmple  "enet_lwip_icssg", source  enet_lwip_icssg (ti.com) @Industrial Communications SDK for AM243x (09.00.00.03)

I read the SDK documentation on the need to allocate resources and change the linker commands, if one wants to wortk with multiple cores. I have made the neccessary changes in system config and the linker scripts.

Consequently I created a CCS 'System' project as follows:

Important to mention here is that the two examples run on the two desired cores separately, however when I try to build/complie the combined multicore project, I get errors saying that there is resource conflict between the the two cores as shown in the snippet below:

I tried to assign the other I2C instances for e.g. I2C_2 and I2C_3 also the MCU domain instances, this change enabled thge build to be successful but then at runtime the CPSW based app cannot read the MAC address from EEprom and I get the following assert failure:

Also according to the user guide it can be intrepreted that I2C0 and I2C1 are the correct instances:/resized-image/__size/320x240/__key/communityserver-discussions-components-files/908/pastedimage1699372110278v1.png

What am I missing?  Is there a different approach that needs to be followed. Could it be that some driver change is required?

Kindly advise.

Many thanks and best regards,

Shobhit

  • 0
    Prodigy 31 points

    Edit:

    So I wanted to implement a multicore project to use CPSW and ICSSG LWIP stack together. The motivation is as follows:
      

    1. Core r5Fss0-0: Implements the eaxmple  "enet_lwip_icssg", source  enet_lwip_icssg (ti.com) @Industrial Communications SDK for AM243x (09.00.00.03) 
    2. Core r5Fss0-1: Implements the example  "enet_lwip_cpsw", source: enet_lwip_cpsw (ti.com) @ MCU+ SDK for AM243x (09.00.00.35)
  • +1
    TI__Genius 16272 points

    Hi Shobhit, 

    Firstly, to enable your use case, we would have to make sure that you were able to run the following independently:

    1. Enet_lwip_icssg example on r5fss0_0 core (or r5fss0_1 core)
    2. Enet_lwip_cpsw example on rf0_1 core. (or r5fss0_0 core)

    Can you please share if you were able to work out both of the above independently?

    Secondly, the board EEPROM contains information such as the Board ID, MAC address etc. and is interfaced through I2C0. Since we allocate other I2C instances to CPSW, it is not able to get information from EEPROM.

    But there is one way to work around this step, that is to use a fixed hard-coded MAC address, rather than using I2C for reading it through EEPROM.

    When you build the application, you get a "generated" folder. This folder contains the auto-generated file based on the syscfg configurations made by you.

    Steps to enable hard-coded MAC address:

    1. Navigate to enet_lwip_cpsw/icssg example. 
    2. Navigate to the generated folder (general path is enet_lwip_cpsw/am243x-evm/r5fss0-0_freertos/ti-arm-clang/generated
    3. Open the ti_enet_soc.c file and locate //#define ENET_MAC_ADDR_HACK (TRUE)
    4. Enable this macro, setting it to true, 
    5. In the function "EnetSoc_getEFusedMacAddrs()" return the desired MAC address
    6. Recompile the project. 

    Following the steps above should unblock you for now. You can try the above steps.

    Apart from this, you might also face an issue with the shared UDMA resource. In case you do, try to divide the UDMA RX and TX rings between equally between the 2 applications.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 31 points

    Hi Shaunak,

    Thanks for your reply!
    In my query itself I stated that the two apllications are runninng successfully on the two cores:

    Shobhit Sharma said:
    Important to mention here is that the two examples run on the two desired cores separately,

    I guess my choice of words was not correct.

    I will give you a feedback regarding the Second part of your response.

    Thanks again.

    Best regards,

    Shobhit

  • 0 in reply to Shobhit Sharma
    Prodigy 31 points

    Hi Shaunak,

    The workaround with hard coded MAC address worked! 

    However the original question remains, can two cores use I2C to read data from EEPROM or is it a limitation of the EVM board?

    So just to be sure that I have understood the constraint properly, It can be concluded that only one core can communicate with EEPROM, if the other core needs data from EEPROM then some other mechanisms are required.

    These mechanisms could be IPC or any other shared memory access?

    Kindly advise.

    Thanks and best regards,

    Shobhit

  • +1 in reply to Shobhit Sharma
    TI__Genius 16272 points

    Hi Shobhit, 

    I had an internal discussion with the team. Two cores might be able to use I2C0 to read data from EEPROM if I2C0 is handled correctly. This hasn't been internally tested so we haven't included a similar scenario in the SDK, but closing I2C driver on reading First MAC address in the EnetBoard_getMacAddrList function, and then opening I2C instance on 2nd core and reading data from EEPROM might resolve the issue.

    Again, this hasn't been fully tested.

    Secondly, you could have some IPC framework to share data from 1st core to 2nd core where 1st core reads the EEPROM data. I don't see any issue with that.

    Regards,
    Shaunak