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?

[FRoub]

I've tried to send something with both channels (0 & 1) also the following trames on the mosi line : (0x88000014 & 0xC8000010) but I still have nothing on the miso line.

I have tried to mesure the voltage and the current on the PSI5 line 1 with an oscilloscope and a current probe.

I have a signal like on the figure 17 page 32 at 7.8V but i see nothing with the current probe.

When I compile my register on the transceiver the current of the transceiver goes from 27mA (default) to 50mA.

Did I take the right sensor data reading in the figure 29 page 86 , regarding the sensor configuration I mentionned in my last comment?

And is it true that the figure 28 is only to read the as5172 configuration (do you know what I need to write on the init_buf_id [29...27])?

Thanks in advance

Fabrice

[TEvan.3]

My previous answer had two points in it, but the most important one for this problem was the SECOND one. You have to get the SPI communication working first.

I assume that you are using the "Figure 27, Page 85" transfers to read and write the registers in the L9663 and they are working fine, yes? And that you can READ register values back with the right values and you're checking the CRCs. That proves your SPI comms is working.

The only difference between those frames (which I assume work) and the ones in Figure 29 is that the Figure 29 ones start "10xxxx" while the Figure 27 ones start "00xxxx". You should PROVE that with an oscilloscope. Make sure the Data, Clock and Chip Select lines are working. There's no use looking at anything else if this part isn't working.

It doesn't matter at all WHAT values you're sending on MOSI. The L9663 must reply with the STATUS signals on MISO and a "1" and the Channel Bit. That has to work.

Maybe you're doing something that is disabling the L9663 chip? Maybe you have a short between the PSI5 bus and some other signals, so that when you see " figure 17 page 32 at 7.8V" then the PSI5 bus coming on shorts to something else on the board and stops the SPI from working. To prove that, after writing whatever you wrote before trying the "Figure 29" ones, try reading some normal register back. If THAT doesn't work then you know that something you've done has stopped the chip from working. Maybe you're resetting the chip somehow? Maybe you've got the 7V doing something nasty and overloading something. You could try 5.3V instead and see if the L9663 keeps working then. Then find out what's wrong.

What do you mean "I compile my register on the transceiver"? That doesn't make any sense in English. I'm guessing you're writing to a register on the L9663 and then the power taken by that chip goes up. That should be when you write "PSI1_EN" to the "CHCNT" register. That turns the PSI5 bus on. The current then taken on the PSI5 bus should be whatever the Sensor draws (or is programmed to draw).

> the current of the transceiver goes from 27mA (default) to 50mA

Measured WHERE? On Vdd or on Vsup, VB, VAS and/or VASSUP? These are all different supplies. VAS should take nothing until you enabled it. The current on Vdd isn't specified anywhere.

WHEN THE SPI BUS IS WORKING (and not before) you can read returned values from the sensor just using the oscilloscope. Here's what my one looks like. I'm using 5 Volts, a 3 Volt Sync Pulse at 3 kHz with two frames of data being returned. You can see the frames easily here.

Tom

[FRoub]

Hi Tom,

I put VAS to 5.2V and disabled the adress multiplexing mode that I forget and it run well.

I'm checking the value of the register with a sniffer. (Saleae logic analyzer)

I'm not sure if i'm reading the value the right way.

I first send the following trames NO SID, payload 20 bits i wrote 0xC8000014 and I read 0x0F3E0006 on the miso line.

It correspond in one case : page 31 table 6 1F0 Databuffer empty and the lower 10 bits are filled with 0.

but I also see on page 32 : In both synchronous and asynchronous mode, when a valid data is read, the buffer empty

code 1F0 is written in the buffer.

The question is where are the data ? I mesure that with my oscillscope :

C1 is the voltage on the PSI-5 line

C2 is the current modulation on the PSI-5 line that I receive back

C3 is the interrupt line which say for a asynchronous operation : Asynchronous operation:

The interrupt pin is set to high when the number of received data since the last reading of

register is as large as the size of the receive buffer. The interrupt pin is set to low when all

the buffers are empty.

I try to read UDB1-1...4(because it think UDB1-1...4 is the fifo in asynchronous mode) but the data are read data are filled with 0 (default value of UDB1-1...4).

Can you help me with this problem ?

Thanks in advance

Fabrice

[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

[mahshid.ghaemi]

​Hello Fabrice,

As it is mentioned in data sheet, the contents of UDB1 determine the SYNC pulse length and it doesn't contains the sensor data. In asynchronous mode sensor data registers are working as a FIFO buffer with 6 stage.

So in order to read the sensor data in asynchronous mode you need to read the sensor data registers through SPI frame as shown in Figure 29 (page 86).

Please pay attention that SPI communication is out of frame, so you need to send 2 times the read SPI frame. the received MISO of second frame will be the sensor data you expect to read.

also consider the following procedure for reading sensor data:

Thanks,

Mahshid

[VChan.1]

Can't we use the same function by changing L9663_SPI_COMMAND_LSHIFT and L9663_SPI_COMMAND_LEN for the CRC check from the L9663?

[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);
}