• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 79 subscribers
  • Views 446 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.

Original question:

Compiler/MSP430F6779: SPI Slave with CS on the MSP430F6779, where is UCxSTE ?

Compiler/MSP430F6779: SPI Slave with CS on the MSP430F6779, is the UCxSTE fully functional?

MARTY steinDORF
Intellectual 390 points
Part Number: MSP430F6779


Tool/software: TI C/C++ Compiler

I've worked with a lot of different MSPs and have found when I run as a slave in 4 wire SPI mode, the CS (connected to STE) only gates the clock, it does not reset the SPI subsystem so that the 1st clock in the next transfer will be the 1st bit.  (this is needed with long bus runs in noisy environments where noise may add or subtract a false Sclk). I know how to work around this by running the CS to an interrupt and to do the reset via code but I was wondering if this is still needed with the MSP430F67xx family?  has anyone tested this on this newer eUSCIxx as SPI slave subsystem? 

  • 0
    TI__Mastermind 49692 points

    Hello Marty,

    For more information about how the eUSCI module works, I would recommend referencing Chapter 40 in the MSP430x5xx and MSP430x6xx Family User's Guide. Also, I would recommend using the A-version, MSP430F6779A, rather than the non-A version in your design. There are several improvements between these revisions (described here) while maintaining pin-to-pin compatibility. However, there is an eUSCI-related errata, USCI50, for both versions that may be close to what you're describing. You can read more about it in the erratasheet.

    Regards,

    James

  • 0 in reply to James Evans
    Intellectual 390 points

    Hi James and thanks for the reply

    I have read the users guide and the text is (more or less) the same as it was for the non enhanced units.  It is not clear if the Rx shift register is reset to the 1st bit or if it just continues with where it left off before the STE line is toggle (like it does in the older MSPs f1611, f2618, f427 ...).    

  • 0 in reply to MARTY steinDORF
    TI__Mastermind 49692 points

    Hello Marty,

    I think I understand what you're saying. Reading the user's guide, the RX shift register isn't reset but halted when UCxSTE transitions into the slave inactive state (which disables but does not reset the eUSCI module). If data is getting received when this happens, it would make sense that there could be left-overs in the RX shift register when UCxSTE transitions back to slave active state. The eUSCI is reset by a PUC or by the UCSWRST bit.

    Ideally, UCxSTE transitions when all the data has been received or transmitted, not while it's being received or transmitted. I'm not sure how far the SPI signals can be routed natively before these type of issues start happening, but I would definitely look into ways to filter out or remove that noise. Obviously, the eUSCI module will react to any type of signals, noise or intentional.

    Basically, what you're doing sounds like the best approach and was discussed by Jens-Michael Gross in the following threads.

    MSP430 FR57XX SPI Slave Transmit and Receive Issue

    SPI STE functionality confusion?

    Regards,

    James

  • 0 in reply to James Evans
    Intellectual 390 points

    Thanks James,

    Whats nice about this family is it appears I can map the STE function to a pin on port 1 or 2 AND configure it as an interrupt!  That saves me the need to run the CS line to two pins.  I setup the interrupt to fire on CS disable edge and the ISR code can simply reset the SPI subsystem just toggle the UCSWRST bit.  I can deal with the noise in firmware by including and testing the packets CRC in the transfer.  I have not fully tested the STE pin mapping option but I have used the reset trick in other projects.

    FYI to other reader: this SPI noise issue is a rare event and depends on signal length, load parameters, and environmental conditions.  Not something you normal need to worry about.

**Attention** This is a public forum