• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 951 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.

TMS570LS3137: Reading of MibSPI Tx and Rx Status Flags as created in HALCoGen SPI.C driver

N King
Intellectual 460 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN

I'm rather confused that for a TRANSMIT function, in routine spiTransmitData of spi.c, the process seems to be controlled by reading the RX flag, bit 8, as per this snippet:

        /*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */
        while((spi->FLG & 0x00000100U) != 0x00000100U)
        {

 according to the device Technical Reference Manual, spnu499b dated November 2012–Revised August 2013, 25.9.5 SPI Flag Register (SPIFLG).

The same bit is used for the spiDataReceive function.

The TX flag, which would be 0x00000200U does not appear to be used at all...


In my code, the process hangs up as this RX bit is cleared: looking at the project I copied it from, it works. What have I not set up??? Also in the source project, bit 24, BUFINITACTIVE is continuously set, although I have not knowingly set the part up as MibSPI: in HALCoGen I request simple SPI1, 2 & 3 drivers to be enabled.


HALCoGen revision 04.05.01 Release 28 August 2015.

 

Thanks

  • 0
    TI__Mastermind 32565 points
    Hi,

    SPI is full-duplex communication module. Whenver it does a TX, a RX is always done along with it. In TransmitData function, even though the inention is only to send the data, it also does receive some data. The data received here is condidered as dummy. same is the case for RX. In spiReceiveData function, a data of value 0 is sent so that the actual RX data can be read.

    TranmitAPI:
    spi->DAT1 = ((uint32)DataFormat << 24U) |
    ((uint32)ChipSelect << 16U) |
    (WDelay) |
    (Chip_Select_Hold) |
    (uint32)Tx_Data;
    /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
    srcbuff++;
    /*SAFETYMCUSW 28 D MR:NA <APPROVED> "Hardware status bit read check" */
    while((spi->FLG & 0x00000100U) != 0x00000100U)
    {
    } /* Wait */
    SpiBuf = spi->BUF;

    In the code snippet above, the driver is trying to write the data (TX_Data) and waits for the Rx complete Flag and then does a dummy read to the BUF register where the received data is present.

    Thanks and Regards,
    Veena
  • 0 in reply to Veena Kamath
    TI__Mastermind 32565 points
    HI,

    The MISBSPI RAM gets initialized, the moment GCR0 register is set to 1. The BUFINITACTIVE flags remains 1 until the RAM init is completed. This is also done as part of startup code.

    /* Release the MibSPI1 modules from local reset.
    * This will cause the MibSPI1 RAMs to get initialized along with the parity memory.
    */
    mibspiREG1->GCR0 = 0x1U;

    ..
    ..
    ..

    while ((mibspiREG1->FLG & 0x01000000U) == 0x01000000U)
    {
    }/* Wait */
    /* wait for MibSPI1 RAM to complete initialization */

    Thanks and Regards,
    Veena
  • 0 in reply to Veena Kamath
    Intellectual 460 points
    Thanks for your responses. However, the solution was to correct some format option errors in HALCoGen.
    I'm slightly puzzled that the BUFINITACTIVE flag remains set - I'm presuming this is as I am not using the multi-buffer mode.