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.
Tool/software: Code Composer Studio
Hi,
I am implementing a program to log analog values to SD card every 15 min, during ideal time DCO is wasting lot of power sitting there and doing nothing (can't use VLO as it is too inaccurate to track time). My logic is to reduce speed of DCO significantly during 15 min interval and then later increase it to default DCO value. The DCO clock speed is reducing down (I can make out from register value and low current consumption) but it is not reverting back to original DCO configuration. Can any one help with suggestion.
DCOCTL and BCSCTL1 are set to 0x0, but they are not revering back to original configuration which is DCOCTL = 0xA0 and BCSCTL1 = 0x8F
(Code and register values pasted below)
#include "msp430g2553.h" #include <driverlib.h> #ifndef TIMER0_A1_VECTOR #define TIMER0_A1_VECTOR TIMERA1_VECTOR #define TIMER0_A0_VECTOR TIMERA0_VECTOR #endif #include <SPI.h> #include <pfatfs.h> #include <pffconf.h> #include "SPI.h" #include "pfatfs.h" #define cs_pin 8 // chip select pin #define read_buffer 128 // size (in bytes) of read buffer unsigned short int bw, br; char buffer[read_buffer]; int rc; DIR dir; /* Directory object */ FILINFO fno; /* File information object */ uint32_t sensor1; uint32_t sensor2; uint32_t sensor3; uint32_t sensor4; uint8_t StringLength = 0; char buf[50]; uint32_t counter = 0; uint32_t AccStringLength = 0; unsigned long time; int c=1; uint32_t t1 = 0; uint32_t t2 = 0; uint32_t t3 = 0; uint32_t t4 = 0; void setup() { analogReference(INTERNAL2V5); pinMode(9, OUTPUT); pinMode(10,OUTPUT); FatFs.begin(cs_pin); digitalWrite(10,HIGH); delay(200); digitalWrite(10,LOW); delay(200); } void loop() { digitalWrite(9,HIGH); sensor1 = analogRead(2); delay(5); t1 = sensor1; sensor2 = analogRead(3); delay(5); t2 = sensor2; sensor3 = analogRead(5); delay(5); t3 = sensor3; sensor4 = analogRead(6); delay(5); t4 = sensor4; digitalWrite(9,LOW); rc = FatFs.open("LOG.TXT"); delay(5); bw=0; sprintf(buf,"%lu Output is %lu,%lu,%lu,%lu\r\n",counter,t1,t2,t3,t4); counter++; StringLength = strlen(buf); rc = FatFs.lseek( AccStringLength ); AccStringLength = AccStringLength + 1024; rc = FatFs.write(buf,StringLength,&bw); rc = FatFs.write(0,0,&bw); //Finalize write rc = FatFs.close(); //Close file BCSCTL1 = 0x0; // Set range DCOCTL = 0x0; delay(1000); BCSCTL1 = 0xA0; // Set range DCOCTL = 0x8F; }
1) Initial clock register values ( DCOCTL = 0xA0 and BCSCTL1 = 0x8F)
2) Clock register values while the code is running (DCOCTL and BCSCTL1 have become 0x0, but they are not revering back to original configuration which is DCOCTL = 0xA0; and BCSCTL1 = 0x8F)
Hi Tapas,
I tried something similar to this and did not observe the same behavior. Everything seemed to work ok. However, I don't think this is the best way to conserve power. Have you considered using an external 32kHz crystal to source ACLK and then run a timer from ACLK during your idle time? ACLK remains active in LPM3 and the current is very low. This can be seen in the low power mode supply currents (into Vcc) section of the datasheet:
Best regards,
Caleb Overbay
Thanks Caleb, after reducing the delay it seems to work fine, I will report more on this thread after extensive testing.
Since PCB is already made, I can't use crystal. My bet was on using VLO clock source, but it drift significantly with voltage change. One more question, does rapidly changing DCO clock register in loop affect the life and performance of the controller.
Regards,
Hi Tapas,
It might also be helpful to check out Using the VLO Library which details how to measure the VLO frequency on your device so you can get better accuracy out of using it. Let me know if this helps.
Also, I don't know of any problems that occur from rapidly changing the DCO clock register. This is not a typical use case of the DCO since it is usually set at the beginning of execution and not changed again.
Best regards,
Caleb Overbay
**Attention** This is a public forum