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.

TMS570 MibSPI receiving "shifted" 16 bit words

Other Parts Discussed in Thread: ADC128S022, HALCOGEN

I have configured MibSPI for master comms to an external ADC (8 channels, 12 bits), SPI Configuration is done in mode 1, frequency 400kHz, word size 16 bit. Format of the word: typical 8 bits output data with ADC channel address to read + 8 bit 0x00 to retreive ADC result).

On the test bench, the ADC is forced to 0V in all channels. So the answer on the MISO is consistenly 0xF000 for all channels. Frames check on a logic analyzer consistenly show 0xF000 shwoing the conversion done at the ADC. The edges are sharp and it really does not seem there could be a HW issue (I have set the freq real slow).

The problem is that when I look in the MultiBuffer Ram RXDATA, some times (let's say 70% of the transactions) I get a wrong value: 0x3800 or 0x7800. Instead of the 0xF000 seen on the scope. It really looks like as if the module is "shifting" right the RX word before storing it in MultiBuffer Ram RXDATA,

The ctrl part of the MultiBuffer RAM is showing a 0x000F which tells me no errors are detected. I have checked no loop-back mode is set. And honestly speaking I am quite lost at this point. Any hint on what to look for, or registers to check would be appreciated.

Regards,

  • Luis,

    You are saying that your ADC is 12 bit. How can you read from your ADC only 8bit of DATA?

    Will it be possible to get the part number for your external ADC so I can have a look?

  • Dear Jean-Marc,

    Thank you for your answer. Obviously I made a mistake in my original post and the transmission are 16 bits.

    The chip itself is: ADC128S022 from National Instruments. The ADC sits after a set of optocouplers which isolate the measurement zone from the TMS570. Thus  the data/clock lines arrive inverted to the uC. Therefor we have configured the SPI module to mode 1 in orther to be able to communicate to the ADC:

    Next I attach a scope printscreen, where you can see a 0xF000 answer from the adc arriving to the TMS (MISO line):

    This 0xF000 value corresponds to a measurement at the ADC at maximum voltage on that channel. The ADC outputs the 16bit word according to the datasheet: 4 0 bits + 12 bits to 1 (maximum voltage sampled) = 0x0FFF. After going through the optoisolation this is turned into 0xF000 which is what arrives to the TMS570. (What you see on the picture).

    This communication takes place periodically between TMS570 and the ADC: We have also discovered that some times (around 95% of the times). The TMS570 reads 0x3800 or 0x1800 instead of the 0xF000. The rest of the communications are correct (reading 0xF000 at the SW).

    And here is were we are stuck. The edges at the TMS570 pin (picture) are clean, but this percentatge of good-bad transactions is weird. By the way, the value read at the TMS570 when the previous picture was taken was 0x3800.

    As said before, any hint will be appreciated.

    Sorry for the poor explanation in the previous post.

    Best regards,

    Luis Vela

  • Luis,

    Thanks for the additional information. Unfortunately, the scope printscreen is not attached to your previous post.
    Can you send it again?

  • Luis,

    I forgot to ask you if you are using Halcogen to generate your SPI setup.
    If this is the case, can you also share your project so I can have a look to the code.

  • Luis,

    What do you mean by "mode 1"

    Hoe do you configure:
    Clock polarity =
    Clock phase   =

  • Hello Jean-Marc,

    I reattach here the scope printscreen. Hope it works this time.

    We are using a 3rd party HAL development (Not HalCoGen)

    Mode 1:

    Mode numbers

    The combinations of polarity and phases are often referred to as modes which are commonly numbered according to the following convention, with CPOL as the high order bit and CPHA as the low order bit:

    ModeCPOLCPHA
    0 0 0
    1 0 1
    2 1 0
    3 1 1

    IMPORTANT: However, the HW team has discovered that they have missed the polarization resistors: the uC pins where feeding directly the diodes at the optocouplers. This was resulting in lower levels for the signals and apparently it explains the malfunction of the peripheral. If this gets confirmed this issue will be closed from our side. I would please ask you to keep the thread open until de HW team confirms the bug was on the HW design.

    Thank you in any case for the fast response.

    Best regards,

    Luis

  • Luis,

    What is the status on your question?

    If your problem is understood, could you please mark this thread as verified answer so I can close it.

  • We have identified this as a HW problem when driving the optocouplers for the SPI bus.

    Aftr fixxing the HW design th comms are working.

    Thank you for your support