• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 30 subscribers
  • Views 655 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: SPI Rx interrupt not triggered

ChrisNo
Prodigy 230 points
Part Number: TMS570LS3137
Other Parts Discussed in Thread: HALCOGEN,

Hi all,

I have a TMS570LS31x dev.kit. interfaced with different equipments. HALCoGen and the generated API are used. One of the mentioned equipements is interfaced with via SPI (board as master, said device as slave), and requires only SOMI, SCK and nCS signals. It does not take inputs from the master on the SIMO line, which must be grounded.

When reading from the SOMI line, all that is required to do, is set nCS active, enable SCK and read incoming data. All of this is working fine in polling mode.

When I change to interrupt mode (required in the project), using spiGetData() instead of spiReceiveData(), nothing happens. That is, I observe the communication with an oscilloscop, and nothing happens on either SCK nor nCS (and thus nor on SOMI).

spiInit() is correctly called, all three pins set as functional, RXINTENA set in SPIINT0, and spiEndNotification() should call a function to handle the data (obsviouly, the notification is not triggered). When I breakthrough, I also see that spiGetData() is correctly called, and that the g_spiPacket_t structure is correctly set. I have tried with and without breakpoints in the code.

I am lost here, what am I forgetting?

Thanks in advance,

Christophe

  • 0
    TI__Mastermind 21425 points

    Hello,

    You should enable SPI interrupt in VIM module tab (according to SPI module used (MIBSPI1, MIBSPI2...)).

  • 0 in reply to Miro
    Prodigy 230 points

    Hello and thanks for the answer.

    I forgot to mention that, but it has been done, VIM channels 12 (MIBSPI1 Level 0) and 26 (MIBSPI1 Level 1, just in case) are set indeed. vimInit() is called, and _enable_interrupt_() as well in the initialization phase. This is otherwize working because interrupts are used e.g. with SCI module. I should mention that I use the SPI in compatibility mode, i.e. not MIBSPI, and the SPI1 driver is enabled in the Driver Enable tab.

  • 0 in reply to ChrisNo
    TI__Mastermind 21425 points

    Hello,

    As I understand, TMS570LS3137 HDK is master and you are not observing any signals on nCS and CLK. Am I right?

    From your post I can see that SIMO pin is not set as functional. IF this is true, please set it as functional and set all other unused pins as GIO.

  • 0 in reply to Miro
    Prodigy 230 points

    Sorry I didn't mean to click on "This resolved my issue".

    That is correct, TMS570LS3137 HDK is master and I am not observing any signals on nCS and CLK, but in interrupt mode only: in polling mode, I observed signals on nCS, CLK and SOMI. The only change I made going from polling to interrupt mode was enabling RXINTENA on SPIINT0, changing spiReceiveData() to spiGetData(), and enabling VIM channels.

    SIMO is not set as functional, but this has not shown to be problematic in polling mode: it is not used anyway. I will now set it as functional and come back at you with the result.

    All other unused pins are already set as GIO.

  • 0 in reply to ChrisNo
    Prodigy 230 points

    Setting SIMO to functional had no effect.

  • 0 in reply to ChrisNo
    TI__Mastermind 21425 points

    Hello,

    The SPI clock is supplied by Master. spiReceiveData function is outputting dummy data and in that way Rx data is shifted because SPI CLK has been started with Tx. spiGetData only enables interrupt and sets g_spiPacket_t structure.

  • 0 in reply to Miro
    Prodigy 230 points

    Sorry again, I am not sure why I keep clicking on "This resolved my issue"... Bit tired probably.

    Anyway, I am not sure if I understand your reply. TMS570LS3137 HDK is master and in that way, it supplies the clock, just as I intend it to do.

    Let me be a bit clearer.

    The device I need to get data from via SPI specifies in its datasheet that it shall be the slave of the SPI communication, which is how things are set up to be. It also specifies that the SIMO (i.e. the line from TMS570LS3137 to it) shall not be used (and shall be grounded on the device's side). It specifies that only SOMI (i.e. the line from the device to TMS570LS3137) shall be used.

    I have successfully gotten data from the device using polling method, data that seem very well to match what the device is suppose to send. From there, I do not see how the data I observe on the SOMI line in polling mode could be dummy data, nor how you could conclude that from the information I gave you.

    After I successfully retrieved data using polling mode, what I need to do is retrieving this data using interrupt mode for project requirement purposes.

    Now, in polling mode, I observe that the nCS signal is being activated and that the CLK signal is being enabled, and I observe incoming data from the device on the SOMI line. In interrupt mode, I observe nothing on nCS and CLK, which is also why (that would seem logical) I observe nothing on the SOMI line.

    I noticed that spiGetData() enables interrupt and sets the g_spiPacket_t structure, and so my question is: what do I have to do, from the point where all my interrupts, vim etc are set up and spiGetData() called to have the TMS570LS3137activate the nCS and enable the CLK (which is what need to be done in order to have the device write data on the SOMI line)?

  • 0 in reply to ChrisNo
    TI__Mastermind 21425 points

    Hello,

    spiReceiveData outputs dummy data to SIMO (NOT SOMI) .

    spi->DAT1 = ((uint32)DataFormat << 24U) |
                        ((uint32)ChipSelect << 16U) |
                        (WDelay)            |
                        (Chip_Select_Hold)  |
                        (0x00000000U);

    A write to TXDATA field in SPI Transmit Register asserts nCS and starts the CLK. In that way Tx and Rx are performed. SPI by protocol is Full Duplex in nature, which means simultaneous TX and RX operations happen.

    spiGetData only enables interrupt and sets g_spiPacket_t structure.

    The nCS will not be asserted and CLK will not start until you initiate transfer from Master.

  • 0 in reply to Miro
    Prodigy 230 points

    Ok so this actually resolved my issue this time haha

    The straight answer is then: a write to spi->DAT1 structure is what initiates a transfer from the Master (activates nCS and enables CLK), in both polling or interrupt modes. I understand what you meant about the dummy data, which makes sense, I hadn't thought of it.

    Best regards,

    Christophe