L9663-1 PSI5 Transceiver not communicating through SPI

[ljuarez]

We want to use the L9663 PSI5 Transceiver to interface a sensor. A STM32 Discovery board is being used as the SPI master, in mode 1 (CPOL = 0, CPHA = 1). The SPI clock speed is set to 10MHz.

The module configuration is:

/* SPI1 parameter configuration*/

 hspi1.Instance = SPI1;

 hspi1.Init.Mode = SPI_MODE_MASTER;

 hspi1.Init.Direction = SPI_DIRECTION_2LINES;

 hspi1.Init.DataSize = SPI_DATASIZE_8BIT;

 hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;

 hspi1.Init.CLKPhase = SPI_PHASE_2EDGE;

 hspi1.Init.NSS = SPI_NSS_SOFT;

 hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_2;

 hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;

 hspi1.Init.TIMode = SPI_TIMODE_DISABLE;

 hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;

 hspi1.Init.CRCPolynomial = 11;

We are sending 32 bit frames to the device formatted as specified on the datasheet (Frame definition section, pages 84-85) .

However, the IC is not responding to any SPI commands, and the MISO line stays always high. We have verified that the SPI module of the STM32 board functions properly, by interfacing a MCP2515 SPI CAN controller successfully. i.e. getting an SPI response and activity on the MISO line.

We have also verified that the number of clock cycles for each SPI transaction is correct (32 clock cycles as specified on the datasheet, page 87).

The transceiver has been supplied with one of the configurations described in the documentation (page 15), with the following values (all within the operational range):

VB = 12V - Including a 75nF capacitor between the pin and GND

VDD = 5V - Including a 75nF capacitor between the pin and GND

VASSUP = 0V (Charge pump off)

VAS = 7.6V (Using an external regulated voltage)

Included a 75nF capacitor across the pins VINTD and DGND.

Since we are using the exposed pad TQFP32 package, the pad is soldered to a GND plane. All the grounds have been kept electrically shorted, as specified on the datasheet (page 11). The TM pin is also connected to GND.

We have also confirmed that the device is switched on, by measuring the output voltage on the VINTD pin, which is 3.3V when the device is enabled, consuming around 19mA when powered up.

The question:

Could someone please describe why the device is not communicating back on the MISO line?

[TEvan.3]

The manual isn't clear on this. It also says the sensor buffer is a FIFO in Asynchronous mode, but it really isn't. "FIFO" means "First In, First Out", and every other FIFO I've ever seen in the world lets you read the data from one location, and the data shifts down as you read it. What we have here is a half-FIFO. It is a FIFO from the chip's side. It pushes data in starting at the first slot, and the data pushes down. But you can't read it from the other end. It also can't "fill from one end while you're emptying it from the other end", which is the usual point of a FIFO.

With this one, the first SIX words push in from Slot 1. When it is full you get an interrupt. You then have to read it starting from Slot 6 going down to Slot 1. On the first read the FIFO "locks" (whatever that means). Only when all the buffers have been emptied does it "unlock" and start storing data again.

The above description sounds like there would be a "race condition" if things didn't happen in the right order, and sure enough, you had better read the Errata to see what can go wrong. It also tells you there that on the interrupt to read slots 6, 5, 4, 3, 2, 1, and then check the FIFO_LOCK bit. If that is still set you read Slot 1 again. If you write some test code you'll probably find that "failing to unlock" doesn't happen, but don't leave the code out. This sort of thing might only happen once an hour or once a day. But it would lock the whole thing up if you don't have the recovery code there.

It is worse than that. There are two channels, and so there are two FIFOs, and I'd expect to see two FIFO_LCK bits in the registers, one for each FIFO. But there's only one "FIFO_LOCK" (also called "FIFO_LCK") bit. So do BOTH FIFOs lock when you read one of them, or are there two internal FIFO_LCK bits that are OR-ed together and the register bit only shows if either is set? I have no idea. But the Errata implies that when one FIFO fills you had better read BOTH of them. Maybe that only matters if you have both channels running, or maybe it doesn't. If you are using both channels in Async mode you get two separate interrupts, but only one FIFO_LCK bit.

If you're using both channels you had better read both like it says in the Errata. If you're only using one then you'd better write some test code.

You might also get a "Buffer Empty Fault" when doing this, so be sure to check for that and to have recovery code for that as well.

I'm very glad I'm not using Async mode! Why are you - why not use Sync mode? That's simpler and is documented so you can write code to use it.

Tom

[TEvan.3]

#define L9663_SPI_RESPONSE_LEN (1 + 26 - 3)
#define L9663_SPI_RESPONSE_CRC_LEN (3)
#define L9663_SPI_RESPONSE_LSHIFT (31 - 26)
 
uint32_t
l9663_crc_3_check(uint32_t a_nData)
{
	return l9663_crc_3(a_nData << L9663_SPI_RESPONSE_LSHIFT,
		L9663_SPI_RESPONSE_LEN + L9663_SPI_RESPONSE_CRC_LEN);
}