• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 52 subscribers
  • Views 865 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2650 SPI RTOS Error

Bryan McLaughlin36
Prodigy 10 points
Other Parts Discussed in Thread: CC2650

I am trying to connect one of the SPI modules in the CC2650 chip to the following pins:

SCLK: DIO_10

CS: DIO_11

MOSI: DIO_13

MISO: DIO_20

 

We are not using the MISO functionality, but I have connected it to DIO_20 (which is unconnected on our custom board).

 

When I call the RTOS function SPI_open, which I expect to return a handle to an SPI “object”, it returns null.

 

If I modify the pins I am trying to connect the SPI peripheral like so:

SCLK: DIO_18

CS: DIO_15

MOSI: DIO_6

MISO: DIO_1

 

The SPI_open function returns a valid handle.

 

When I try making a call to SPI_transfer with the null handle while running in debug mode, I can see that the program calls the loader_exit function in the file exit.c.

 

When I make the call to SPI_transfer with the valid SPI handle, the chip behaves as expected. The SPI_Transaction object is the same in both test cases.

 

All of the pins in question (the set that work and the set that don’t) are accessible on the smartrf board. I have tried running the code both on our custom board and one of the development boards and the debugger behaves the same in both cases.

 

The set of pins that work are labeled as follows on the smartrf board:

SCLK: RF1.8

CS: RF1.6

MOSI: RF1.4

MISO: RF1.5

 

The set of pins that does not work are labeled:

SCLK: RF1.16

CS: RF1.14

MOSI: RF1.15

MISO: RF2.8

Has anyone successfully used the RTOS function SPI_transfer function that could help me overcome this NULL issue?

Thanks!

  • 0
    TI__Guru* 85400 points
    Moving to Bluetooth Low Energy Forum

    Regards,
    Gigi Joseph.
  • 0
    TI__Mastermind 29650 points

    Hi Bryan,

    A brief explanation on what you're seeing:

    All peripheral drivers using pins use the PIN driver (PIN_open) to get a PIN handle for the pins they are using. This ensures that this handle "owns" the set of pins and no-one else can get a handle for those pins. If the application or another driver has called PIN_open for any of the pins first then PIN_open in the SPI driver will fail and SPI_open will return NULL.

    The SPI_Handle is a pointer to the corresponding SPI_config in your Board file which contains the configuration for the driver. Subsequent calls to the SPI driver assumes you are using a valid handle and since yours are not valid the driver will read in data from address 0 + offset and probably ends up with a fault somewhere.

    To resolve this issue, simply make sure you don't have any conflicting pins being opened in your application + board header/source files and things should be fine.

    Regards,
    Svend