• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 514 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.

Original question:

PGA970: programming with FPGA

PGA970: Clarification on operating with/without the internal MCU

Steve B
Prodigy 10 points
Part Number: PGA970


In this post, PGA970: programming with FPGA, Scott says:

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/810845/pga970-programming-with-fpga

"You can read the demodulator data when the PGA970 microcontroller is in reset mode, but this is not recommended. The update rate of the demodulator output is faster than you can read the full 24 bits through the digital interface, so by the time you read the last byte of the demodulator data it will already have updated to the next sample. In order to avoid this problem you will have to write firmware so that the microcontroller reads the demodulator data and stores it temporarily before outputting the full 24bits from each sample."

But in this post

https://e2e.ti.com/support/sensors-group/sensors/f/sensors-forum/1083613/pga970-enabling-spi-without-internal-mcu

The question is specifically about operating the 970 without using the internal MCU and Scott makes no mention of this not being recommended.  

Wondering which is correct?  

If the 970 needs to have the internal MCU operating as the first post says what kinds of issues would result if the demodulator data is not read as fast as it's available?  - if one or multiple samples are missed?

Thanks

  • 0
    TI__Guru** 113765 points

    Hi Steve,

    Welcome to the E2E forum!  In the first post you referenced there were actually a couple of different questions:

    1. Writing waveform data to RAM while M0 is in Reset
    2. Whether the user should write a firmware routine

    The second post asked about communicating to the PGA970 using an external processor using SPI and how to enable SPI.  This second post is more recent than the first.

    So the questions seem similar, but not really addressing the same overall topics.  I think the bigger question is why would you use a part with an M0 core when you didn't intend on making use of the M0?

    That said, you can communicate to the PGA970 using the SPI digital interface while the M0 is in the Reset state.  Although not specifically stated, I believe Scott's comments regarding the reading of demodulator data was with respect to the EVM as that SPI interface communication is very slow.  Using an external processor outside of the EVM platform should be able to capture the data quickly enough even at the 128us update rate.

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 10 points

    Bob,

    Thanks for the quick reply!

    We're using the part with the M0 because it's what's available for integrated LVDT signal conditioners...  

    We want to keep things simple and just use the SPI interface, but we've been having issues and wanted to make sure we are not trying to use it in a way that wasn't intended or is known to not work well.

    Thanks,

    Steve

  • 0 in reply to Bob Benjamin
    Prodigy 10 points

    Seeing support comments like "Unfortunately we have limited support capability for this device.  It is rather complicated I understand, but unfortunately the code example is a little on the sparse side." don't make us eager to use the M0...

    But then there's this "The only way to get a reliable digital output from the demodulators is to use the communication buffer in firmware." from this post:

    PGA970: ADC and demodulator testing - Sensors forum - Sensors - TI E2E support forums

    We are not getting "reliable digital output from the demodulator" and are trying to understand if it's possible without using the M0.

    Thanks,

    Steve 

  • 0 in reply to Steve B
    TI__Guru** 113765 points

    Hi Steve,

    This is a complicated integration even without the M0.  If TI had unlimited resources we could provide better support.  However we are constrained as most likely you are as well. 

    As to the PGA970, the device was designed to use the M0 and is necessary for some functionality.  However, communication through the digital interface is possible while the M0 is in Reset.  The issue here is the timing and how it is determined when new data are available to be read out from the device.  The PGA970 has its own internal clock and the device reading the data has a different clock and they can drift apart.  If you attempt to read from the PGA970 during an update period you will get corrupted data.

    Scott's recommendation is to write code in such a way as to create a data buffer or internal FIFO.  This makes it easier to solve the synchronization issue, but complicates the data transfers as now you cannot read directly from the control and status registers.  The only communication that can take place with the M0 not in the Reset state is by using the COMBUF.

    So can you tell me more about the reliability issues you are seeing?  Can you tell me how you are determining when to read the conversion data?  Do you have any logic analyzer data to show the communication and data transfers for me to review?

    Best regards,

    Bob B

  • 0 in reply to Bob Benjamin
    Prodigy 10 points

    Bob,

    We are able to read the demodulator data and for part of an afternoon it looked correct but since then it's been down in the few thousand count range regardless of the input - not an occasional corrupted read because we're not synchronized with the PGA970 register update.   When we use the eval board with the same register settings it looks like it's working correctly although the data is read much less frequently.  We're reading at a 20ms rate and aren't doing anything to sync to the PGA970.  It appears the SPI interface is operating correctly and we can configure the output and it operates as expected.  

    Thanks,

    Steve

  • 0 in reply to Steve B
    TI__Guru** 113765 points

    Hi Steve,

    I'm not sure what else I can add here.  The only thing I can suggest is to connect up a logic analyzer to the SPI interface on the EVM and compare to your data transfers.

    Best regards,

    Bob B