• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 46 subscribers
  • Views 1037 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.

PGA900: Invalid SPI Device Response to Read Command from Master. 0x45

Kenneth Boria
Prodigy 10 points
Part Number: PGA900

I have implemented the SPI Protocol as described in section 7.3.15.3 of PGA900 data sheet SLDS209A.
Figure 38 "Response to SPI Read Commands is Available When the Next Command is Sent" shows that the first byte of the "Device Response to Read Command" is always 0x05.
Figure 38 does not show what is clocked from the slave during the first byte, "Read Command from Master".
This first byte is usually also 0x05, but is sometimes 0x45.

This response (0x45) seems to appear when the Master and the Slave get out of sync.
For instance, if you perform a SPI transfer to a device on the bus and then change to a diffent device (same bus, different chip select) you get a 0x45 from the PGA900 on the next SPI transfer.

Can someone tell me what this 0x45 actually means?
Was the command actually received correctly received by the salve?

I am using LabVIEW with NI USB-8452, but also tried it with C# and SiLabs CP2130.

Thanks for any help that you can offer.
Ken

  • 0
    TI__Mastermind 31655 points

    Hi Ken,

    I know this was answered for you in email, but I am just posting the reply here so it is available for others who might encounter the same problem:

    According to the design Bit 23 is a diagnostics bit that is getting set if the device didn’t see 24bits clocked in during the NCS low time period… So it’s pretty much a bit frame error check.

    I think your setup might be too fast that you are pulling the NCS pin high at the end of the frame before you can allow the last bit to be clocked in… Or, it could be that you are already clocking in the first bit before you had the chance to pull NCS low at the beginning of the frame…

    Either way what the status bit is trying to say is that between NCS falling and NCS rising he didn’t see 24bits, so he’s complaining about it.

    So it seems like there is nothing wrong with the device, however, you do want to get this fixed, because the design also says that if this error is detected, the bit that didn’t get shifted in properly will be assumed 0…. So if you see a 0x45 that means your last SPI data was shifted in wrong.

    Regards,