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

TMS570LS1227: SPI communication issue while at low temperature at first read

Benjamin Zhou
Expert 4000 points
Part Number: TMS570LS1227


Hi Team,

  My customer reported an issue while using TMS570LS1227 to get the status of TPS65381A via SPI after SPI init at first time: 

  --At room temperature(25‘C), the SPI data register in TMS570LS1227 is same as scope. 

  --Low to below 0'C,  the SPI data register is not same as scope that the scope shown as 0x111b, but the data register is 0; this issue can be reproduced at 10'C;

  --For low temperature, execute SPI read command(no special read command), 

More details could be found in attached file. 2727.TMS570LS1227 SPI issue in low temperature.docxCould you kindly help to double check this issue and show which would cause this issue?  Expect for your reply, thanks.

Best Regards

Benjamin

   

  • 0
    TI__Guru**** 199096 points

    Hello Benjamin,

    You mean the data on SPI bus is correct, but the data in SPIBUF is wrong?

    Do you use the interrupt mode or polling mode to read the data? Is there any other SPI operation just before reading TPS status register. Do you see the overwritten error in SPI flag register? If receive full interrupt flag is set when you read the data from SPIBUF?

    The code should like this:

    spiREG2->DAT1 = 0x04FE0000 | command; //the command = 11 for your case 
    while((spiREG2->FLG & 0x100)!=0x100); //make the data has been copied to SPIBUF
    value = (spiREG2->BUF) & 0xFF;

    This is the sequence when data is shifted into the RXSHIFT register:

    1. If both SPIBUF and RXBUF are empty, the received data in RX shift register is directly copied into SPIBUF and the receive interrupt (if enabled) is generated. The RXEMPTY flag in SPIBUF is cleared at the same time.

    2. If SPIBUF is already full at the end of receive completion, the RX shift register contents is copied to RXBUF. The receive complete interrupt line remains high.

    3. If SPIBUF is read by the CPU and if RXBUF is full, then the contents of RXBUF are copied to SPIBUF as soon as SPIBUF is read. RXEMPTY flag remains cleared, indicating that SPIBUF is still full.

    4. If both SPIBUF and RXBUF are full, then RXBUF will be overwritten and the RXOVR interrupt flag is set and an interrupt is generated, if enabled.

  • 0 in reply to QJ Wang
    TI__Expert 4000 points
    Hi QJ,
    You mean the data on SPI bus is correct, but the data in SPIBUF is wrong?
    Benjamin； Yes, the waveform of SPI is correct, but the data in SPIBUF is not correct.

    Do you use the interrupt mode or polling mode to read the data? Is there any other SPI operation just before reading TPS status register. Do you see the overwritten error in SPI flag register? If receive full interrupt flag is set when you read the data from SPIBUF?
    Benjamin: Using the Polling mode; for this issue, it only happened at the first time read TPS65381A status after init, and no other SPI operation.
    meanwhile, there is no error reported for the SPI.

    Is there any special consideration for the low temperature SPI communication? Expect for your reply, thanks.

    Best Regards
    Benjamin
  • 0 in reply to Benjamin Zhou
    TI__Expert 4000 points

    Hi QJ,

     Customer used the “Polling Mode” for the SPI communication, and there is no any other SPI operation before reading the TPS65381 status register and there is no SPI error from the SPI registers; and during customer usage, while the full interrupt flag is set, then SPI read data from SPIBUF.

     Any suggestions for this question?  

    Best Regards

    Benjamin

  • 0 in reply to Benjamin Zhou
    TI__Guru**** 199096 points
    Hi Ben,

    The MCU acts as SPI master. The command of reading data is transmitted to TPS successfully, and SPI clock is correct, CS signal is correct, this means that the SPI module is functioning well.

    Do you have their schematics, and the code of reading data from TPS?
  • 0 in reply to QJ Wang
    TI__Guru**** 199096 points
    Hello Ben,

    Can you ask your customer to check the core power supply (1.2V), and PLL clock using ECLK test mode?

    If the SPI interrupt is enabled, can they get the interrupt triggered? Is this issue happened to only one board or couple boards? Is the board powered cycle or reset at low temperature?