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.
I have a custom board with an MSP430FR5575 and a CC1101. In my app, he MSP is basically in LPM3 with a LF crystal doing some timekeeping and the CC1101 is sleeping as well most of the time. We've measured that the current consumed when both chips are sleeping is around 160uA @3V when should be much lower (around 10uA). I've cut the supply track and now I've attached two multimeters, one to measure the current through the MSP and the other for the CC1101. I can see that the current through the CC1101 is what datasheets says that it should (around 0.5uA) but the current being consumed by the MSP430, doesn't even matter if I enter LPM3 or LPM4, is much higher.
After playing around with the code, I've solved this scenario by, after sending the SLEEP command to the CC1101, resetting the eUSCI SPI module by setting UCSWRST and clearing it in the next instruction. Doing this the current goes down to around 10uA in LPM3. OK, I found a workaround, but I'd like to find an explanation of what I'm doing wrong. The code has been ported from another MSP430 with USCI instead of eUSCI that also drove a CC1101. There are some minor differences between USCI and eUSCI but none of them being meaningful to me.
SPI is working at 4MHZ, the TX/RX function uses polling and I check for UCTXIFG to be set before writing to UCA0TXBUF, for UCRXIFG before reading UCA0RXBUF and wait for UCBUSY to be clear before leaving the function.
Many thanks in advance.
Mmmm. After switching the clock source from SMCLK (=DCO) to ACLK(=LXT1) it started working straight away without having to reset the SPI module. Later I have tried dividing the SMCLK (=DCO/4) and also works without having to reset SPI.
Interestingly enough F_SPI = (DCO/4)/1 = 2MHz works, but F_SPI = (DCO)/4=2MHz does not (SPI reset requires). No matter what the clock frequency is the CC1101 understands all the commands, so the problem seems to be on the MSP side. Am I missing anything regarding the clocking of the eUSCI SPI module? Errata?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to jezule:
If I understand correctly, your problem is that when you go to sleep, the RF modules consumption is correct, while on th uC side it does not match with the supposed one.
Moreover, if you reset the SPI unit or change the clock source to 32 kHz, the consumption goes down to a correct level, isn't it?
If this is the situation, the problem is the clock source. In the users' guide, you will be that during LPM3 the SMCLK is off, but it is not an absolute truth. If you are using a perupheral unit (SPI, I2C, UART) configure with a frequency greater than 32 kHZ, when you go to LPM, even if they are not being used, the clock is running. Therefore, you have checked that if you change the frequency or reset the unit, the consumption goes down.
There are several solutions for this:
1) Reset the unit when you go to LPM, and restart when you wake up. You have already done it.
2) Change the clock source when you go to LPM. You have already done it.
3) On the UCS (Unified Clock System) exists a register that give you the possibility to disable several clock sources when you go to sleep. Take a look to your users' guide and SMCLKREQEN, MCLKREQEN and ACLKREQEN terms.
I hope it could help you.
In reply to Is T da S:
Thanks for your reply. I did not know that SMLCK is not completely off when entering LPM3 but I do not think this completely explains the issue. I have tried right now turning off SMCLK (CSCTL4.SMCLK=1) before entering LPM3 without noticing a big change in the current.
What I find weird is that in LPM3:
- eUSCI clock = SMCLK, eUSCI prescaler = 4, the MSP430 does not enter a deep sleep mode. It sometimes gets stuck checking UCBUSY. Resetting SPI solves all problems.
- eUSCI clock = SMCLK/4, eUSCI prescaler = 1,the MSP430 goes to deep sleep straight away.
Same clock source, same SPI clock frequency, different situation.
This is indeed strange.
Without any further investigation, I have one possible explanation to offer:
Teh USCI internalyl runs a state machine that is advanced with the eUSCI clock. (not the divided clock!).
So if you switch off the clock, the state machine immediately stops advancing. If this happens when the USCI isn't really done, it may cause the additional current.On MSPs where the USCI unconditionally requests the clock until it is done (even though you already entered LPM), the clock should go off once the USCI is really done and all is shut down. (in UART mode, on these MSPs the clock would never go off, as the clock is still needed for receiving, a known and documented erratum)
Just an idea.
Time to say goodbye - I don't have the time anymore to read and answer forum posts. See my bio for details.Before posting bug reports or ask for help, do at least quick scan over this article. It applies to any kind of problem reporting. On any forum. And/or look here.I'm sorry that I can no longer provide help in the forum or by private conversation.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.