• State TI Thinks Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 6130 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

EK-TM4C123GXL: Possible to realize 32-bit SPI communication?

Han Hao
Prodigy 90 points
Part Number: EK-TM4C123GXL
Other Parts Discussed in Thread: TM4C123GH6PM

Hi, I'm trying to use tm4c123gh6pm to communicate with a SPI slave device who has a 32-bit interface. As the datasheet suggests, the maximum SPI data frame size of this microcontroller is 16bit. Is there a way I can make this happen? Or can anyone recommend some other microcontroller which has 32-bit SPI?

Thanks a lot

  • 0
    TI__Guru 72500 points
    Depending on the slave device, you may need to "bit bang" the select line, configuring it as a digital low and then sending 2 16-bit transfers (or 4 8-bit) and then making the select line high after the last of the 32-bits are transferred.
  • 0 in reply to Bob Crosby
    Prodigy 90 points

    Hi Bob,

    Thank you. This makes sense. Considering the select line control, I should just use a normal GPIO and manually toggle it on and off right? And another issue is that, between the sending and receiving of 2 16-bit data, I believe there will be some time when clk are kept low, will this affect data transmission? Or should I use the continuous transfer mode?

    Thanks a lot,

    Han

  • 0 in reply to Han Hao
    TI__Guru 72500 points
    Typically having the clock pause between the 2 16-bit transfers is not an issue, but you need to check the datasheet of your slave device. (I have not yet run into an example of an SPI slave that required a continuous clock.)
  • 0 in reply to Bob Crosby
    Prodigy 90 points
    Got it. Thanks very much. I'll work on it and get back if there is any issue.
  • 0 in reply to Han Hao
    Guru 13040 points
    The steady clock during the period in which you reconfigure your 16-bit transmission does not affect the SPI data, don't worry - we have a few sensors that export 32-bit stuff. In theory, you could even read the first half today and the other half next week, and it would still be fine...
    As Bob stated, it is really a matter of finding out what your slave wants, as far as the CS line goes (some devices want it to stay steady, others need a pulse in the middle, there are all kinds of flavors).
    Bruno
  • 0 in reply to Bruno Saraiva
    Prodigy 90 points
    Great to know that. Thank you Bruno.
    I believe my slave device is looking for a CS signal pulse between different 32-bit datas, then it should stay low as data sent in and out. I guess one thing I should ensure is enough setup time between that CS pulse and the upcoming clk signal.

    Han
  • 0 in reply to Han Hao
    Guru 117850 points

    May I offer the finding that (certain) Display Control devices - employing SPI - (really) require continuous data clocking!
    (this as the data directly impacts the display's scanning - "sitting too long - on any one pixel row (or column)" proves NOT GOOD for the display's health!)

    Iirc - certain pressure sensors (also) seek constant SPI clocking - suggesting that a "REAL READ of the Device's Spec" - proves (always) best policy!

    I believe both posters here to be "generally correct" - but any "universal proclamation" (may) be unwise...       Lesson learned - RTFM (always)!

  • 0 in reply to cb1_mobile
    Prodigy 90 points
    Thanks for the information and suggestion. My slave device is an analog front-end + ADC, SPI datas sent in and out are writing/reading commands for registers, so I guess it should be fine.
  • 0 in reply to Han Hao
    Guru 117850 points

    Uh-oh - depending upon the "bit-depth" of that "AFE" - I recall a client - with a device either from "Linear Tech" or ADI (which has now swallowed LT) - where SPI clock variance "degraded" accuracy.     (from my memory - the ADC's, input Cap charge time's increase - as the MCU "regrouped" - negatively impacted that conversion!)

    This IS a "fine level" of detail - and may NOT be well described w/in the AFE's data.     It is not my intent to "cry wolf" - but to share my "photo-memory" - in the attempt to save you time/effort.     I do recall the (other) firm's FAE to be "unsure" - they don't always have the (preferred) first hand experience with EACH of  their assigned devices.

    While admittedly "nasty" - if yours is at/around 18 bits and up - I'd suggest a "bit banged, initial test - in which you (deliberately) "freeze the SPI clock" just as the MCU's implementation would do. Of course you must (properly) input known, stable analog signals - especially into those pins (potentially/likely) impacted by the "stall" of the SPI clock - while carefully monitoring (ideally logging) the data!

  • 0 in reply to cb1_mobile
    Prodigy 90 points
    I see. Defenitely will try and ensure it. Thanks a lot for your kind help! :)
  • 0 in reply to Han Hao
    Guru 117850 points

    Thank you - it proves "safest" to expect, "Nothing to be easy" - letting one's guard down may "open wide the door to the unwanted..."

    Staff here has (now) abandoned ship - if you provide your device identity & maker - staff will tomorrow, "search on" that specific part - see if we can locate the past detail...     (I'd quote odds @ 10:1 your proposed device is from LT or ADI - after awhile - "nothing is new!")

  • 0 in reply to Han Hao
    Expert 2355 points
    Hello Han Hao,

    Please have a look at the data sheet section "15.3.4.4 Freescale SPI Frame Format with SPO=0 and SPH=1". If you are able to feed the FIFO rapidly enough, you can achieve the required 32-bit transfer by using the Fss signal and 2x16 or 4x8 transfers (no bit-banging required). I believe it is specific to the particular mode identified above. I have used this successfully in the past, but with a caveat: if the FIFO is starved (runs "dry") the frame select signal will de-assert mid-transfer. You must protect from an intervening interrupt introducing too much latency, etc...

    Regards,
    Dave
  • 0 in reply to SourceTwo
    Guru 117850 points

    Greetings extended to "the" Source.     (the true source)

    Might this "monkey motion" have been avoided if the SPI Frame Format (recognizing this IS a 32 bit MCU - and that advanced SPI devices (may) require 32 bit transfers) had been designed to SUPPORT such 32 bit transfers?       Acknowledged - this was a NEW requirement - and HAS been implemented by others - has it not?

    Is (that) not the REAL "Gorilla in OUR  midst/mist" - must it (always and only) be "Bandaids to the rescue?"       (I've just "re-opened my cut - now must find a larger bandaid...")

  • 0 in reply to cb1_mobile
    Expert 2355 points
    Hi cb1,

    Yes, I must agree with your sentiment - seems most of the peripherals were designed somewhat "unencumbered by the thought process". (Credit to Car Talk for that one). By the way, did you every have the pleasure of working with the QSPI on the now-extinct MC68332? That was a thing of beauty!

    Best Regards,
    Dave
  • 0 in reply to SourceTwo
    Guru 117850 points

    Greetings Dave,

    Lobster season must not (yet) be in full-force - seeing your arrival here... (we East Coasters LOVE our NE style Clam Chowder & Lobster - out west - most always - even "fine" places serve, "Clamless Chowder.") (I delight them (almost) as much as I do those here...)

    One of the top Profs @ UCLA was enthralled w/that MC68332 - I tried to "run off with it" - sadly was forced to "return to the school." Newer M4s & M7 (you know where) have very nice support for "QSPI" - as you know - single bit I/O "killed their earlier implementation" - now 4x Data & faster speed - greatly raises their appeal & use. (we did one board w/2 - and (almost) achieved "common clocking." [yielding 8 bit transfers]

    Staff/I LOVED Car Talk - the fallen brother IS missed - heck of a show from 2 smart (MIT) guys...

    Your "lifted" (yet credited) line, "unencumbered by the thought process" may echo (even here) to expand to, "unencumbered by the thought and/or EFFORT process."      Let them eat cake!    (served w/nice bandaid wrap)

  • 0 in reply to cb1_mobile
    Expert 2355 points

    Back in the day of the MC68332, "QSPI" stood for "Queued SPI" and that was the root of beauty!

    Dave

  • 0 in reply to SourceTwo
    Guru 117850 points
    As to "roots" and "beauty" some here are advised to avoid mirrors...