LTC 4332 Remote Master does not respond on SPI write from Local master

Hi Shaun,

I'm sorry you're having issues with the LTC4332.    This part is being successfully used in many different customer applications.

One important note is that this part only supports clock frequencies up to 2 MHz, so your test at 3.2MHz would not be expected to work.  A 1.8MHz SCK should be supported; however, please realize that there is a maximum cable length for operation at this speed.   Table 2 in the data sheet indicates that the max cable length for 2 MHz is approximately 30m.  These lengths were confirmed in a lab environment using a CAT5E ethernet cable, but depending on the actual cable and application environment, the usable length may be slightly different.

Assuming that your application's cable length is under 30m, then I'd expect that the 1.8MHz SCK should operate.

You are correct that there is a heartbeat between the local and remote LTC4332 devices.  The local device is expecting a response from the remote device based on its heartbeat transmission and if its received the local device will pull nLink low.  Since you report that nLink is low and you can successfully talk to the local side's control interface, this suggests that its highly likely the RS-485 wiring is basically correct and the two parts are communicating at base level. 

There should be non-heartbeat traffic on the RS-485 bus when the local side SS pin is asserted.  Only one SS pin can be active at a time, this includes both nSS1-3 and nSSC.  Also when asserting nSS#, be sure to follow the timing constraints.  If there are issues with this, then the local LTC4332 will ignore the SPI traffic and not send it to the remote side. 

Eric

Hi Eric,

Thank you for the reply and time in understanding the issue I am having.

I may add here, I am using STM32l4+ MCU to communicate with this chip, if it matters and supply voltage is 3.3V

At the moment I am using 30 cm cable, so cable length constraint can be ruled out.

Please find attached timing diagram of SPI signals. MISO is initially HIGH when the program starts, with the first SPI transmit instruction, it goes low and stays low forever, until a reset is performed.

I am using SSI pin to access H3LIS200DLTR ID Register  (Transmit Reg address followed by receive data)

Also please find the SPI initialisation parameter. the baud rate is set to 1.8MHz with a pre-scaler of 64.

Not able to figure out what could be the issue. 

/* SPI3 init function */

__weak HAL_StatusTypeDef MX_SPI3_Init(SPI_HandleTypeDef* hspi)
{
HAL_StatusTypeDef ret = HAL_OK;

hspi->Instance = SPI3;
hspi->Init.Mode = SPI_MODE_MASTER;
hspi->Init.Direction = SPI_DIRECTION_2LINES;
hspi->Init.DataSize = SPI_DATASIZE_8BIT;
hspi->Init.CLKPolarity = SPI_POLARITY_LOW;
hspi->Init.CLKPhase = SPI_PHASE_1EDGE;
hspi->Init.NSS = SPI_NSS_SOFT;
hspi->Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_64;
hspi->Init.FirstBit = SPI_FIRSTBIT_MSB;
hspi->Init.TIMode = SPI_TIMODE_DISABLE;
hspi->Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
hspi->Init.CRCPolynomial = 7;
hspi->Init.CRCLength = SPI_CRC_LENGTH_DATASIZE;
hspi->Init.NSSPMode = SPI_NSS_PULSE_ENABLE;
if (HAL_SPI_Init(hspi) != HAL_OK)
{
ret = HAL_ERROR;
}

return ret;
}

Hi Eric,

Is there anything else you can suggest me to do to find the problem?

I wish to hear from anyone who has successfully used this chip as I having no luck.

I have also been trying to get support from Analog Devices support team, they have not been able to help me even after 25 days.

Looks like there are issues with this chip. I am concerned about having to throw away 50 boards fitted with this chip and also redesign with alternate chip.

Regards

Shaun

Hi Eric,

As suggested by you, there was a shorting of clock signals to ground. This was due to PCB assembly fault. After rectification, the signals are passing through as expected. Please close this case as of now.

Thank you for your timely support to guide me to find the fault.

Regards

Shaun