• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 46 subscribers
  • Views 627 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.

ADS8330, AutoMode

Flamingo
Expert 2290 points
Other Parts Discussed in Thread: ADS8330, OMAP-L137

I am running the ADS8330 in AutoMode. I've got the input SPI traffic set up to drive the DMA on the OMAP-L137. I'm seeing timeouts sometimes and I've tracked the issue down to this: Sometimes when I write the CFR (0xe4bd), it is not "caught" by the ADS8330. That is, when I read the CFR back, sometimes I see 0x6bd (manual mode). My normal behavior is to alternate between the two modes. That is, when I'm not collecting data, I park the chip in Manual Mode and de-assert Start Convert. When I change to collection, I assert Start Convert and configure the part for AutoMode via the 0xe4bd command.

I've hooked up the scope to Start Convert, End Convert(INT in my case), Chip Select, SCLK, SOMI, and SIMO (not all at the same time). When I timeout the transfer, the command command went out well formed with good clocks. No other erratic behavior is present on any of the other lines. That is, I can't see any difference between the good transfers and the bad transfers except that the chip does not drive the EOC/INT signal low.

To help debug this, I added a read CFR after I write the CFR. Sometimes it reads back 4bd, sometimes it reads back 6bd.

The question I have is what could be happening that would prevent the WriteCFR command from working? (The scope has a long buffer, and I can see no other SPI-ADC traffic that is occurring before or after the failures.)

The frequency of the failure is different from board to board.

  • 0
    TI__Guru**** 181021 points

    Hi Flamingo,

    Could you possibly send me your screen capture showing the command sequence?  This almost sounds like a communication problem.

  • 0 in reply to Tom Hendrick
    Expert 2290 points

    0741.tek00000.tif

    4743.tek00001.tif

    The first image is one that worked. You can probably see how the full buffer displayed at the top of the display shows the continuing reads.

    The second image is one that didn't work. You can probably see how the full buffer at the top of the display shows no additional reads.

    The traces are: top(orchid) = chip select, next (green) = SOMI, next(cyan) = SCLK, next (yellow) = SIMO.

    The first command out is 0xe4bd (WriteCFR). The second is 0xc000 (ReadCFR). In both cases, the write is the same, but the read back is different. In the one that fails, the read back is 0x6bd.

    Thanks for any help. I can only capture 4 traces at a time, so I've included the ones that I thought you'd want to see. If you'd like to see INT, let me know which one to drop.

  • 0 in reply to Flamingo
    TI__Guru**** 181021 points

    Hi Flamingo,

    Take a look at Figure 5 in the data sheet (page 14).  The valid data edge into or out of the ADS8330 should be the falling SCLK.  You've got your OMAP sending data in so that data is valid on the rising SCLK and I believe the ADS8330 is just misinterpreting your command cycle.  Try setting up the L137 so that the clock dwells low with data changing on the rising SCLK and valid on the falling (both transmitter and receiver sections) and see if this eliminates the problems.

  • 0 in reply to Tom Hendrick
    Expert 2290 points

    Sorry for the delay, but I have been unable to verify the fix for this (although is seems correct). My board fried right after I got the answer and the next board won't yet boot...