• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 328 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.

TDA4VM: update mcan example to be usable in EVM

Mircea Cociuba
Intellectual 655 points

Part Number: TDA4VM

Hello all ( again ),

As you know, the mcan example for MCU2_1 from CSL, from PDK is not working, as the phisical pins are not available on the base board.

The received solution based on mcusw is tricky, as it only supports mcu1_0 and mcu2_1, and it is autosar based ( need of tresos as license).

For our current needs it is ok ( as long as we receive tresos and license ), but for future releases please update it, so that the mcan works from pdk on mcu2_1.

Br, Mircea

  • 0
    TI__Guru 61306 points

    Hello Mircea,

    MCU2_1 CSL CAN example is working fine , it is programmed to work for MCAN4 instance which is on GESI board (an usual request from customers to show usage of CAN instances on GESI Board ) .To show use case on base board we have MCU1_0 core example which uses MCU_CAN0 instance.

    TI's intent is to show the usage of few CAN instances from different domain cores and of course we cannot enable usage of all CAN instances from different cores.I can raise an requirement for this but based on the requests from multiple clients the request can be taken forward.

    TI is offering EB Tresos license and i hope that shouldn't be a problem.

    Regards

    Tarun Mukesh 

  • 0 in reply to Tarun Mukesh Puvvada
    Intellectual 655 points

    Update the comments only then, write there so that future users will not waste time and money.

    We know that you can not make them all work, that is fine, just mark the ones that do not work and why they do not work.

    Br, Mircea

  • 0 in reply to Tarun Mukesh Puvvada
    Intellectual 655 points

    BTW: can you explain the linker changes you have done, why where they necesary? what are they about?

    My assumption was that you have a memory region carved out for each core, and oh well, that is that, it runs there. Why was a change necessary? and what did that change do?

  • 0 in reply to Mircea Cociuba
    TI__Guru 61306 points

    Hello Mircea,

    Its been mentioned on the top of the source code as part of comments, which core supports which instance and where the instance is as well.

    Note on Available Instances on EVM, and Tested Instances with this example:
    * For J721S2_EVM:
    * Available Instances : MCU_MCAN0,MCU_MCAN1,MAIN_MCAN3,
    * MAIN_MCAN4,MAIN_MCAN5,MAIN_MCAN16
    * Test support Instances : For mcu1_0
    * 1.Transmitter test : MCU_MCAN0
    * 2.Receiver test : MCU_MCAN1
    * 3.Internal loopback: MCU_MCAN0
    * 4.External loopback: MCU_MCAN0,MCU_MCAN1
    * For mcu2_1
    * 1.Transmitter test : MAIN_MCAN4
    * 2.Receiver test : MAIN_MCAN4
    * 3.Internal loopback: MAIN_MCAN4
    * 4.External loopback: MAIN_MCAN4, MAIN_MCAN16
    * NOTE: MAIN_MCAN4 is J6(MC9) on GESI Board for J721S2.
    * For J7200_EVM:
    * Available Instances : MCU_MCAN0, MCU_MCAN1, MAIN_MCAN0, MAIN_MCAN3
    * MAIN_MCAN4, MAIN_MCAN5, MAIN_MCAN6, MAIN_MCAN7,
    * MAIN_MCAN8, MAIN_MCAN10
    * Test support Instances : For mcu1_0
    * 1.Transmitter test : MCU_MCAN0
    * 2.Receiver test : MCU_MCAN1
    * 3.Internal loopback: MCU_MCAN0
    * 4.External loopback: MCU_MCAN0,MCU_MCAN1
    * For mcu2_1
    * 1.Transmitter test : MAIN_MCAN4
    * 2.Receiver test : MAIN_MCAN4
    * 3.Internal loopback: MAIN_MCAN4
    * 4.External loopback: MAIN_MCAN4, MAIN_MCAN5
    * For J721E_EVM:
    * Available Instances : MCU_MCAN0,MCU_MCAN1,MAIN_MCAN0,MAIN_MCAN2
    * MAIN_MCAN4,MAIN_MCAN5,MAIN_MCAN6,MAIN_MCAN7,
    * MAIN_MCAN9,MAIN_MCAN11
    * Test support Instances : For mcu1_0
    * 1.Transmitter test : MCU_MCAN0
    * 2.Receiver test : MCU_MCAN1
    * 3.Internal loopback: MCU_MCAN0
    * 4.External loopback: MCU_MCAN0,MCU_MCAN1
    * For mcu2_1
    * 1.Transmitter test : MAIN_MCAN4
    * 2.Receiver test : MAIN_MCAN4
    * 3.Internal loopback: MAIN_MCAN4
    * 4.External loopback: MAIN_MCAN4, MAIN_MCAN5
    * For J784S4_EVM:
    * Available Instances : MCU_MCAN0,MCU_MCAN1,MAIN_MCAN3,
    * MAIN_MCAN4,MAIN_MCAN5,MAIN_MCAN16
    * Test support Instances : For mcu1_0
    * 1.Transmitter test : MCU_MCAN0
    * 2.Receiver test : MCU_MCAN1
    * 3.Internal loopback: MCU_MCAN0
    * 4.External loopback: MCU_MCAN0,MCU_MCAN1
    * For mcu2_1
    * 1.Transmitter test : MAIN_MCAN4
    * 2.Receiver test : MAIN_MCAN4
    * 3.Internal loopback: MAIN_MCAN4
    * 4.External loopback: MAIN_MCAN4, MAIN_MCAN16
    *
    Since the baseboard and GESI are same for J7200,J721E,J721S2, it is clear that MCAN4 instance is on GESI board.
     
    Mircea Cociuba said:
    : can you explain the linker changes you have done, why where they necesary? what are they about?

    If A72 core is running linux, we have memory mapping in linux as well so the executable running on R5F core should also meet the same memory mapping otherwise it causes data corruption.

    And also certain section of memory is reserved in DDR to run the linux , so those sections usage were avoided from other cores.

    In the patch, i have moved all the data from MAIN_MSRAM to DDR region of MCU2_1 for avoiding the conflicts from linux.

    Regards

    Tarun Mukesh