MSP430: what doesnt work…….

This will be an on going post that will be constantly updated on what doesn’t work when coding for the msp430…….yes this will feature my failings lol.
so for the first Failure……

Project: RGB led fade to different colors with a ~4 hour timer
This fail is a test program that i had created to test the software PWM using WDT+ and interrupts.
CCFLAGS = -mendup-at=main
-mendup-at=”function”—when main ends, it usually goes to stop program execution, but you can make it jump back to main when main exits. pretty much sets it up as a never ending loop. great if main is supposed to never exit or return.
Code:

#include<msp430x20x2.h>
#include<signal.h> //interrupt SR
volatile unsigned int timer1 = 0;
void main(void) {
WDTCTL = WDT_MDLY_32;
P1DIR |= BIT0+BIT6;
IE1 |= WDTIE;
if (timer1==126) {
timer1 = 0;
P1OUT ^= BIT6;
}//end if
_BIS_SR(LPM0+GIE);
}//end main
interrupt(WDT_VECTOR) watch_dog_timer(void)
{
++timer1;
P1DIR ^= BIT0;
} //end interrupt

what it was supposed to do is cycle through the program, when the WDT causes an interrupt the timer is supposed to increment
then once the timer reaches 126 it resets and toggles P1.6(green LED on launchpad)

what it did is loop through, never servicing an interrupt, and looped with out doing anything……well almost nothing, timer1 never incremented but the main loop did compare timer1 to 126.
for some reason the interrupt never gets serviced because it goes back to main and clears the WDT timer count, so then it runs it runs so quick that the interrupt that’s sitting there clears when it goes back to main…..
Cause: my theory says my code maybe too short for it to call the interrupt fully.
When i step through it the interrupt flags never get called, and before you know it the whole thing starts over again.
Fix: none as of yet still testing

Update: code is still failing – and tested and tested, time for a new approach…..but here is what doesn’t work

#include <msp430x20x2.h>
#include <signal.h> //add for interrupt
#define UP 0x00
#define DOWN 0x01

volatile unsigned int millsecs = 0;
volatile unsigned int counter2 = 0;
//void loop(void);
void main(void)
{

WDTCTL = WDT_MDLY_32;
P1DIR |= BIT6;
P1DIR |= BIT0;
//P1OUT ^= BIT0;
IE1 |= WDTIE;
loop();
//++millsecs;
//if (millsecs == 253) {
//millsecs = 0;
//++secs;
//P1OUT ^= BIT6;
// }
//int i;
//for (i=0;i<10;i++);

//eint();
}
void __inline__ loop(void) {
P1OUT ^= BIT0;
if (millsecs == 253) {
millsecs = 0;
//++secs;
P1OUT ^= BIT6;
}
msp_delay(20);

}//end loop
void __inline__ msp_delay(register unsigned int n)
{
__asm__ __volatile__(
" 1: n"
" dec %[n] n"
" jne 1b n"
: [n] "+r"(n));
}//end delay
interrupt(WDT_VECTOR) watchdog_timer(void)
{
++millsecs;
P1OUT ^= BIT0;


}

A few things that I had tried

mendup-at=loop does not work as expected and mendup-at=main works but resets counters and resets settings that are usually run at the beginning of main.

also WDT interrupt still not being serviced……I will be taking a completely  different approach.

using low level init and having larger then normal interrupt service routines for either the timer or WDT+ ….more to come soon lol


2 Responses to MSP430: what doesnt work…….

  1. Hey there, Justin.

    If I’m not mistaken, your problem lies in the WDTCTL statement. It’s my understanding that ANY assignment to the WDTCTL register needs to include WDTPW so that the write is effective. The WDT has a bit of a security mechanism in place that prevents corruption by requiring a “password”, WDTPW, to be included in any bit write to the register.

    I think that’s what’s wrong. I could be wrong myself, but that’s the only thing that I can think of. Best of luck!

    • i did think of that but WDT_MDLY_32 – is defined by WDTPW+WDTTMSEL+WDTCNTCL, i think it runs way too fast for it to work correctly,
      it always runs through the main loop and the interrupt is never serviced and is cleared when it goes through main again.
      I see how it runs and all the bits get set, then cleared as it goes through again and again. I believe my approach is incorrect on how to get this to work——– later on today i will be updating my failure post, i have tried a few different variations testing the interrupt and code……and all have failed which leads me to believe what i am trying to due is not feasible at this time, so i am going to use that metronome code and base it off that. more to come 🙂