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]

Fabrice included an example CRC function, but it isn't practical. The message to be summed has to be converted from a 32-bit integer to one-bit-per-byte, and then the resulting checksum has to be packed back from bytes into bits. I think that code was derived from the code on this site:

http://www.ghsi.de/pages/subpages/Online%20CRC%20Calculation/

If you want to learn about CRCs you're better off reading:

http://www.ross.net/crc/download/crc_v3.txt

These are the ones that helped me to get a reliable CRC function for the L9663 chip and for the PSI5 Devices:

http://www.zorc.breitbandkatze.de/crc.html

http://www.zorc.breitbandkatze.de/crctester.c

Here's what I wrote for the ST L9663 SPI transfers. Note that the value to be summed has to be LEFT justified in the passed-in integer for this to work:

/* CRC parameters.
 *
 * Augmented to Direct Initialisation calculations:
 * CRC tester v1.1 written on 13/01/2003 by Sven Reifegerste (zorc/reflex)
 * -----------------------------------------------------------------------
 * 
 * Parameters:
 * 
 *  polynom             :  0x3
 *  order               :  3
 *  crcinit             :  0x2 direct, 0x7 nondirect
 *  crcxor              :  0x0
 */
 
#define CRC_ORDER	3		/* Bits in CRC. */
#define CRC_POLYNOM	0x3		/* 1011 without top bit. */
#define CRC_DIRECT_INIT	0x02		/* Augmented "7" is "2" direct. */
#define CRC_CRCXOR	0
#define CRC_CRCMASK	(((((unsigned long)1 << (CRC_ORDER - 1)) - 1) << 1) | 1)
#define CRC_CRCHIGHBIT	((unsigned long)1 << (CRC_ORDER - 1))
 
/* Big-endian (non reflected) only at the moment. Message must be left justified. */
 
unsigned long l9663_crc_3(unsigned long msg, unsigned long bitlen)
{
	// fast bit by bit algorithm without augmented zero bytes.
	// does not use lookup table, suited for polynom orders between 1...32.
 
	unsigned long c, bit;
	unsigned long crc = CRC_DIRECT_INIT;
 
	c = msg;
 
	while (bitlen-- > 0) {
		bit = crc & CRC_CRCHIGHBIT;
		crc <<= 1;
		if (c & 0x80000000) bit ^= CRC_CRCHIGHBIT;
		if (bit) crc ^= CRC_POLYNOM;
		c <<= 1;
	}
 
	crc ^= CRC_CRCXOR;
	crc &= CRC_CRCMASK;
 
	return(crc);
}
 
#define L9663_SPI_COMMAND_LEN		(1 + 31 - 5)
#define L9663_SPI_COMMAND_CRC_LEN	(3)
#define L9663_SPI_COMMAND_LSHIFT	(31 - 31)
 
/* Sum the command without the CRC field. */
uint32_t l9663_crc_3_gen(uint32_t a_nData)
{
	return l9663_crc_3(a_nData << L9663_SPI_COMMAND_LSHIFT,
		L9663_SPI_COMMAND_LEN);
}

The above returns the CRC bits that are then added in the correct place in the SPI message that is to be sent.

There's also an "l9883_crc_3_check()" function that is used to check the CRC returned from the L9663 - which is of course a bit different.

Then there has to be a similar-but-different one to generate the standard PSI5 CRC. It is different to the above as the bits are processed "least significant bit first" where the above is the other way around. Then the CRC bits have to be end-around swapped as well.

Tom

[FRoub]

Hi Tom,

Thanks for the CRC calculation ! It work easier with your method !

I have now the following problem :

I write the following trame on the MOSI line and receive the following trame on the MISO : (those trames are given by pasquale from ST with the CRC calculation)

SR1 MOSI: 0x04 0x00 0x00 0x08

MISO: 0x1C 0x20 0x10 0x07 SR1[9] over voltage on VAS MISO[28] RSTB =1always on reset

SR2 MOSI: 0x05 0x00 0x00 0x00

MISO: 0x1C 0x28 0x08 0x0A MISO[28] RSTB =1 always on reset

SR3 MOSI: 0x06 0x00 0x00 0x18

MISO: 0x1C 0x31 0x00 0x0A SR3[0] reset occured MISO[28] RSTB =1 ialways on reset

Does anyone know why my RSTB bit is always set ?

I set the RESETN pin

It's only a prototype so I try to put the frequency to 100KHz but it still don't work.

I try to connect my sensor to the PSI5 first line to see if it work better but no.

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 100nF capacitor between the pin and GND

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

VASSUP = 0V (Charge pump off)

VAS = 7.6V (Using an external regulated voltage)

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

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.

Thanks you in advance for the answer.

Fabrice

[TEvan.3]

> Does anyone know why my RSTB bit is always set ?

The manual says the RSTB bit is cleared by "any valid SPI communication". So that might mean your SPI frames aren't valid.

You really need to see the SPIE, FSR1 and FSR2 bits, but they aren't transmitted until you've sent a command that successfully disables "Address Multiplexing Mode". You can't do that until you can send a proper SPI command, and it looks like you can't at the moment.

I suggest you construct commands to read SR1, SR2 and SR3 and then decode the results. That should tell you what error bits are set in those registers. You can READ registers with invalid SPI commands - you just can't WRITE them.

I suggest you do what I did. Send all possible EIGHT variants of every command you send. I mean send the command with the CRC set to 0, 1, 2, 3, 4, 5, 6 and 7. One of them has to be "correct" because the chip will actually obey the command and won't complain.

Tom

[FRoub]

Hi Tom,

Thanks for your answer.

The RSTB bit is still set with every spi communication but I can write in every Register and it work.

For exemple I have change:

GCR1[14] DIS_ADD_MUX -->address multiplexing disabled.

GCR1[0] VAS_SEL --> 7.6V and I have mesure the voltage on the VAS pin it change from 5.3V to 7.6V

CHCNT[10] PVAS_EN --> disabled and then the voltage on the VAS pin is 0V.

When address multiplexing is disabled and i read register SR1there is no SPI Fault and SPIE FSR1 FSR3 are clear.

If it help when I read SR3 register then the RSTB bit is not set and SR3[0] is clear too.

I have already try to change the transceiver but whitout success too.

Let me know if you have a idea of what it could be it will be great

@Pasquale D'Argenio​ it would great too if you can tell what is wrong.

Thanks

Fabrice

[TEvan.3]

I've just looked at transactions my software makes with the L9663, and the RSTB bit remains set until I read SR3. This matches:

> If it help when I read SR3 register then the RSTB bit is not set and SR3[0] is clear too.

Actually, in my case the STATUS flags on the read of SR3 still has RSTB set (because the chip doesn't know I'm reading SR3 when it sends those Status bits), so the Status bits aren't cleared until the cycle AFTER SR3 is read.

SR3 has a "RST" bit which is "Cleared upon read". I'd guess the RSTB bit in the Status is connected directly to that bit in SR3. And so I'd expect the only way to clear it is to read SR3.

The Data Sheet says of the RSTB bit: "It is automatically cleared by any valid SPI communication.".

So the RST bit isn't doing what the Data Sheet says it should. That means the chip has a design fault as it doesn't match the Specification in the Data Sheet, or the Data Sheet is faulty as it doesn't document what the chip does. Given that SR3[RST] and RSTB are the same thing I'd say the Data Sheet is wrong here.

Ignore it. The chip does everything else just fine.

Tom

[FRoub]

Hi Tom,

Thanks for your answer. I start again with this communication between the L9663 transceiver and an angular position sensor from AMS. Do you have personnaly a exemple of trames / communication mode that you used the configure the transceiver to communicate with a sensor ? It will be very helpful because I'm a little bit lost.

My e-mail is fabrice.roubaty@edu.hefr.ch if you have something for me.

Thanks in advance

Fabrice

[TEvan.3]

You can't talk to an unprogrammed AMS chip with the L9663. Give up now if that's what you're trying to do.

I assume you're looking at something like the AMS AS5172A / AS5172B?

It won't work until it is programmed. There are standard ways to do that with PSI5, and the L9663 supports those ways very well.

The AMS doesn't do it that way. It uses a non-standard "UART-over-PSI5" method, which bizarrely modulates the voltage at 38,400 baud downstream, and the current at 38,400 baud upstream. There's no way the L9663 can support that.

It would have to be programmed in a special adapter, connected to a serial port, usually on a PC, and running at 38400 baud. Once programmed you could receive data from it with a L9663. These things are meant to be programmed by the thousand (or more) using a special rig on the production line of a product.

AMS detail this programming board in the board User Guide, as a "AS5172 PSI5 Programming Board". If you have one of these you can program the chip, and then talk to it with the L9663.

All you have to do in that case is to configure a few registers in the L9663 and then preferably have it generate interrupts when the data is ready. Then you read the data back. This is all pretty obvious from reading the L9663 Data Sheet. The hard part is you have to write a lot of support functions to generate and check all the CRCs, the Parity (GCR and other registers) and then functions to read and write specific registers over your SPI controller.

"Frames and Mode" is a matter of configuring the L9663 with the same number of bits (10 or 16), the high or low bit rate and whether it is using Parity or CRC. When they're matched the L9663 receives the data and makes it available for reading over SPI.

As for being "lost", I'd recommend getting the PSI5 Standard Documents and then reading them all the way through a few times. Then do the same with the L9663 manual. Keep reading it until it starts making sense. There aren't any shortcuts unless you can get someone to write the code for you targeted to your specific CPU, OS and SPI peripherals.

Tom

[Salvatore CANNAVACCIUOLO]

​ RSTB bit is cleared after a read access on SR3 register, in case, of course, the IC is no more RST.

This will be clarified in the next revision of the datasheet, coming soon.

Tnx a lot for the flag!

Salvatore Cannavacciuolo

[FRoub]

Hi Tom,

Thanks again for your time. Yes I'm working with the AS5172B.

I've found somebody who has programmed my sensor like that :

A20CRC-500/1H

A: asynchronous

20: databits

CRC: Error detection

500: cycle time in us

1: number of timeslop per cycle

H: bit rate189kBps

I've configure my L9663 like that before end of prograaming

GCR1 [14]:DIS_ADD_MUX -->address multiplexing disabled. [0]VAS_SEL --> 7.6V and I have mesure the voltage on the VAS pin it change from 5.3V to 7.6V

CHCNT [1]SYNC pulse disabled [0]PSI1_EN ---> interfaceON

CH1_CR1 [12] DOUT1 as interrupt output [6...4] 1 time slot [6...4] BR1 189kb/s [0] SYNC1_EN 0 Asynchronous mode

The rest is filled with default value

Then a make a end of programming with value 0x1111

Then page 86 Sensor data reading

NO SID, payload 20 bits i wrote 0xC8000014 on the mosi line but the miso line receive nothing.

After that the status register MISO lines are like that :

SR3 : 0x0C310044

SR2 : 0x0C280801

SR1 : 0x0C208002

Can you have a look and tell me what could be wrong ? You seem to have a lot of experience with psi5.

Thanks in advance

Fabrice

[TEvan.3]

I've never used Asynchronous mode. It should be simpler than Synchronous though.

First thing to do is to put an oscilloscope on the PAI5 bus and see if the AS5172B is transmitting anything. Then decode a packet manually (by measuring the bits from the oscilloscope) and see if it is sending what you expect, and what you have programmed the L9663 to receive.

> i wrote 0xC8000014 on the mosi line but the miso line receive nothing.

You're sending "0xC8000014"? That decodes as "Sensor Data", "Channel 1", "Timeslot 1", "Low Word", and then a CRC. The L9663 should be responding with six Status Bits, a "1", the Channel Bit (you sent), a "0", 20 bits of Sensor Data and then the CRC. You're using Channel 1 and not Channel 0? Are you sure?

Check those signals with an oscilloscope. It shouldn't be possible to get "nothing" in an SPI transfer. The L9663 should do something.

I think your SPI Transfer isn't working.

Tom