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.

Compiler/TDA4VM: How to communicate with external devices using MCU_SPI as slave

Part Number: TDA4VM


Tool/software: TI C/C++ Compiler

Hi,

I want to communicate with external devices using MCU_SPI as slave, and need to test it.

Which files do I need to config or modify?

Is there any guideline can provide?

Best Regard,
Leo Ho

  • Hi Leo Ho,

    Are you on the latest SDK 6.02? Can you please look at the existing example at psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/drv/spi/example/mcspi_slavemode/src and see if this works for you?

    Regards,

    Karan

  • Hi Karan,

    I'm on the latest SDK 6.02, and the folder looks like what I need, but I have some questions below.

    1. We are not using CCS to run the example, is the same way to run it by UART?
    2. If we need to communicate with external devices using MCU_SPI as slave, what should we do?

    Best Regard,
    Leo Ho

  • Hi Leo Ho,

    The example I pointed you to is validated with CCS, it requires to load the Slave binary and the Master binary on two different core.

    By UART do you mean you want to look at the logs coming on UART? If so, the the logs even in case of running from CCS would be displayed on the MCU and MAIN UARTs.

    Please browse through the code in case you want to take reference to create your own use-case, but I would strongly suggest to run the existing example first with CCS. I can help you with all that setup in case you haven't used CCS before.

    Regards,

    Karan

  • Hi Karan,

    For some reasons we don't use CCS.
    Can I use binary file link in /lib/firmware to .xer5f file, or have other kinds of methods to use by UART?

    Best Regard,
    Leo Ho

  • Hi Leo Ho,

    In case of CCS we need to create two xer5f (master running on MCU and slave running on MPU).

    So other than CCS you could have used SBL for booting the multicore image.

    A multicore image is basically two images stitched together and then the SBL loads images from the multicore image on respective cores.

    SBL would load a multicore image (slave on MPU and master on MPU) and run, this could have been another way in which you could have tried to run the same application. But the problem comes because the application was never validated/supported with SBL boot, it could run but it might give some errors too.

    The check the above I tried to create a multicore image from the CCS example and ran using the SBL, seems like a some tests fail and some pass.

    The reason for failure of a CCS app not working with SBL could most likely be because either the memory map of the application is not compatible with that of the SBL or there is some resource constrain.

    Now coming back to the question - 

    1. You want a reference to an existing code - the example can provide that.
    2. You can take the code and create an example of your own and load from your preferred method.

    Regards,

    Karan

  • Hi Karan,

    I would like to run the example on SBL first, cause some reasons can't use CCS to run up.
    How to run the example on SBL?

    Best Regard,
    Leo Ho

  • Hi Leo Ho,

    You would like to run your own application with SBL or do you want to run the mcspi_slavemode application in the SDK with SBL?

    If you want to run the mcspi_slavemode then some tests will fail as this is not supported with SBL boot.

    Regards,

    Karan

  • Hi Karan,

    I want to try to run the mcspi_slavemode application in the SDK with SBL.
    Have some fails is fine, I just want to try it.

    Thank you.

    Best Regard,
    Leo Ho

  • Hi Leo Ho,

    As this is not supported, it might seem a little involved without proper documentation in place. But I'll try to help you here.

    So if you look at the documentation of the application, \details in the comments in main_mcspi_slave_mode.c

      23  *          For AM65xx and J721e devices, to demonstrate the example two cores  
      24  *          on the same SoC are needed, mcu1_0 uses McSPI instance 2 on the MCU 
      25  *          domain as the master and mpu1_0 uses  McSPI instance 4 on the Main  
      26  *          doman as slave. These two instances are internally connected in the SoC:
      27  *                                                                              
      28  *          Following is the internal pin signal connection information:        
      29  *          MasterSPI_SCLK----SlaveSPI_SCLK                                     
      30  *          MasterSPI_D1------SlaveSPI_D0                                       
      31  *          MasterSPI_D0------SlaveSPI_D1                                       
      32  *          MasterSPI_CS------SlaveSPI_CS                                       
      33  *                                                                              
      34  *          To run the example:                                                 
      35  *          1) Run the MasterSlave mpu1_0 test binary (slave) on MPU1_0 core    
      36  *          2) Run the MasterSlave mcu1_0 test binary (master) on MCU1_0 core   
      37  *          3) Be sure to run slave application and then master application  

    Modification to the app:

    Can you please make changes to the main_mcspi_slave_mode.c and spi_component.mk as mentioned in the below patch?

    The Task_sleep(10000) is needed in the master task as you need to have the slave running first. This is taken care of in the CCS boot method by loading and running the slave app first but as here the SBL loads it, we need to explicitly delay the master task a little. (10s here, just an arbitrary delay I chose).

    The other change to enable appimage creation is to create images which could be loaded by SBL.

    diff --git a/packages/ti/drv/spi/example/mcspi_slavemode/src/main_mcspi_slave_mode.c b/packages/ti/drv/spi/example/mcspi_slavemode/src/main_mcspi_slave_mode.c
    index 750aab3..a8d2a26 100755
    --- a/packages/ti/drv/spi/example/mcspi_slavemode/src/main_mcspi_slave_mode.c
    +++ b/packages/ti/drv/spi/example/mcspi_slavemode/src/main_mcspi_slave_mode.c
    @@ -1563,6 +1563,7 @@ Void masterTaskFxn (UArg arg0, UArg arg1)
     void masterTaskFxn()
     #endif
     {
    +    Task_sleep(10000);
         uint32_t  i;
         bool      testFail = false;
         SPI_Tests *test;
    diff --git a/packages/ti/drv/spi/spi_component.mk b/packages/ti/drv/spi/spi_component.mk
    index 89a66d8..6ac5ae6 100755
    --- a/packages/ti/drv/spi/spi_component.mk
    +++ b/packages/ti/drv/spi/spi_component.mk
    @@ -390,6 +390,7 @@ export MCSPI_MasterSlave_TestApp_BOARD_DEPENDENCY
     export MCSPI_MasterSlave_TestApp_CORE_DEPENDENCY
     export MCSPI_MasterSlave_TestApp_XDC_CONFIGURO
     export MCSPI_MasterSlave_TestApp_MAKEFILE
    +export MCSPI_MasterSlave_TestApp_SBL_APPIMAGEGEN = yes
     MCSPI_MasterSlave_TestApp_PKG_LIST = MCSPI_MasterSlave_TestApp
     MCSPI_MasterSlave_TestApp_INCLUDE = $(MCSPI_MasterSlave_TestApp_PATH)
     MCSPI_MasterSlave_TestApp_BOARDLIST = $(drvspi_BOARDLIST)

    Building the two different binaries:

    Execute the following from <SDK_PATH>/psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/build

    # Master app on MCU1_0
    make MCSPI_MasterSlave_TestApp CORE=mcu1_0 -sj
    
    # Slave app on MPU1_0
    make MCSPI_MasterSlave_TestApp CORE=mpu1_0 -sj

    After this step, you should have two *.rprc files as:

    -rw-rw-r-- 1 karan karan  97712 May 13 14:37 pdk/packages/ti/binary/MCSPI_MasterSlave_TestApp/bin/j721e_evm/MCSPI_MasterSlave_j721e_evm_mcu1_0TestApp_release.rprc
    -rw-rw-r-- 1 karan karan 419000 May 13 14:36 pdk/packages/ti/binary/MCSPI_MasterSlave_TestApp/bin/j721e_evm/MCSPI_MasterSlave_j721e_evm_mpu1_0TestApp_release.rprc

    Combining the images in a multicore image

    Once we have the two rprc images we need to create a multicore image (a stitched image version of these two) which can be loaded by the SBL.

    You can refer http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_Foundational_Components.html#boot section 4.6.3.3.6 Multicore Images.

    cd psdk_rtos_auto_j7_06_02_00_21/pdk/packages/ti/boot/sbl/tools/multicoreImageGen/bin
    
    
    #<PDK>/packages/ti/boot/sbl/tools/multicoreImageGen/bin/MulticoreImageGen LE 55 output.appimage  <core_id_1> core_1.rprc <core_id_2> core_2.rprc
    
    ./MulticoreImageGen LE 55 app 0 <PATH_TO_BIN>/MCSPI_MasterSlave_j721e_evm_mpu1_0TestApp_release.rprc 4 <PATH_TO_BIN>/MCSPI_MasterSlave_j721e_evm_mcu1_0TestApp_release.rprc

    Now use this app and put it in the SD card along with the SBL and sysfw.bin

    # build mmcsd SBL
    cd pdk/packages/ti/build
    make sbl_mmcsd_img -sj
    
    # binary locatoin
    -rw-rw-r-- 1 karan karan 161228 May 13 15:15 pdk/packages/ti/boot/sbl/binary/j721e_evm/mmcsd/bin/sbl_mmcsd_img_mcu1_0_release.tiimage
    
    # Copy the above *tiimage and put it in your SD card boot partition (rename to tiboot3.bin)
    
    # Copy sysfw.bin to SD card boot partition
    -rw-rw-r-- 1 karan karan 263072 Feb 21 17:50 pdk/packages/ti/drv/sciclient/soc/V1/sysfw.bin
    
    # Copy the app generated to SD card boot partition
    
    # Contents of SD card boot/ 
    # 1. tiboot3.bin
    # 2. sysfw.bin
    # 3. app

    Viewing the output
    EVM setup http://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/latest/exports/docs/psdk_rtos_auto/docs/user_guide/evm_setup_j721e.html 
    Change boot mode of the EVM to SD boot - Connect to serial terminals 2nd instance on MCU UART and 1st instance on MAIN UART. Power ON.

    Let me know if this works for you.

    Regards,

    Karan

  • Hi Karan,

    Thanks for your support, there is the log below:

    For MAIN UART: 

     SPI UT 1
    
     
     SPI master slave test slave in non-dma interrupt mode
    SPI initialized
    Slave: PASS: Txd from master SPI 
    
     
     SPI master slave test slave in non-dma interrupt mode have passed
    
     SPI UT 2
    
     
     SPI master slave test slave in polling mode
    SPI initialized
    Slave: PASS: Txd from master SPI 
    
     
     SPI master slave test slave in polling mode have passed
    
     SPI UT 3
    
     
     SPI master slave test slave in non-dma callback mode
    SPI initialized
    Slave: PASS: Txd from master SPI 
    
     
     SPI master slave test slave in non-dma callback mode have passed
    
     SPI UT 12
    
     
     SPI slave transfer error test in non-dma interrupt mode
    
     
     SPI slave transfer error test in non-dma interrupt mode have passed
    
     SPI UT 13
    
     
     SPI slave phase polarity test in non-dma interrupt mode
    SPI initialized
    Slave: PASS: Txd from master SPI 
    
     
     SPI slave phase polarity test in non-dma interrupt mode have passed
    
     SPI UT 6
    
     
     SPI master slave test slave multi channel in non-dma interrupt mode
    SPI instance 4 channel 0
    Slave: PASS: Txd from master SPI 
    
     
     SPI master slave test slave multi channel in non-dma interrupt mode have passed
    
     SPI UT 7
    
     
     SPI master slave test slave in polling mode
    SPI instance 4 channel 0
    Slave: PASS: Txd from master SPI 
    
     
     SPI master slave test slave in polling mode have passed
    
     SPI UT 8
    
     
     SPI master slave test slave in non-dma callback mode
    SPI instance 4 channel 0
    Slave: PASS: Txd from master SPI 
    
     
     SPI master slave test slave in non-dma callback mode have passed
    
     SPI UT 11
    
     
     SPI master slave test slave multi channel RX_ONLY test
    SPI instance 4 channel 0
    Slave: PASS: Txd from master SPI 
    
     
     SPI master slave test slave multi channel RX_ONLY test have passed
    
     All tests have passed. 
    Done
    

    For MCU UART:

    SBL Revision: 01.00.09.02 (Apr 13 2020 - 17:11:43)
    SYSFW  ver: 19.12.1-v
    19.12a (Terrific Lla
    
     SPI UT 1
    
     
     SPI master slave test master in non-dma interrupt mode
    SPI initialized
    Master: PASS: Txd from slave SPI  
    
     
     SPI master slave test master in non-dma interrupt mode have passed
    
     SPI UT 2
    
     
     SPI master slave test master in polling mode
    SPI initialized
    Master: PASS: Txd from slave SPI  
    
     
     SPI master slave test master in polling mode have passed
    
     SPI UT 3
    
     
     SPI master slave test master in non-dma callback mode
    SPI initialized
    Master: PASS: Txd from slave SPI  
    
     
     SPI master slave test master in non-dma callback mode have passed
    
     SPI UT 12
    
     
     SPI master transfer error test in non-dma interrupt mode
    
     
     SPI master transfer error test in non-dma interrupt mode have passed
    
     SPI UT 13
    
     
     SPI master phase polarity test in non-dma interrupt mode
    SPI initialized
    Master: PASS: Txd from slave SPI  
    
     
     SPI master phase polarity test in non-dma interrupt mode have passed
    
     SPI UT 6
    
     
     SPI master slave test master multi channel in non-dma interrupt mode
    SPI instance 2 channel 0
    SPI instance 2 channel 1
    SPI instance 2 channel 2
    SPI instance 2 channel 3
    Master: PASS: Txd from slave SPI  
    
     
     SPI master slave test master multi channel in non-dma interrupt mode have passed
    
     SPI UT 7
    
     
     SPI master slave test master multi channel in polling mode
    SPI instance 2 channel 0
    SPI instance 2 channel 1
    SPI instance 2 channel 2
    SPI instance 2 channel 3
    Master: PASS: Txd from slave SPI  
    
     
     SPI master slave test master multi channel in polling mode have passed
    
     SPI UT 8
    
     
     SPI master slave test master multi channel in non-dma callback mode
    SPI instance 2 channel 0
    SPI instance 2 channel 1
    SPI instance 2 channel 2
    SPI instance 2 channel 3
    Master: PASS: Txd from slave SPI  
    
     
     SPI master slave test master multi channel in non-dma callback mode have passed
    
     SPI UT 10
    
     
     SPI master slave test master multi channel TX_ONLY test
    SPI instance 2 channel 0
    SPI instance 2 channel 1
    SPI instance 2 channel 2
    SPI instance 2 channel 3
    
     
     SPI master slave test master multi channel TX_ONLY test have passed
    
     SPI UT 20
    
     
     SPI master data size test in loopback mode
    
    
     SPI master data size test in loopback mode with SPI Mode 0
    SPI initialized
    
     
     SPI master data size test in loopback mode have failed
    
     Some tests have failed. 
    Done
    

    Have some questions:

    1. Is the error log above mentioned last time?
    2. If I want to work master on mpu and slave on mcu, what should I do?

    Thanks again.

    Best Regard,
    Leo Ho

  • Hi Leo Ho,

    leo ho said:
    If I want to work master on mpu and slave on mcu, what should I do?

    If you look at the makefile you will see the flags  -DMCSPI_SLAVE_TASK and  -DMCSPI_MASTER_TASK being defined under the build flags for mcu1_0 or mpu1_0. So when you build for mcu1_0 the flag  -DMCSPI_MASTER_TASK gets defined, you can change this to  -DMCSPI_SLAVE_TASK and same for mpu1_0. Make corresponding changes to the source files if needed.

    leo ho said:
    Is the error log above mentioned last time

    Can you clarify this more?

    Regards,

    Karan

  • Hi Karan,

    You have mention the problem comes because the application was never validated/supported with SBL boot, it could run but it might give some errors too by using SBL.
    Is the cause of error log?

    Best Regard,
    Leo Ho 

  • Hi Leo Ho,

    Yes, that is the reason for the failure. The application works fine with expected logs when run from CCS.

    Regards,

    Karan