0

I've been trying to turn on the LEDs on my MSP430G2553 and it just doesn't work. I've tried the code examples from TI, the pre-generated code composer studio LED blinking project, and even previous code that worked on an MSP430 from the past. None of them seem to work. What could be the problem? Could it be faulty hardware? Here's my code:

#include  <msp430.h>

void main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop watchdog timer
  P1DIR |= 0x01;                            // Set P1.0 to output direction

  for (;;)
  {
    volatile unsigned int i;
    volatile unsigned int j;

    P1OUT ^= 0x01;                          // Toggle P1.0 using exclusive-OR

    i = 25000;                              // Delay
    while(i--) {
       j = 2;
       while(j--);
    }
  }
}
charlee
  • 31
  • 1
  • 8
  • 2
    That's a pretty wild spin-loop. Is that the best way to stall for a period of time? – tadman Oct 24 '17 at 19:22
  • https://e2e.ti.com/support/microcontrollers/msp430/f/166/t/18638 – Bálint Oct 24 '17 at 19:27
  • 1
    A lot of very basic example from TI uses this kind of pooling loops before diving into energy harvesting stuff... It is quite common to see them around when the user is at the very first tries with the MCU... – Matteo Ragni Oct 24 '17 at 19:29
  • If the TI-supplied example projects don't work (and you're sure this is supposed to work on your board, you're compiling it, loading it correctly, etc) I'd say that's a pretty strong indicator of faulty hardware. Any DIP switches to set? You never set `P1DIR` directly, any chance some other bits in that could be mucking with things? – yano Oct 24 '17 at 19:34
  • 1
    "Does not work" does not tell us anything. Does the flashing succeed? Can you debug the program? – CL. Oct 24 '17 at 19:37
  • Might be a hardware problem. Did you observe the "previous code" "working" on the same board in the past? If so, the board or the LED might just be physically broken now. – kfx Oct 24 '17 at 19:57
  • @CL It doesn't flash at all. Yeah I can debug it and it gets programmed onto the MSP430 properly. – charlee Oct 24 '17 at 20:23
  • @tadman I've tried other loops, but none of them result in a flashing LED. – charlee Oct 24 '17 at 20:23
  • @kfx By previous code, I mean that it's the same uC model, but that it's a different board. – charlee Oct 24 '17 at 20:27
  • @yano Yeah it all builds and loads properly. I don't have any DIP switches and I've tried setting P1DIR directly, but there just aren't any flashing LEDs. – charlee Oct 24 '17 at 20:30
  • Can you try with `P1DIR |= 0x6` and `P1OUT ^= 0x6`? – Matteo Ragni Oct 24 '17 at 20:45
  • @MatteoRagni I tried P1DIR |= 0x6 and P1OUT ^= 0x6 and it didn't work. – charlee Oct 24 '17 at 21:24
  • Since it's fairly clear this is a hardware problem, I'll vote to close. If you help with checking the hardware, you may consider asking for that in http://electronics.stackexchange.com/ – kfx Oct 25 '17 at 10:39

4 Answers4

4

I encountered a problem with the MSP430FR5994 dev board where the LEDs wouldn't turn on for the blinky example but they would turn on for the "Out Of Box Experience" project. Comparing the code, I determined that the difference is this line from pmm.c:

//For FRAM devices, at start up, the GPO power-on default
//high-impedance mode needs to be disabled to activate previously
//configured port settings. This can be done by clearing the LOCKLPM5
//bit in PM5CTL0 register
PM5CTL0 &= ~LOCKLPM5;

Putting that at the top of main() seems to fix whatever the issue is and the LEDs behave as expected.

Gladclef
  • 687
  • 1
  • 8
  • 17
  • I came here looking for an answer to this question for the MSP430FR2433 and this is the correct answer for my case. The TI example for this chip didn't have this line. Adding it fixed my issue. – rost0031 Jul 16 '20 at 18:07
0

Can you try this version (still a polling loop, but let's keep it very basic)?

#include <msp430.h>

int main(void) {
  volatile int i;
  WDTCTL = WDTPW | WDTHOLD;
  P1DIR |= 0x01;
  P1OUT = 0x00;

  for (;;) {
    P1OUT ^= 0x01;
    for (i = 0x6000; i > 0; i--) { };
  }
  return 0;
}

I took this from one of my old examples when I used the MSP430 in 2010...

Matteo Ragni
  • 2,837
  • 1
  • 20
  • 34
  • I just tried it. Unfortunately, it doesn't seem to work. – charlee Oct 24 '17 at 20:21
  • Since I'm quite confident about this code, I guess that we are dealing with a faulty hardware. I'm sorry. – Matteo Ragni Oct 24 '17 at 20:23
  • faulty hardware or what about your headers/addresses, you sure you have them matched up with your specific device? – old_timer Oct 24 '17 at 21:02
  • The general header includes the specific header. In any case, the specific header for the OP is `msp430g2553.h`. If the header is not matched the code does not compile (there is an `#error` in the general header if cannot get the define for the specific hardware) – Matteo Ragni Oct 24 '17 at 21:05
  • I've used #include and #include . Neither of them have a flashing LED. – charlee Oct 24 '17 at 21:26
0

Try replacing your while loop with __delay_cycles(1000000);.

Compilers can optimize-out empty loops even if the loop variable is marked as volatile.

#include  <msp430.h>

void main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop watchdog timer
  P1DIR |= 0x01;                            // Set P1.0 to output direction

  for (;;)
  {
    P1OUT ^= 0x01;                          // Toggle P1.0 using exclusive-OR

    __delay_cycles(1000000);
  }
}
Stephane Hockenhull
  • 185
  • 5
  • Unfortunately, it still doesn't flash the LED. – charlee Oct 24 '17 at 21:28
  • Check the pin's voltage with a multimeter or oscilloscope, check the other GPIO pins (might be the wrong one), check that the LED works, check that it's plugged in the right direction, make sure you have the proper resistor in series to that LED, test the resistor. The MCU pin might be fried or the LED itself. – Stephane Hockenhull Oct 24 '17 at 21:38
0

After a reset, all port pins are high-impedance with Schmitt triggers and their module functions disabled to prevent any cross currents. Even if you have made all the necessary GPIO settings, you need to clear LOCKLPM5 bit in the PM5CTL register (described in the I/O Configuration After Reset chapter TI User Guide)

PM5CTL0 &= ~LOCKLPM5;

until then, the I/Os remain in their high-impedance state with Schmitt trigger inputs disabled.

Aleksey Hblasto
  • 1
  • 1