• Resolved

CC1312R: Question about the SPICC26X2DMA.c driver

Intellectual 940 points

Replies: 5

Views: 86

Part Number: CC1312R

Hi,

I have written my own slave driver for SPI and DMA as I was having some issue and wanted a simpler piece of code to debug. Instead of using Ping-Pong mode, I am using Basic mode as I do not need to ever transfer more than 1024 bytes in one go. So I have removed all the frames and queue code. I have some questions regarding the driver:

1)  It seems there is a mysterious way the driver flushes the Tx FIFO. I'm guessing this is an internal TI trick as I can't find any documentation anywhere.

/* SPI test control register */
#define SSI_O_TCR                   (0x00000080)
#define SSI_TCR_TESTFIFO_ENABLE     (0x2)
#define SSI_TCR_TESTFIFO_DISABLE    (0x0)
/* SPI test data register */
#define SSI_O_TDR                   (0x0000008C)

2) The driver registers a power notification for when the device wakes from stand-by. The notify function then flushes and disables the SSI. Then it configures it again, all in initHw(). Why is this needed and can I exclude this code? If I don't release the constraint and thus preventing a transition into stand-by, I would think this never gets called anyway.

Power_registerNotify(&object->spiPostObj,
                         PowerCC26XX_AWAKE_STANDBY,
                         (Power_NotifyFxn) spiPostNotify,
                         (uint32_t) handle);

3) I first produced a very stripped back non-DMA driver loading the Tx and Rx FIFO's in ISR's and this worked okay but would pause when the mac became busy as the lower priority SPI ISR's got delayed. However, I noticed that I could send the chip select low from thge master side, receive data, load tx data and then transmit that data all without toggling the chip select. To overcome the data pause I implemented DMA. This works but I have to prime the DMA transfer in the slave by making the SPI master toggle the chip select in order for the master to receive the correct byte (I'm not using full-duplex comms so there is only valid data on the Tx line or Rx line and never both). This is in-line with the datasheet. So my question is rather, why was this not needed in the non-DMA version?

Many thanks.

  • Hi,

    I sent it to a concerned engineer. We will get back to you ASAP. Please bear with us.

    Thanks,

    PM

  • In reply to PM:

    Hi,

    Any news?

    Point 3) is more of a curiosity.

    Regards,

    Andy

  • Genius 10240 points

    In reply to Andrew Bakin:

    Hi Andy,

    Sorry for the delay. I am looking for someone to get back to you on this.

    Thanks for your patience.

  • Genius 10240 points

    In reply to FI:

    Hi,

    Did the general behavior of the driver help in the resolving your questions:

    http://dev.ti.com/tirex/explore/node?node=AP24VgJ7gbuZWQrdF16tIg__pTTHBmu__LATEST 

    I have forwarded your query to the relevant team and they should get back to you

    Appreciate your patience.

    Thanks

  • In reply to FI:

    Hi,

    That's okay. I'm happy for this topic to be closed as it's not that important now. None of the points in this thread are causing any problems for me. I think the answer lies in undocumented hardware and so I'm prepared to never know the exact reasons for my observed behaviour. 

    Regards,

    Andy