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.

LMP90079: LMP90079 wrong channel number and data problem

Part Number: LMP90079

Dear Sir Madam,

We use LMP90079 with 4 channels input and Continuous Scan Mode with burnout detection and CRC.

Due to our circuit we check new sample data with ADC_DONE register control. When I see new data immediately with SPI interrupt we ask 5 byte from  SEDIAG FLAGS to SPI_CRC_DAT in order to get samples

We see that most of the cases (%10 of samples) channel data and channel numbers are wrong; for example

for Ch1 data is nearly 8000 and Ch2 and 12000. Some times I get 12000 for CH1 and 8000 for CH2 with correct CRC. That is  Checksum of 5 byte and CRC correct althoug the data is wrong. So what can be the problem.

Best regards. 

  • Hi Emre,

    I apologize for the delay, I didn't have a chance to look at this today. I'll do my best to get back to you tomorrow! 

  • Thanks for your response.

    I will wait for your help.

  • Hi Emre,

    More than likely there is an issue with the SPI timing or post processing. Either a byte is being dropped (i.e.) SPI is not reading it quickly enough before the next interrupt is issued resulting in a truncated sample. This could then be loaded in your software piece-wise until the error is noticed.

    For the other samples that are before/after the incorrect sample, do you notice anything else that is incorrect?

    Is there any other pattern that you see? Is it every 1 out of every 10 samples that is incorrect, or 90 correct and then 10 incorrect?  

    Can you please post a schematic and SPI communication scope shots showing the bit transaction to verify that data is being clocked out before the next interrupt? 

     

  • The error is random. That is if we choose 214 SPS for 4 channels nearly %15-20 of samples are belongs to next channel. but if we decrease to 53 SPS %2-3 of samples are incorrect ( but there are still wrong samples).

    My SPI is in 25kHz (40usn for one bit)

    so for DRDYB check and data read after that  DRDYB check, I need at least 6 byte with some time delays -> 40usn* 8 bit*6 byte => nearly 2 msn to read one data and check CRC in ideal case.

    for 214 SPS samples DRDYB is refreshed in 4 msn and so we decrease the data rate to 53 to see its effects that is 18msn DRDYB refresh period.

    I clear the DRDYB after CRC is read. I also try to read the next register CH_STS to check data valid.

    I did not undertand two things about the problem after your response.

    1- how CRC is correct with SENDIAG_FLAGS ,DOUT H, DOUT_L and Reserved byte control. I thing if we consider ch number changes, there must be CRC error. (if CRC is only calculates DOUT it may be possible.)

    2- what must be the minimum SPI speed. in order to operate in full 214 SPS correctly. 

    For your questions

    * For the other samples that are before/after the incorrect sample, do you notice anything else that is incorrect?

    Some times I get low count for example CH1: normal reading is 8000, I get irrelevant data like 150-200 some time. rather than different channel. But its rate %0.1 or less.

    * Can you please post a schematic and SPI communication scope shots showing the bit transaction to verify that data is being clocked out before the next interrupt?

    We did not use interrupt due to our opto-coupler isolation, we could not detect 7.2 usn period DRDYB signal, so we check ADC_DONE register to see if new data available. so we can't send you interrupt scope output.

  • Hi Emre,

    Since the number of errors decreases along with a decrease in the sampling frequency, more than likely there is an issue somewhere in the post processing. This could be in the form of not clocking data out fast enough, not finishing/exiting a loop properly, or a mis-alignment of the data. 

    Looking at section 8.6 Timing Requirements and Figure 1. Timing Diagram, of the datasheet: the maximum SPI speed is 10MHz, while the minimum is not specified. Probing the SPI clocks to ensure that they are always within spec may be difficult. However, checking to ensure that the SPI signal is being generated properly with minimal over & undershoot may be worthwhile. 

    Since CRC is being communicated with and the data is showing correct from the CRC, this makes me think the issue is in post-processing. 

    It is possible that there is a MSB shift occurring, where the MSB is being truncated for one reason or another. This is a good data point to know. 

  • Hi Alexander,

    You talk about post-processing, Exactly what is this?  Is there any document related with that?

    For the probelm: When I decrease SPS form 214 to 26 we did not see any errror in 25kHz SPI. So as you mentioned there is something related with timing. I will try to increase SPI clock much more by changing hardware and try 214 sample speed again and will share the results. 

    I will also chek the timings according to datasheet again.

  • Hi Emre,

    By post-processing, I mean processing that is happening after the measurement has been taken from the ADC. 

    The symptoms of your issue make me think that there is a "bottle-neck" in the data processing flow. A bottle-neck is a section of the data processing flow that is restricted. 

    Here is an example data processing flow: Data ready at ADC -> SPI communication -> MCU calculations -> MCU output

    I believe in one of these steps, the hardware is not moving quickly enough to process all of your data at higher data-rates. This line of thinking is reinforced by the fact that the system works correctly at low data rates. 

    In addition to tweaking the SPI timing, you may want to try simplifying your MCU calculations if they are time intensive, or if there is a delay or some sort.  

    Oftentimes when I see an issue like this, it is due to a new sample being ready before the last sample has finished going through the data processing flow.

  • When we increase the SPI speed to 200kHz from 25kHz with hardware modification, the accuracy in 52 SPS is excellent but above this SPS these problems still going. (Provious one excellent behabviour 26 SPS for 25kHZ)

    But as ww see that SPI speed some effects, I try to increase speed more, but I thing there are some other problems since altough I increase speed 8 times a little increase in performance. 

    I will check again 

    best regards

  • Hi Emre,

    Good to hear! You may want to look into the data processing routine as well. Please let me know how the debug goes.