• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1707 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS570LC4357: Incorrect data received in MIBSPI slave

Alain Felici
Intellectual 320 points
Part Number: TMS570LC4357

Hello, 

We have two boards, one with a TMS570LC4357 in SLAVE MibSPI mode. They are linked with a SPI bus, (One clock, one SIMO, one CS). 

The data arrives on TG2 because CS1 is activated.

The master board send always the same pattern (1, 2, 3, ... 22) at 1.25 MHz every 1 ms. 

When we power on the slave board, if the first reception coming from the master is correct, every thing will be OK till the power off. If the first reception is not correct (i.e. data not equal the the sent message), everything goes wrong till power off or CS1 put to ground/+5V manually.

If the clock wire is manually switched off/on, the reception will be corrupted as described above.  

Verification of the TG2 (0XFF0C0200) received data is done in CCS7 in memory browser. 

HCG project :

8357.hcg.zip

Regards,

Alain.

  • 0
    TI__Guru 59540 points
    Hello Alain,

    If CS1 is held asserted over the entire period of transmission (CSHOLD=1), then the slave has no reference for the start of the data byte so it will simply clock the next x bits in as the data. There needs to be some synchronization between the master and slave to indicate when the slave is powered and the master is powered so that transmission can begin effectively. One such mechanism would be to use the nENA pin of the slave to indicate the slave is ready and then the master could send at will. If you don't want to use the slave nENA feature, you could disable CS HOLD which would effectively use the CS signal to mark the start and end of the data within a single SPI transmit.

    Also, hopefully your reference to putting CS1 to grnd and +5V manually is a type. The IO on Hercules is 3.3V and is not 5V tolerant. the Absolute maximum voltages on all pins except ADC related pins is 4.6V. Voltages above that could cause damage to the device.
  • 0 in reply to Chuck Davenport
    Intellectual 320 points

    Hello Chuck,

    Thanks for your answer, with our configuration we cannot put a wire for ENA and are typically in the case of three pin mode explain in $28.2.5.1 of Ref Man.

    Otherwise we have more interrogations following our investigation : 

    1/ Can you explain us what is the meaning of CNSR of the multi buffer ram transmit data register, is it linked to SCS PIN?

    2/ We have understood that SCS[0-3] is used to select the TG (0000 -> TG0, 0001 -> TG1,...) but what is the purpose of SCS 4 and 5?

    3/ We need to know how the RX buffer is managed, it is written in the Ref Man that "the Sequencer request the multi buffer control logic to write the received data to the respective RX RAM location".  What is the meaning of "respective RX RAM location" :

    - The next location of the previous received data

    - or  The first location of received empty buffer

    We have try to change of MibSPI3 to MibSPI1 to check the hardware, it's the same results.

    Regards,

    Alain,

  • 0 in reply to Chuck Davenport
    Intellectual 320 points

    Hello Chuck,

    We have made some new try with MibSPI3 : 

    1/ With ENA, CS HOLD, CS hold FC active and receive on TG2 --> Same results

    2/ With ENA, CS HOLD, CS hold FC inactive and receive on TG0 --> No reception

    3/ With ENA, CS HOLD inactive and CS hold FC active and receive on TG0 --> No reception 

    Attached HCG of case 3: 

    1220.hcg.zip

    Regards,

    Alain

  • 0 in reply to Alain Felici
    TI__Mastermind 23137 points
    Hi Chuck,

    Further to Alain's inputs, here is some more data. The SPI is used in 4-pin mode with chip select. There are references above to 3-pin mode, but that's because SOMI is not used as the sensor (SPI master) does not need any input from the Hercules MCU.

    I had also spotted at the bottom of the TRM page 1469 the multi-buffer mode is supported on TG0 only, but I just realized this was for the 3-pin and the 4-pin with ENA modes only, so this information is not relevant. This explains why Alain tried TG0 today.

    As you suggested above, we are pursuing the option of disabling CS HOLD in a 4-pin configuration but Alain could not get the configuration right. Could you please review his settings? As an alternative, we could use the SPIENA signal instead of CS in a 4-wire configuration (with actually 3 wires as SOMI is not used) if you think this could help.

    Thanks,
    François.
  • 0 in reply to Francois Charlot
    TI__Guru 59540 points
    Francois, Alain:

    I think we need to see the data stream on a oscilloscope to understand really what is happening. i.e., do we know if the data being transmitted by the master is truly as expected? I am also curious if there were any errors flagged during the process of receiving the incorrect data. i.e., parity errors, bit errors, framing errors, etc.

    Finally, for the incorrect data that is received, can the errors be characterized as shifted, inverted, missing bits, flipped bits, etc? In general can we diagnose anything by the nature of the data that is received or does it appear that the erroneous data is random?
  • 0 in reply to Chuck Davenport
    Intellectual 320 points

    Hello Chuck, Francois,

    So to resume, we are in 3 wires (CLK,MOSI,MISO) in MibSPI (3) slave mode with CS1 plug into 3.3V all other CS in Ground, so TG2 selected.

    We send 42 words of 16 bits : 

    - First and second are header 0xFF80 and 0xFF00

    - Third one is a counter from 0x0000 to 0xFFFF

    - 4th to 40th is an incremental from 0x0003 to 0x0027

    - 41st and 42nd are an CRC32 so variable

    If the TI board is started after the sender everything is working OK and we can see this in the memory viewer:

     

    As you can see, everything is consistent with sent data (counter value is 0X798D). We have got also an oscilloscope picture showing clock (yellow) and MOSI (blue). We can see the 0xFF80 word. 

    After restart of the sender, oscilloscope show the same figure but in the memory viewer we can see:

      

    You can see for example that the fist word is 0xFFC0 instead of 0xFF80, and just after we have 0x8002 instead of 0x0002 and 0x0002 instead of 0x0003, and so on. 

    Thanks for you help 

    Alain

  • 0 in reply to Alain Felici
    TI__Guru 59540 points
    Hello Alain,

    As I suspected, this appears to be a combination of shifting and maybe some dropped bits if you look at this as a continuous unsynchronized stream of data. By starting the slave after the master is already transmitting, how is the slave to synchronize to the correct packet start and stop since it is a simply synchronous to the SPICLK relative to shifting in bits? When you start the slave first, it is setup and waiting for the messages but when the slave starts after the master, it starts shifting in bits as soon as it is configured regardless of where it is in the data stream. The first bit it sees is bit0 , next bit1, etc. There is then no way to frame up the data since CS1 is tied low always. I see that there is a "pause" or gap in the clk between data bytes, but the SPI doesn't care about the length of the pulse (for the most part) as it only uses the edges to synch to and shift data in and out.

    There are two ways to correct this behavior. One is always guarantee the slave is up and ready before the master starts clocking data out. Two is to have the master control CS1 so that it de-asserts it between packets. This will probably result in a framing error for the last byte of the first packet as well as still corrupt data int he first packet but will allow the slave to synchronize with the master on the second packet.