5xx LPM3 with UART wakeup?

Bump!

I would like to know the answer to this as well.

Have you looked at the code examples (SLAC166) provided on the MSP430F5438 Product Folder?  There are a couple of examples that configure the USCI for UART mode and use LPM0 and LPM3.
They do use a different targeted baud rate, but this should provide some guidance.

I realize this isn't a definitive response, but wanted you to be aware of the existing examples.

Hello.

I made the same observation as described above. The examples are not helpfull in this case, as mentioned earlier. They do not address a comparable scenario (8MHz SMCLK, 115.2kBaud, LPM3).

SMCLK remains active although it should be off in LPM3 when no other module is requesting the SMCLK and the uart should make use of its start-edge-detection (as it was named on the for the 1611). Within an example application the SMCLK is disable during LPM3 as long as i do not turn on the uart module beforehand.

Can anyone confirm complete LPM3 with disabled SMCLK, and SMCLK used to drive a  UART with 115.2kBaud? Could it somehow be linekd to the UART oversampling mode? Because the examples seem to indicate that there is no problem with lower baudrates.

Kind Regards,

Oliver

The issue: When using the USCI in LPM3 or LPM4 SMCLK (sourced from the DCO) remains on contrary to statements in the User's Guide (section 15.3.14)

The Cause: This is actually a known issue and has been confirmed by the factory as a bug (in F54xx & 54xxA). It should be on forthcoming errata when the next revision of the document is released. The following are possible workarounds:

1. Use a GPIO pin as a chip select (CS) when the MSP430 is receiving data. In the Port ISR, switch the polarity on the interrupt pin edge select, enable the UART and RX interrupt, complete the UART transactions, and go back to sleep on the following GPIO interrupt request (release of the CS).

2. Enter LPM3 mode with SMCLKREQEN = 0, use a GPIO pin as a CS pin and, in the port ISR switch the polarity on the interrupt pin edge select, enable SMCLKREQEN bit, complete the UART transactions, and clear the SMCLKREQEN bit on the following GPIO interrupt request (release of the CS).

Both have an inherent latency between CS signal toggling and the MSP430 being able to receive data successfully, which should be accounted for by a delay on the master between toggling the CS signal and transmitting the first data byte. Else, one would still need to calculate the latency in respect to the baudrate and see how many bytes need to be re-sent from the master as to not lose any data. This case would reduce complexity on the master implementation by eliminating the critical timing from CS -> delay -> 1st TX byte.

Brandon,

Thanks for the followup on this.  I was pretty sure that the origional intention was that the drop of the start bit would start the DCO (and SMCLK) and wake from LPM3. 

Is there any plan (from TI) to fix this on a future release of this part?  What about other parts in the 5xx series?

Thanks again,    -Tom

Tom,

I am pretty sure this will still be present in the 54xxA devices. I'm not 100% beyond that. Lots of factory apps watch this forum, so as soon as there is more information we'll be happy to provide it. Sorry for the incovenience.

Would I be correct to assume this issue is common to all 5xxx devices currently out (such as the 522x)? Or is it restricted to just the 54xx family?

Following the posts from Brandon it was a known issue with the F54xx and F54xxA devices. Then it was “still under investigation” according to Priya on May 15, 2009. There has been no follow up from TI staff since then. Yesterday I realised that on a current product we manufacture based on an F5636 this problem must have actually been resolved. We have a similar situation to Salty Hog’s original post. In our case the FFL is running at 8MHz referencing ACLK at 32.768KHz. USCA0 and USCA1 are both using SMCLK for their baud rate generators. SMCLK startup from the falling edge of RXD on either port is less than 1uS (930nS if fact). At 115.2KB the bit time is 8.68uS. That means the next transition (rising edge) will be no sooner than 8.68uS and is correctly sampled. i.e. This works at 115.2KB and no characters are missed. So you could say this feature is working as advertised. 

The point of my post however is that there was no follow up on this issue to explain what the actual problem was with the F54xx/A parts, when the problem was resolved and exactly which other parts were effected. I understand this is a forum but it also appears to be the only means of technical support from TI on this family. I have another post here that I have not received any support with from the forum since 9 August. I would really appreciate if a TI staff member could address this and talk to the factory and respond with an explanation. It's all very well to be Genius’s living in the vacuum of this forum but I could really use your help with this one:

Hi Dean,

I can appreciate your concerns.  Lots of times these "communications" are done tersely in the erratasheets, not as a follow up to an old forum post.

For example, the erratasheets for F54xx and F54xxA devices indicate that erratum UCS6 affects these devices.  It also shows that newer devices (newer F54xxA silicon revs) no longer have the problem.

The erratasheet for F5636 indicates that it has never had this problem (UCS6).

Heads up on the "fix" for UCS6, though.  The DCO isn't guaranteed to start that fast. Depending on your clock setup, very high baud rates may not be reliable without specifically avoiding LPM3 (and using LPM0 instead).  I would say 230.4kbaud or higher is flatly unreliable trying to use LPM3.  115.2kbaud with LPM3 should work with good clock settings, a good reference, and 16x oversampling.

Have you checked the erratasheet on your other post relating to Timer A?

Jeff

Hi Jeff,

Thanks for getting back to me on this and for the advice on UCS6. I gather the "6" means the sixth version of UCS? Is there a document that summarises the versions, features and issues with all MSP430 peripheral blocks issued to date? We don't actually let the executive loop transition into LPM3 at the moment when we are expecting serial comms but do intend to in the future subject to more detailed testing.

On my earlier issue, I have searched through all of the errata I can find. The latest issued is SLAZ321G–October 2012–Revised July 2013. There is an issue discussed (TAB23) that results in problems reading TAR/TBR. This is not related to the problem discussed in my post.

Dean.

Dean Cooper said:

UCS6. I gather the "6" means the sixth version of UCS?

However, fixing UCS6 on newer silicon may lead to introduction of a new USCI erratum (regarding not being able to properly receive the first byte in LPM due to slow DCO startup)

Hi Dean,

Sorry to hear about your difficulties. Jens-Michael is right, the investigation mentioned earlier in this thread led to the publication of the erratum UCS6 in the MSP430F5438A errata document (this document is linked off of the MSP430F5438A product page) - unfortunately it looks like no one updated the forum thread when the new errata document with UCS6 was released. Sorry for the confusion this has caused.

The UCS6 erratum is listed in all errata documents of devices that are affected by this issue - since it does not affect the MSP430F5636 device that you are using, it is not listed in the errata document for your device.

I'll take a look at your other thread that you mentioned.

Regards,

Katie

Hi Katie,

I'm seeing this issue with the msp430fr5739 has well but I don't see anything about it in the errata regarding this.  Can you verify that if this issue affects this chip?

Thanks,
Andy

Hi Andy,

UCS6 does not affect MSP430FR5739.

Could you describe in more detail your setup and then what behavior you are seeing? UCS6 erratum is that SMCLK will stay on - correct behavior is that SMCLK would turn off. Are you seeing the clock stay on (by outputting it on a pin to observe this, for example?)

Or are you having the issue of SMCLK with the DCO not starting fast enough for your UART communication speed - that would not be the same thing as UCS6, though some people were depending on the UCS6 failure behavior and sometimes ran into an issue like this when it was fixed (usually with a high UART speed where the DCO wake-up time from datasheet may be too long for the particular baud rate you choose).

Regards,

Katie