I am implementing a PTX105R circuit on a shared SPI data bus.
When ALONE The PTX105 is confirmed functional and working perfectly and communicating with the host.
When EVERYTHING ELSE is on the SPI bus, but PTX105 is removed, then everything else ALSO works perfectly.
BUT - The PTX105 will not share the SPI bus with the rest of hte system.
The problem seems to be that when NSS line is High (HIF1) per the datasheet I expect the MISO line should be high impedance per SPI standards. However, the PTX105 is pulling the line low with a fairly heavy resistance of about 40 ohms. This is enough to corrupt data exchanges from all other devices sharing the bus. I have confirmed this by cutting the single trace to the MISO pin on the PTX105.
The PTX105 should not pull MISO low when NSS is high.
From the datasheet:
3.7.5. SPIPTX105R implements a standard SPI interface supporting the SPI mode 0 (CPOL = 0, CPHA = 0), i.e. the clock must be low when data changes and data is captured at the leading clock edge after NSS is de-asserted. It uses 4 signal lines for communication: • Not-Slave-Select (NSS): Active low input to select the device. A communication is initiated by pulling NSS low. When NSS is high the data output MISO is disabled
Is this a known errata for the part?
Can you confirm my findings and suggest a work-around?
HI Sparky Steve,Thank you for posting your question online.Let me check on this and I will get back to you as soon as possible.Best Regards,OV_Renesas
Hi Sparky Steve,Apologies for the delay.Please send us an SPI log.Unfortunately, the PTX will not set MISO to high impedance, if NSS is high. A single buffer gate controlled by CS would enable high impedance for MISO.Best Regards,OV_Renesas
I have found that a series resistor also works, but agree that the "right" solution is a tristate gate.
Thanks for confirming that the pin isn't being released.
You asked for the SPI log, I am not sure i understand what you mean by that? I didn't capture any scope plots because it was such an obvious issue. I don't have an SPI analyser readily available.
ALSO - is there a chance this can be fixed in the chip firmware in the future? Or is the pin itself physically incapable of being set floating/input?
Hi Sparky Steve,Thank you for the reply and apologies for the delay.No need for SPI log. I asked for it because I thought there might be an issue, before I confirmed that it's the expected behavior. I can't tell if it would be changed. There is no plans as of now. Best Regards,OV_Renesas