Post Go back to editing

Weird data on MISO line, after reading out all 8 channels of the on ad7771 ADC

Category: Hardware
Product Number: AD7771

Hello everyone, i'm currently working with the ad777x-FMCZ devkit, and reading out the channels works fine.
what i'm having trouble with is noticing some weird behaviour on the MISO line, after finishing readiout out all 8 channels.

this is with reading the channels only through SPI. happens when i read the channels in 8 byte frames, or when i try to read all 32 bytes at once. 

I might be doing something wrong because for the life of me I cannot understand what is meant in this section of the data sheet.

tbh i think it's quite weirdly written

but in any case, here's what happens on the signal analyzer, first in 8 byte chunk readout.

lines are top to bottom: clock, mosi, miso, /cs,drdy,alert

  

as you can see, after the last 8 byte chunk is read out, after a while, and after the chip select line is pulled high, we have some weird bit of noise on the line

here is the same thing happening when i try to read out all 32 bytes at once.

i'm sending 0x80 command every 4 bytes, so looks like 0x80, 0x00, 0x00, 0x00, 0x80..... so as to not trigger a reset.

any idea why this might be happening?, the data that i'm getting seems to be good otherwise.

  • Reading out one more byte immediatly after finishing seems to fix the issue, but i'm not sure why, since i'm readying out 32 bytes.

  • Hi  ,

     will look into this and get back to you.

    Thanks,
    Francis

  • Hi  ,

    To clarify the datasheet section below, 64 is chosen to cite examples that reading the data must be in multiples of 8 bits. Please refer to the snapshot below.

    I might be doing something wrong because for the life of me I cannot understand what is meant in this section of the data sheet.

    tbh i think it's quite weirdly written

    When you mentioned reading out one more byte fixed the issue, is there any intelligible data found in the last byte or is it random?

    When the CS is pulled up, the SDO pin enters tri-state. What digital controller and software are you using?

     Thanks,
    Janine

  • Ah, alright, so reading out 64 bytes at a time is completely alright. 

    Anyway, i'm using an nrf5340, and the zephyr driver implementation of the SPI.
    The data in the last byte is always the same 


    reading out one byte it's 0xFF, which coincides with the datasheet, that if you read out all 8 channels, the next read then starts from the last channel right, so that looks correct ?

    but anyway, here's the full readout, and you can see that the data line stays low after the second 1 byte readout.
    Side note, after further testing, this seems to just push the issue down the line, and it seems to be happening in low power mode only ?


    here's the readout at 2khz odr, in high resolution mode,  
    while at the same data rate but in low power pode, we have the glitch.

    But in high power mode the alert pin is set....
    reading out the error registers, i get the internal_register_crc error bit set, and that only happens after the power mode.
    but the power mode is set correctly, according to the odr...

  • Hey, do you need more info on this? I don't think my question was fully answered.

  • Hi  ,

    Apologies for the delayed response.

    1. On the noise seen at the MISO line, there is high low in the original thread, whereas it is continuously high in your comment, could you please clarify the difference here?

    2. Regarding the power mode, the installed oscillator is 8.192MHz, whereas low power mode has a limitation of 4.096MHz. Do you wish to operate using high or low power mode?

    3. Could you please clarify what you mean by it only happens after the power mode?

    reading out the error registers, i get the internal_register_crc error bit set, and that only happens after the power mode.

    Thanks,
    Janine

  • regarding point 1. I'm not showing the noise in any of the screenshots of the second comment. My bad if it's not clear:
    -First screenshot shows what is read out if you read 1 more byte after reading the full 32bytes. So that's not noise, it's actually the starting byte of channel 7, which seems correct.
    -The second screenshot shows the full readout, with the data line staying low, after reading out 33 (32 + 1 extra ) bytes. 
    -The third screenshot shows no weird noise on the data line, but the alert pin being set to high, this only happens in high power mode. 
    point 2: I would probably operate in low power mode, but does the mhz limitation have any effect on anything else but the data rate? so with the same decimation rate, i would get different output data rates depending on the power mode. But i think I account for this. 
    point 3: What I meant by that, is that the alert pin gets set only after changing the power mode to high power mode. I don't understand why, since according to the ODR, it's a good transition to HIGH power mode.

  • Hey, anything to be added here? my last answer is just clarification, the problem still persists. 

  • Hi  ,

    1. In the original post, there was high/low in the SDO pin, but this could be the case when there is no clock provided and CS remains high. When you have pulled CS low and provided clock, you are getting the expected data which is the next channel, is that right? After 32 bytes, is channel 7 correct? Or should it be channel 0 after reading all 8 channels?
    2. The main clock is divided by 4 in high res and 8 in low power mode and you are correct in its effect to the data rate. However, the main clock is limited to 4.096 MHz for low power mode (the current crystal installed is 8.192MHz). Please refer to the datasheet snap below.

    1. Which CRC error is enabled when switching to high power mode?

    Thanks,
    Janine

  • 1. Yes, according to the data sheet, if you try reading out one more channel after all 8 have been read out, then you just get the last channel again. 
    2.Does that mean that when using the eval board, going into low power mode is "undefined" because on that board there already is a 8Mhz cristal?
    Should we then when creating the board plan on using only low power mode and install a 4mhz crystal 
    3. I'm pretty sure it was the MEMMAP_CRC_ERR . Now i understand if this would happen if i did something incorrect, but the mode switch happens, so i don't know why that crc error is set. 

Before You Switch


Switching languages will make ADI Explorer unavailable. Resume your session by switching back to English and reopening ADI Explorer.