2024-04-23 03:26 PM
Im currently working on a custom PCB with cc1120 as transceiver and stm32f446RET6 as MCU. I integrate the cc1120 library from IT's library. The device uses SPI as serial communication. Here is the communication example in given datasheet.
With this information i configured the SPI settings as:
after that i use HAL_SPI_TransmitRecieve( ) function as my comm func. in driver. But im not gonna share the complex library instead i will demonstrate the situation. My CS pin and cc1120 reset pin is logic HIGH in idle by software.
txdata[0] = 0x30;
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, 0);
HAL_SPI_TransmitReceive(&hspi1, txdata, rxdata, 1, 500);
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, 1);
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
txdata[0] = 0x2F;
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, 0);
HAL_SPI_TransmitReceive(&hspi1, txdata, rxdata, 1, 500);
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, 1);
HAL_Delay(20);
txdata[0] = 0x8F;
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, 0);
HAL_SPI_TransmitReceive(&hspi1, txdata, rxdata, 1, 500);
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, 1);
HAL_Delay(20);
txdata[0] = 0x00;
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, 0);
HAL_SPI_TransmitReceive(&hspi1, txdata, rxdata, 1, 500);
HAL_GPIO_WritePin(SPI1_CS_GPIO_Port, SPI1_CS_Pin, 1);
HAL_Delay(20);
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
}
In this code first i use command SRES (0x30) for reset the device. In this situation device must be send chip status from MISO line when i start to transmit from MOSI line. But i cant see the chip status byte in MOSI line (Im seeing 0xFF as chip status byte). Chip status byte explained in datasheet as: "When the header byte, data byte, or command strobe is sent on the SPI interface, the chip status byte is sent by the CC112X on the SO pin." and:
Then in while loop , want to access PART NUMBER register for read the chip id. The chip id reg is a extended register (0x2F8F). So first im transmitting 0x2F then 0x8F after that i want to recieve chip id. But again i cant get anything.
So i cant reach the cc1120 device but i don't know why. I tried several different configurations. I use oscilloscope for see the lines and SCK line looks fine to me. Here is the MCU and the RF part of pcb. Almost same as the reference design of the cc1120:
So there is a external 32MHz oscillator indicated as Y2 but we don't have it so we use 32.578 MHz instead. Is that a problem for the device? Here is the scope results:
Ch1:SCK
CH2:MOSI
In MISO line im only seeing logic HIGH voltage and nothing else. I think that MOSI line scope results overlapping in while loop but im not sure. How can i solve this problem?
Solved! Go to Solution.
2024-04-26 03:37 PM
We solved the problem. We were using a 32.768 MHz instead of 32 MHz oscillator. When we soldered 32 MHz, one SO line pulled logic LOW when CS was asserted.
2024-04-23 04:39 PM - edited 2024-04-23 04:41 PM
Are you sure that you have the SPI Mode correct?
Have you asked TI about this - to verify that your design is correct?
For example:
@mrkayaalp wrote:Almost same as the reference design of the cc1120:?
Is "almost" close enough?
@mrkayaalp wrote:So there is a external 32MHz oscillator indicated as Y2 but we don't have it so we use 32.578 MHz instead. Is that a problem for the device? ?
You really need to ask TI that question!
It looks like the only GND connection to the CC1120 is the pad on the underside - are you sure that is soldered correctly?
I had trouble with a CC1125 board where that pad was not soldered properly - that prevented the SPI working:
@mrkayaalp wrote:I think that MOSI line scope results overlapping in while loop but im not sure. How can i solve this problem?
You need to set your scope to single-sweep - so that you don't get multiple SPI transactions overwriting each other.
Maybe also put a breakpoint in your STM32 code, so that it only does a single read.
Does your scope not have a proper screen capture facility?
Simple logic analysers are available very cheaply these days - they can show you the full 4 wires, and decode the data
2024-04-24 01:14 AM
Thank you for your response. I swiftly raised the issue on the TI forum and am awaiting their guidance. Confidently, I've configured the SPI settings for Full Duplex Communication, and upon reviewing, the clock configurations appear to be in order.
Regarding the grounding connection beneath the device, I'll consult with our hardware-guy to ensure proper implementation.
Furthermore, I'm committed to resolving the issue efficiently and have decided to invest in a new logic analyzer, which I believe will significantly aid in troubleshooting.
2024-04-24 01:23 AM - edited 2024-04-24 01:26 AM
@mrkayaalp wrote:Thank you for your response. I swiftly raised the issue on the TI forum and am awaiting their guidance..
It would be helpful to give a link so that everyone can see the complete story.
@mrkayaalp wrote:I'm committed to resolving the issue efficiently and have decided to invest in a new logic analyzer, which I believe will significantly aid in troubleshooting.
It would also be beneficial to have a 4-channel scope - so that you can see all the SPI lines at once.
Many scopes nowadays can do protocol decode for SPI, etc ...
2024-04-24 02:01 AM
So i manage to get better scope results:
In while loop firstly im sending (0xAF -> 0x2F | 0x80) with 1 in the MSB for read operation (Sending 0x2F first for extended adressses). MOSI and SCK
Then im sending 0x8F for register adress:
Then im sending all zeros for recieve the data:
But again i cannot see anything in MISO line:
2024-04-24 02:08 AM
Your scope has a USB socket on the front:
Use that to download proper screenshots - far better than photos!
Before going to a custom board, did you verify your comms on dev boards - eg, BOOSTXL-CC1120 + Nucleo-F446 ?
2024-04-24 02:15 AM
No i didn't try it with BOOSTXL-CC1120 + Nucleo-F446. This is a prototype board for better understanding.
2024-04-24 02:28 AM - edited 2024-04-24 03:29 AM
You really need to get the basic understanding first - before making a custom board.
This is exactly why manufacturers make development/evaluation/demo boards like the Nucleo and BOOSTXL.
Once you've proved the basics on known-good hardware, then - and only then - move unto custom hardware.
eg,
that's for testing comms between an STM32 Discovery Board and a BOOSTXL-CC1125 (also an AVR).
EDIT:
A further significant advantage of using manufacturer's dev boards is support: the manufacturer - and forum users - will know exactly what you're talking about.
2024-04-24 03:42 AM
Also cross-posted on Stack Exchange:
https://electronics.stackexchange.com/questions/710767/stm32f446-mcu-spi-problem-with-cc1120-device
2024-04-24 04:09 AM - edited 2024-04-24 04:19 AM
It seems that the CC1120's SPI is identical to CC1125 - both defined in SWRU295 CC112x/CC1175 Low-Power High Performance Sub-1 GHz RF Transceivers/Transmitter User's Guide.
so here's my working SPI config for STM32F0-Disco to CC1125: