• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1183 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.

AM3352: Beaglebone Green Wireless and CC1101

Randhir Kalsi
Expert 4545 points

Part Number: AM3352
Other Parts Discussed in Thread: CC1101, , AM3358

Hello team,

Hope you are well.

Is there a driver that readily works with the CC1101 on the AM335x?

The customer's research has shown that user space SPI use will be preempted by kernel processes and delay its use.

They have started looking at the PRU, but would like a way to speed things along.

Any recommendations?

Issue:

The CC1101 is responding over SPI, but with incorrect data. Have a CC1101 working with a competitor MCU for years.

The AM335 is new and so is the development environment. User space code on the board appears to not work with the implementation below:

   struct spi_ioc_transfer transfer[3];           //the transfer structure

   // send the SPI message (all of the above fields, inc. buffers)

   int status = ioctl(fd, SPI_IOC_MESSAGE(3), &transfer);

  • 0
    TI__Guru**** 393215 points
    Hi,

    For CC1101 support please ask on the Low Power RF forum: e2e.ti.com/.../155
    By the way, Beaglebone Green Wireless is a third-party board and is not supported in any of the TI released SDK's.
  • 0
    TI__Expert 4545 points
    Hello team,
    Hope you are well. Any feedback on customer question regarding AM335x and CC1101 application.
  • 0 in reply to Randhir Kalsi
    TI__Guru**** 393215 points
    Please see my previous post.
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 317180 points
    From Randhir's post it sounds like the issue is on the AM3352 side. Randhir: More details would be required to understand what is going on.

    Btw, CC1101 is supported from this forum: e2e.ti.com/.../156
  • 0 in reply to TER
    Prodigy 80 points
    Success! Source of issue still unknown.

    The CC1101 was never the issue. "spidev1.0" was working incorrectly as I read it. The communication was moved over to spidev2.0 and spidev2.1 and the code works as written.


    Further symptoms of spidev1.0 issues:

    Data can be written to the CC1101 and read using the ioctl commands. The registers of the CC1101 change and the device can be made to transmit correct data on 433MHz. The registers are read and confirmed on the Oscilloscope. The SCLK and MOSI and MISO all work correctly.

    The only thing that does not match up is the receive buffer on the AM3358 after the ioctl() function.

    ioctl(fd, SPI_IOC_MESSAGE(3), &transfer);

    The array assigned to transfer[0].rx_buf always results in a "doubling" of the Least Significant Nibble. The data returned may be a byte with data "0x2A", but the data recorded in the buffer if "0xCC". It looks as if the receive buffer if recording the returned data at double-time after the first nibble of returned data. The issue is the same for every bite that comes in. EX: 0x15 == 0x33; 0x01 == 0x03;

    If anyone knows of the source of this issue, please reply. I would like to use the port if possible.