• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 31 subscribers
  • Views 878 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.

TM4C1294NCPDT: How to clear the SSI Tx-Fifo

claus scheidl
Prodigy 230 points
Part Number: TM4C1294NCPDT

Good Day to everybody...

I've a quite simple question. In my RTOS application with the TM4C1294 I have a task listening for any bytes coming in via a SPI transfer from an external master. Works perfect.

But in my tx-fifo are several Bytes that are exchanged when the master sends something. It happens now, that the synchronization is lost, when the master asks for an unexpected number of bytes. Well, then I don't know exactly how many bytes and what is left in the tx-fifo. My simple question is, how to clear the Tx-Fifo?? Didn't found a register to manage that simple problem!

Would be great, if someone else knows more than me.  Klaus-Michael

  • 0
    TI__Guru**** 191486 points
    Hi Claus,
    There is not such a register bit to clear the TX FIFO. I will suggest in such a case you call SPI_close() or call TivaWare driver API SysCtlPeripheralDisable() and then SysCtlPeripheralEnable for your SPI slave.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Hi Charles,

    Never to doubt/question (except for 'here/now!')     Would not,  'Review of the DriverLib - provide valuable insight?'    Thus...

    SSIEnable(uint32_t ui32Base)

    {
    // Check the arguments.
    ASSERT(_SSIBaseValid(ui32Base));
    // Read-modify-write the enable bit.
    HWREG(ui32Base + SSI_O_CR1) |= SSI_CR1_SSE;
    }
    //*****************************************************************************

    SSIDisable(uint32_t ui32Base)

    {
    // Check the arguments.
    ASSERT(_SSIBaseValid(ui32Base));
    // Read-modify-write the enable bit.
    HWREG(ui32Base + SSI_O_CR1) &= ~(SSI_CR1_SSE);
    }

    Alas - no 'Clear and/or Deliberate Treatment' of the SSI FIFO - appears w/in (my enfeebled) recognition...

    While 'BRUTAL' -  one would expect that a 'Peripheral Reset' - would achieve that clearance - yet demand Perhiperal's (repeated) initialization!

    [EDIT] ... Whoops - just noted that you suggested, 'SysCtlPeripheralDisable()'  which (somehow) 'crack staff' (ok - moi) MISSED!    (can you say,  Dumkopf!)    We are checking - and will post/report...

    And here - and now - what (we) originally intended:

    //! Disables a peripheral.
    //! This function disables a peripheral. Once disabled, they do not operate or respond to register reads/writes
    //*****************************************************************************

    void
    SysCtlPeripheralDisable(uint32_t ui32Peripheral)
    {
    // Check the arguments.
    ASSERT(_SysCtlPeripheralValid(ui32Peripheral));

    // Disable this peripheral.
    HWREGBITW(SYSCTL_RCGCBASE + ((ui32Peripheral & 0xff00) >> 8),
    ui32Peripheral & 0xff) = 0;
    }

    It is unclear (at least to me) if  (this)  function, 'DOES indeed clear the SSI FIFO.'    In the defense of your Client-Users - the SSI-FIFO (and/or) most such 'FIFOs' - are 'less than well explained' - and their location may over-challenge most here.     (surely to include this reporter...)

  • 0 in reply to cb1_mobile
    TI__Guru**** 191486 points
    Hi cb1,
    I was going to suggest the SSE bit but I wasn't certain if it will reset the FIFO pointers or merely just stopping the SPI until it is re-enabled again. If the FIFO pointers are not clear then once the SPI is enabled again, the prior remanent data in the FIFO can still go out to the bus. This is why I suggested peripheral reset. If the slave loses synchronization with the master I think it is fine to reset not just the slave but the master as well to reestablish synchronization.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Hi Charles,

    Agreed - and you may note - my group is 'BIG FAN' of, 'Peripheral Reset' - as that insures that the Peripheral 'STARTS' from known/stable - initial conditions.     That said - did you not suggest 'SysCtlPeripheralDisable()' - which while 'close/almost' - proves (not) 'Peripheral Reset.'

    The 'Issue Resolving Post' - first to identify  SysCtlPeripheralReset() - was mine - presented here (first ) @ 06:48 - this morning...

    Yet - there is a (serious) 'downside' to 'Peripheral Reset!'      As you surely know - that Peripheral must  (then) be completely 'RE-Initialized!'     Thus - the user trades 'time' (for the Peripheral to become initialized & ready) for the 'robustness' - which the 'Clean Restart'  hopefully provides...

    It is assumed (ok hoped) that 'some other means' of 'Clearing the SSI FIFO' may exist.    Yet (as earlier noted) Tech Writers provided:

    • only  the 'bare minimum' of guidance
    • and/or 'did not themselves know'
    • or simply chose 'not to share' 

    Now to your suggested,  "the SSE bit but I wasn't certain if it will reset the FIFO pointers"     Staff here (those awake) 'deep-dived' - uncovered:

    Register 3: SSI Data (SSIDR), offset 0x008

    The transmit FIFO and the receive FIFO are not cleared  even when the SSE bit in the SSICR1register  IS cleared, allowing the software to fill the transmit FIFO before enabling the SSI.

    Perhaps - if he's 'still with us' - poster may note that his 'simple issue'  (in the eyes of whom?) - can (likely) be achieved by  issuing the 'SSI Peripheral Reset' call (and then Re-Initializing) - which (it is highly expected) - should 'Clear the SSI's TX (and RX) FIFOs.'     (poster's declaration of this as 'simple' - may meet some (well deserved) challenge!)

  • 0 in reply to cb1_mobile
    TI__Guru**** 191486 points
    Hi cb1,
    Thank you for catching my mistake. While I wrote peripheral reset, I quoted the wrong API. The SysCtlPeripheralDisable will gate the clock off to the peripheral. SysCtlPeripheralReset is to create a s/w reset to the peripheral. You are correct.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Hi Charles,

    You ARE to be commended for 'sensing' that the 'SSE' bit - may not cause the FIFO Reset!     (see staff's 'confirming FIND' - of your exact guidance - above)

    Once more - even a 'blind squirrel' - stumbles across an (occasional) walnut. (No squirrels - especially blind ones - were harmed - during the read of or writes to - this thread. Same can not be said for the walnuts...)

  • 0 in reply to cb1_mobile
    Prodigy 230 points

    Thanks to all contributors,

    The blind squirrel still is around. I guess the "walnut" is poorly designed concerning the Fifos. And I'm unhappy with the peripheral reset and new setup. This may cause that I'll loose a transfer by the master.
    Usually the master will behave as expected and always send the number of bytes required. I'm now going to implement a magic return to the master to let him know, when the slave looses the synchronization. Then he can send an extra command to trigger the peripheral reset. This will be a save workaround...

    For me the issue is solved as far as possible.  Klaus-Michael 

  • 0 in reply to claus scheidl
    Guru 117855 points

    As your 'solution' stems from the earlier 'identified & recommended use of 'Peripheral Reset'' - which (was) noted as 'brutal' - fairness (and consideration of time/effort invested (in your behalf)) would yield 'dual awards' - one to you (for a 'tightened' (on demand) trigger of Peripheral Reset) - and a second for the 'identifier of that  key function' - which stood (and remains) as your 'best & only' hope...