Skip to main content
mrkayaalp
mrkayaalp
Associate II
April 23, 2024
Solved

STM32F446RET SPI Problem With CC1120 Device

  • April 23, 2024
  • 4 replies
  • 8798 views

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.

Pasted image 20240424003521.png

With this information i configured the SPI settings as:

Pasted image 20240424003611.png

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:

Pasted image 20240424004458.png

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:

Pasted image 20240424005159.png

Pasted image 20240424005211.png

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:

WhatsApp Görsel 2024-04-24 saat 01.13.10_a240d5a4.jpg

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?

This topic has been closed for replies.
Best answer by mrkayaalp

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.

4 replies

Andrew Neil
Andrew Neil
Super User
April 23, 2024

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:

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1271367/cc1125-cc1125-spi---miso-so-stays-low

 

@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

A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
    mrkayaalp
    mrkayaalpAuthor
    Associate II
    April 24, 2024

    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.

     

    Andrew Neil
    Andrew Neil
    Super User
    April 24, 2024
    @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.

    EDIT: https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1353735/cc1120-spi-problem-with-stm32f446re-custom-pcb 

     

    @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 ...

    A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
      Andrew Neil
      Andrew Neil
      Super User
      April 24, 2024

      Also cross-posted on Stack Exchange:

      https://electronics.stackexchange.com/questions/710767/stm32f446-mcu-spi-problem-with-cc1120-device

       

      A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
      Andrew Neil
      Andrew Neil
      Super User
      April 24, 2024

      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:

      AndrewNeil_0-1713956826598.png

      AndrewNeil_1-1713956873307.png

       

      A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
      mrkayaalp
      mrkayaalpAuthor
      Associate II
      April 24, 2024

      My settings are same as yours. Which library are you using for the device?

      Andrew Neil
      Andrew Neil
      Super User
      April 25, 2024

      I worked from the SWRA493 (October 2015) CC112x-CC1190 Boost Software Examples:

      https://www.ti.com/tool/BOOSTXL-CC1120-90#related-design-resources

      https://www.ti.com/lit/an/swra493/swra493.pdf

      Another advantage of starting with a manufacturer's dev kit!

      Your other 2 threads have already pointed-out two flaws in your code:

      https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1353735/cc1120-spi-problem-with-stm32f446re-custom-pcb/5161874#5161874

      and that's apart from any hardware issues on your custom board.

      A complex system that works is invariably found to have evolved from a simple system that worked.A complex system designed from scratch never works and cannot be patched up to make it work.
      mrkayaalp
      mrkayaalpAuthorBest answer
      Associate II
      April 26, 2024

      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.

        Terms & ConditionsAccessibility statement