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.

CCS/TM4C1237H6PM: SSI Slave TX line value stuck after 1 byte.

Part Number: TM4C1237H6PM

Tool/software: Code Composer Studio

Hello,

I am using the SSI module on slave mode and I want to do 4 byte reads. 

However, after 1 byte is read the TX line of the microprocessor gets stuck on the bit of the first byte. 

On the slave mode if I try the reading 4 bytes here's what happens: 

The same thing also happens if I read 1 byte at a time but because the first byte is correct the overall operation works:

If I do the loopback test with the same data as the device configured as master I get the correct behaviour: 

I just want to understand why this is happening.

My master device is a raspberry pi 3B+ using  the SPIDev library. 

My configuration is like this, the weird frequency comes from SPIDev: 

Thanks for reading.

  • Greetings,

    As you report,

    Tuna Bicim said:
    If I do the loopback test with the same data as the device configured as master I get the correct behaviour: 

    If my logic proves correct - your 'loopback' condition 'eliminates' (at least greatly reduces) SPI clock frequency differences between SPI Master & Slave.    (This as both Master & Slave reside w/in the (same) MCU - and (I suspect) the 'signal path' is (short & direct - entirely internal) thus 'idealized!')

    From a review of your 3rd data capture (above) - the Master's SPI Clock to Data relationship is 'beyond reproach.'  

    It is my belief that while in 'SPI Slave Mode' - it is only the Master which generates the SPI clock.    However - the fact that you 'have had to' program your Slave MCU - in the attempt to 'Match the Master' - leads to my sense that a 'Frequency Delta' proves a key factor in your system failure.    And your scope caps - 'Do not - or cannot' - provide the Slave's (internal) 'SPI clock to data'  capture/verification. 

    As a test of this theory -

    • cannot you bring your 'Rasp Pi' into a, 'far more conventional' SPI clock rate?    
    • And also - cut that SPI clock rate (nearly) in half - better enabling your SPI channel's success.  
    • Also - can your 'Connecting Signal Path' be reduced - and made more direct - and (really) 'measured & tested?'
    • Possibly 'signal reflections' (standing waves) impede the Slave MCU's data capture.   A series resistor along w/'Reduced Path Length' should help.   You may also 'Scope as a check for 'Ringing.' 

    (once that (laundry list's) achieved - you can, systematically 'Increase speed' - carefully observing (just where/when) your system (I suspect) then 'breaks.')    

    Do insure that a solid ground joins your boards - and that 'under operation' - power delivery to both boards is adequate...

  • Thanks for the reply. 

    Clock difference might the cause of it but I'm not sure yet. The problem is SPIDev library only takes certain values and those values are sadly not conventional. The other way to try it might be connecting another microprocessor board and using a conventional value.

    I tried much lower frequencies and the result is the same. The other difference on the loopback mode is that the SPI module is master instead of slave on that instance.

    Right now because this is a development kit I am using jumper cables which are not perfect but is not noisy enough from what is seen on the logic analyzer. 

    I think I am going to try to hook another spi module of the tiva board to itself and try it that way. If it works then the problem might be the clock generation on the Raspberry or my connections. 

  • Thank you - I am 'on the road' and kept getting, 'Bad Gateway' as I systematically composed (and sent) my progressive response.

    Somehow bullet-point #4 'did not survive' - fortunately I ''save regularly" (kidz at home are so advised - as well) so (now) all bullets reveal.

    Good as logic analyzers are - I believe that you need a (reasonably) high-performance Scope - to monitor data's arrival at the Slave's SPI Input port.   (I cannot recall if that's MOSI - brain fade?)

    Your idea of employing 'another board' and one able to operate at (both) conventional SPI data rates AND SLOWER ONES - at least initially - is seconded!     (the fact that the first byte arrives successfully signals that (the potential for 'Clock Delta Growth w/data length' (may) prove of consequence.)

    I am surprised that your 'Pi System' is so restrictive - that cannot be good...

  • I figured out the solution.

    When I configured SSI1 as master and connected it to SSI0 I realized that FSS signal was pulsed between bytes and the documentation also shows this for Freescale SPI. Raspberry Pi library wasn't pulsing the FSS signal between bytes which resulted in Data Buffer for SPI to not update.

    This is still an annoying requirement but at least I know what to do.

    Thanks again for the replies. 

  • Ay Caramba - 'I should have noticed that!'    Yet a good 'detective job' on your part - and (still) your recognition of the NEED for 'a stable' of 'KNOWN GOOD Signal & Communication Sources' for 'Ready Attachment to the MCU' proves quite good.

    The only (slight) justification for my failure was the lack of Channel Labeling - I note (now) that Ch-3 (likely) carried the FSS signal - which as you noted - remained at 'logic high' - throughout your entire 4 byte transaction!

    There'a a (likely) homeless guy - just down the street from my 'beach-side hotel' - I may offer my 'Tech Services' to him.   (And at a discount - I can't even 'blame distractions' - my deluxe room overlooks the ocean - yet the 'action' is 180° shifted - at/around 'the pool.'   (I failed in that diagnostic - as well...)    (It IS fortunate that my 'parole documents' specify - 'No Sharp objects'...)