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

MSP430 SPI in slave mode

Olli Mannisto
Expert 1750 points
Other Parts Discussed in Thread: MSP430FR5969

There's piles of examples and documentation for using SPI in master mode. However for slave mode it's a bit more tricky. 

Reading is straightforward enough but are there best practices / tutorials for writing in slave mode? I found some discussions here but that's about it. e.g. https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/167107

It's a synchronous bus but the µcu cannot guarantee any exact response time so you cannot do what you do with simple devices. Most of the time these have a defined command -> address -> n delay bytes -> response cycle within one frame. At least the single frame approach wouldn't work for MSP430 as it'd be difficult to synchronize the write exactly to the master unless I'm missing something. 

To put things into perspective, 8MHz SPI bus has clock cycle of 125ns, MSP430FR5969 is running at 16MHz so 62.5ns clock cycle. However wake-up from LPM4 takes between 7-10µs i.e. 7-10 bytes transmitted on SPI bus at that time. 

I should set up DMA to snag the received bytes, wake up processor meanwhile, process the command and start pushing relevant data to transmit buffer with DMA and/or send single byte as appropriate. Master goes to have a coffee and a cigar during that time. Some 20µs delay between command transmit and dummy bytes to read data perhaps?

I found one mention that LPM3 (and 4 obviously) will put DMA clock to sleep so you're going to miss the 1st byte. According to the handbook MSP430FR5969 should keep clock available if needed by peripheral but since DMA is only awake after triggered.. Override the relevant clock disable bit?

  • 0
    TI__Guru 56685 points
    Hello Olli,

    Please keep in mind that the DMA uses MCLK which is shut off in most LPMs. So you will need to wake up to Active Mode to use it. Please refer to the Operating Modes table 6-1 in the datasheet fora list of which peripherals/clocks are available for use in different LPMs. It is true that with the clock request feature, will keep clocks on when going into different LPMs. The effect here is that you will not be going into the lower LPM mode you want. For example, the difference between LPM1 and LPM2 is the use of SMCLK. If you have a peripheral that uses SMLCK and requests it in LPM2, you are in LPM1 until that clock request is cleared. Also, you must pay attention to when a peripheral will signal a clock request. For example, the eUSCI in UART mode makes a clock request when a UART TX or RX is happening and only requests for the duration of the transmission. Periods between TX/RX do not have the clock request so the part will shutdown the requested clocks between byte transmissions. You must take care to account for the clocks starting back up when the next byte is received, which can limit the baud rates you can do in different LPMs.

    Now onto your case. You are using an Unlocked Peripheral, which means since its in SPI mode, it does not need an internal clock to run for its clocked externally. This means the SPI Slave will receive a byte into its buffer in LPMs. You just need to wake the device and transfer the received byte out of the receive buffer, before the next byte has finished reception. You can do this due to the nature of the eUSCI which has a buffered TX/RX register. Since you are using a high SPI TX/RX frequency, I would suggest using the SPI CS line to wakeup the MSP430 (GPIO interrupt) from an LPM to active mode so you can empty the RX buff in time before the next byte arrives. You can also come up with a scheme were the SPI Master operates at a lower TX speed until it gets confirmation from the MSP430 that it has woken up.
  • 0 in reply to Jace H
    Expert 1750 points
    Thanks for the detailed reply. Some additional questions.

    Is that LPM vs clocks really so straightforward? i.e. if I go to LPM1 and do CS_enableClockRequest(CS_MCLK) 1st, I'm still in active mode although the CPU is off? So the current consumption is about the same as in the figure 5-1 in the SLAS704E for 0% AM or about 3x vs LPM0? And if I do set that bit, DMA will then kick in with the usual 5xMCLK delay when triggered?

    In the SLAU367K chapter 11.2.7 examples are given for various LPM modes vs DMA transfer 1st byte. Table 11-3 says that in LPM3 or above, using LFXT1CLK as MCLK (=DMA clock) source does not carry the 5 µs penalty for waking up DCO. So far so good. I do presume this holds true for HFXTCLK as well? Is that '1' in LFXT1CLK something specific or it means just LFXTCLK?
  • 0 in reply to Olli Mannisto
    TI__Guru 56685 points
    Olli,

    Please check the Figure 1-5 Operating Modes in the User Guide along with the Operating modes Table 6-1 in the datasheet for more detail descriptions on what operating modes have what enabled. The LPMx.5s are a special case though. They start turning off the core and PMM depending on settings. BTW LPM1 with MCLK enabled is LPM0. Or in other words Active Mode with CPU off is LPM0.

    For HFXT, please see the note for HFXT in section 3.2.3. Went entering LPMs, the HFXT can be disabled and the time for a HFXTAL to stabilize is much longer than wake up times reported in the datasheet. So using HFXT in this way is not advised. LFXT doesn't get this penalty because it is not turned off automatically due to its lower power usage, and of its need to be used by the RTC in LPMs. Please also keep in mind, the wake up times from LPMs is dominated by clock startup time.
  • 0 in reply to Jace H
    Expert 1750 points

    Table 6-1 says in LPM0 MCLK is off but turning it on won't turn on CPU?

    On subject of using LFXT to run MCLK, you're limiting yourself to 32kHz CPU clock which does not seem very useful for most purposes?

    WRT HFXT, my application is not really low power so keeping it running would not be a big issue. Looking at Table 5-5 in datasheet I can see that using 16MHz crystal consumes 190µA current so there's no meaningful benefit going to the trouble of using LPM3 with HFXT active. We did see earlier there are certain issues using MSP430FR5969 @ 16MHz with the DCO thought. 

    In fact I think I can save myself a lot of trouble by modifying code from using LPM4 just because and use LPM0 instead. 

    Heating is an issue however since the environment is high temperature so using ULP processor makes sense and it's cheap and cheerful too. 

    Regards, Olli

  • 0 in reply to Olli Mannisto
    TI__Guru 56685 points
    Olli,

    Sorry about the confusion on MCLK. You can ahve the CPU and MCLK disabled separately, but you can't really control it. Certain peripherals that only use MCLK (DMA, AES acellerator, etc) add in Bus Stalls to the CPU when they are in use in order to not have CPU execution. Effectively you would be in LPM0 with MCLK enabled if one of these peripherals makes a clock request.

    Correct, LFXTAL running MCLK is not useful in most cases.

    I also concur on your assessment for your particular application that LPM0 will save you some hassle, especially if Low Power is not the biggest concern for you. LPM0 just makes more sense for the High Data rate you are using SPI at.

**Attention** This is a public forum