• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1495 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.

TM4C129EXL SPI Read Problem

Daniel Vamos
Genius 3950 points
Other Parts Discussed in Thread: ADS1262

Hello, 

I would like to communicate with ADS1262 using SPI. The code that I am using successfully works with TM4C123GXL but fails with 129EXL. To make sure that the SPI wiring is OK, here is the screenshot of a communication trial.

As you can see only the MISO channel fails, I mean I dont have any reply back from the ADS. (Stop Conversion command, Read Register , Write register, Read Register the above sequence.)

Any idea how to go on? Tried on two 129EXL boards but failed.

Pinout configuration: 

SPI CS: PD2 | SPI CLK: PD3 | SPI MOSI: PD1 | SPI MISO: PD0

PS.: I've also tried the SPI Looback TI RTOS SPI example and works flawlessly, the ADS works well with 123GXL. 

  • 0
    Guru 27665 points
    Your chip select looks wrong, I would not expect it to be de asserted between bytes to the device. I suspect the device is restarting the command parsing on every new chip select assertion and never completing a command. Typically besides enabling serial I/O the chip select acts to synchronize the external device.

    Robert
  • 0 in reply to Robert Adsett
    Genius 3950 points

    Dear Robert,

    Thank you for your reply. Regarding the chip select, it is controlled by RTOS. However I made some changes and CS is controlled by self. Here is the outcome:

    As you can see, the still dont have valid reply. (Interesting is the 123GXL uses the same CS timing and works fine.)

    I have disabled the CS control for every byte as you suggested. As you can see the reply is not what expected.

  • 0 in reply to Daniel Vamos
    Guru 27665 points
    Did you capture the timing for the '123 case?

    The first plot looks correct to me now, the second looks wrong, I would not expect it to work either since you do not de-assert cs between transactions.

    Something is pulling MISO low, the first thing I would do is find out what. Isolate the MISO line so that the device and the micro are not connected and make sure both have pull-ups and see which pulls it low. The micro should stay high and the device send out its response.

    Robert
  • 0 in reply to Robert Adsett
    Genius 3950 points

    The most recent outcome, when MISO is disconnected from the uC. I expect that the last read should be equal to the previous write.

    I am working on the pullups.

  • 0 in reply to Daniel Vamos
    Genius 3950 points
    The project that I've modified is TCP Echo example. Do you think that this project pinmux should affect on SPI? I have tested the ADS1263EVM with 129EXL but failed. I am going to modify the SPI loopback and coming back with the result.
  • 0 in reply to Daniel Vamos
    Guru 27665 points
    If your latest snapshot was from the device output and the input to the micro was pulled low I'd say that was a reasonable possibility.

    Certainly something is driving the micro's pin in that case. Since it appears to be happening on multiple boards I'd not place pin damage as my first suspect, although a short on the board is a possibility.

    Robert
  • 0 in reply to Robert Adsett
    Genius 3950 points
    Hey,
    I can't make it work. Tomorrow I am going to make a super simple example project and restart everything.
    Thank you for your support,

    BRB
  • 0 in reply to Daniel Vamos
    Genius 3950 points

    Hello.

    I made a super simple spi example, and here is the outcome.

    As you can see, I got a valid reply for my query, so the problem in on my code. I got only one question remains: Why does the MISO line is low after transaction. Rpullup is needed for SPI MOSI and MISO lines? I read many articles, sometimes using rpullup is recommended stimes not.

    What do you think? 

    Thank you for your support!

    12 MHz, 36 M Samples [9].zip

  • 0 in reply to Daniel Vamos
    Guru 27665 points
    For MISO a pull-up is definitely required. When CS is not asserted then there is nothing driving that line, it is floating. Worst case a CMOS latchup destroys your micro.

    It's arguable for MOSI since it is driven by the micro always. However, and this is a potentially large caveat, before the pin is programmed as an output it defaults to an input and is vulnerable. IMO, the risks of that condition, however temporary, outweigh the costs of a resistor most of the time. I take the position that all outputs should have a pull-up.

    Also check the errata, I don't know if the '129 got affected but there is a severe errata on the '123 I/O that requires extra protection.

    Robert
  • 0 in reply to Robert Adsett
    Genius 3950 points

    Dear Robert,

    It seems the SPI problem is solved.
    I made a few changes on SPI Loopback example and I can communicate with the device successfully, well the problem is SW related.

    Thank you for your advice and your support!