I am using the Analog Devices EVAL-ADE9430 Evaluation board for testing one of their devices. The Evaluation board uses the NUCLEO-144 STM32F413ZH processor. I am using the Keil uVision development setup to run and debug code. I am specifically concentrating on the SPI Bus Driver and the timing. I have no previous experience with STM Devices and how the SPI transfers happen in the processor.
While walking through the code and following it on my scope to see the SPI Bus timing I am seeing something that does not make sense. The AFERead32BitBuffer() function is called when you read a 32-bit register from the SPI Device which is an Analog Devices ADE9430 Chip (see Below).
- The code calls HAL_SPI_Transmit() with the number of bytes it needs to transmit (see line 9 below). In this case it is transmitting a two byte command header where bits [15:04] are the register address and bits [3:0] is the R/W command, see example timing below.
- When I capture the actual timing, I would expect to see a 16Bit transfer of the command header. instead this is what I am seeing.
- Timing shows a 24 bit transfer which I believe should only be the 16 bit command header. Instead it appears the SPI bus is starting to immediately read the first 8-bits of the 32bit data riight after sending the command header.
- This is followed by the next three bytes of data to make up the 32 bits.
- Then finally the 16bit CRC is returned from the ADE9430 Chip.
- Next I wanted to only execute that single line so I added a breakpoint on this line 9 and single stepping over it while capturing the timing on the scope (see timing below). I would expect to only see two bytes transferred on the SPI Bus after its execution. Instead, I always see the timing for three bytes, even though line 9 clearly says transfer two bytes. This was the only line of code that was executed.
I am trying to understand what is causing the SPI Bus to generate the timing for this third byte when the code is only transmitting a 2 byte command header.
Thanks - mike
uint32_t AFERead32BitBuffer(uint16_t addr, uint16_t numSamples, uint32_t *pData)
{
int32_t status = SYS_STATUS_SUCCESS;
cmdBuffer[0] = (addr >> 4);
cmdBuffer[1] = ((addr & 0x0F) << 4) + 8;
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_14, GPIO_PIN_RESET);
status = HAL_SPI_Transmit(&hSPI, (uint8_t *)&cmdBuffer, 2, SPI_TIMEOUT);
/* FIXME : Handling SPI_Transmit error*/
if (status != 0)
{
status = HAL_SPI_Transmit(&hSPI, (uint8_t *)&cmdBuffer, 2, SPI_TIMEOUT);
}
if (status == 0)
{
status = HAL_SPI_Receive(&hSPI, (uint8_t *)&pData[0], 4 * numSamples, SPI_TIMEOUT);
}
HAL_GPIO_WritePin(GPIOD, GPIO_PIN_14, GPIO_PIN_SET);
SwapEndian32Bit(&pData[0], numSamples);
DEBUG_MSG("REG32RD,0x%x,0x%x", addr, pData[0]);
return status;
}
Hi,
Yes CRC is enabled.
- Open the afe_config.c file
- Go to line ~552, you should see the following statement disabling CRC
- hSPI.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
- Enable it CRC by changing it as follows
- hSPI.Init.CRCCalculation = SPI_CRCCALCULATION_ENABLE;
The SPI Clock is running at 6.25 MHz here is the contents of the hspi structure which I think has the SPI Configuration information. If not let me know what I can provide.
I took a picture of the same read with CRC is not enabled it looks to be what I would expect. The command from the processor to the ADE9430 is a 16bit wide command. Followed by four 8 bit transfers which make up the 32bit register data.
I just can't figure out how and why it is sending the 24bits as a group when CRC is enabled and the code indicates send 2 bytes.
Thanks - mike
