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.

LED problem with port B

Other Parts Discussed in Thread: TM4C123GH6PM

I made a simple program to run four LED's connected to port B as follows :-

#include <stdint.h>

#include <stdbool.h>

#include "inc/hw_types.h"

#include "inc/hw_memmap.h"

#include "driverlib/sysctl.h"

#include "driverlib/gpio.h"

#define TARGET_IS_BLIZZARD_RB1

#include "driverlib/rom.h"

int main(void)

{

ROM_SysCtlClockSet(SYSCTL_SYSDIV_4|SYSCTL_USE_PLL|SYSCTL_XTAL_16MHZ|SYSCTL_OSC_MAIN);

ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOB);

ROM_GPIOPinTypeGPIOOutput(GPIO_PORTB_BASE, GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3);

while(1)

{

ROM_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3, 0x0f);

ROM_SysCtlDelay(32000000);

ROM_GPIOPinWrite(GPIO_PORTB_BASE, GPIO_PIN_0|GPIO_PIN_1|GPIO_PIN_2|GPIO_PIN_3, 0x00);

ROM_SysCtlDelay(32000000);

}

}

There are no errors in the program.

I have connected the cathode of all the LED's to "ground".

But the LED's are not glowing. (although they are working fine when I connect there anode to 3v3 and cathode to "GND")

  • vikas saxena said:
    LED's don't glow. (although they are working fine when I connect their anode to 3v3 and cathode to "GND")

    Operative phrase here may better be, "Leds were working fine!"

    It is normal/customary to impose a properly sized, series connected, current-limiting resistor between power source and such Leds.  While the MCU (likely) has insufficient current source capability to, "do in/kill" your Leds - surely the connection you describe (quoted above) has no such limitation! 

    Typical, modern Leds glow nicely w/3-5 mA current flow.  Ohm's law enables your calculation - red and green Leds typically show ~2V drop at/around that current.  That series connected - limiting resistor must "drop" the remaining ~1V3 - to keep Leds, "safe/happy."  Note that blue or white Leds have a higher voltage drop (~3V) and new, "forest green" (i.e. real green - not color challenged yellow-green) may approach that same 3V.

    Your code reveals no issue that my 03:00 review can spot - other than the insertion of some delay just after, "ROM_SysCtlPeripheralEnable()."  MCU requires some time for that enable to take effect - you should not immediately follow that Enable function w/another - targeting that same peripheral.

  • But they are still not working.

    Should I try using the GPIOPadConfigSet() API to increase the GPIO strength to 12mA.

  • vikas saxena said:
    But they are still not working.

    Please follow KISS to best enable myself/others to assist.

    a) Find some resistor (68-200 ohms ideally) and feed 3V3 to one end - opposite end tied to Led's anode. (Led's cathode continues to ground - as you've stated.

    b) Systematically repeat that connection @ each candidate Led.  Do they illuminate?

    c) You make no report of adding the delay I specified - w/out proper feedback we're stuck...

    d) Unless your Leds are damaged - or really of poor quality - 12mA should not be required.

    e) If the Leds have survived - being sure to employ the series connected current limiting resistor - temporarily change your code to another Port (D, E) ideally and retry.  Avoid Port A (defaults strangely), Port C (JTAG danger) and Port F (F0's special delight awaits).

    We note you've not identified make nor model of your MCU.  And - is this an "official board" or your own design?

  • I tried step "a", but the led's didn't glow.

    the MCU is TM4C123GH6PM. I have purchased the original Tiva Launchpad from Texas instruments..

    I mam using a 220ohm resistor.

  • VS: "Tried step (a) - Led didn't glow..."

    If that led's cathode is really/effectively tied to ground - and if your series resistor is ~220 ohms (not 220K) - and if your've connected the other end of that resistor to an adequate 3V3 source - your Led may have been damaged.

    I'd repeat this test across all of your Leds - one at a time.  If - as your initial post suggested - you powered the Leds from a "stiff" 3V3 source - that may have damaged them.

    Confusing - and still unstated - is how (or if) you were able to bypass/defeat the (usual) presence of the current limiting resistor - and inject 3V3 directly into the Led's anode - while the Led's cathode is tied to ground.  Suspect that took some special effort - and was ill advised...

    This has moved far from ARM issue - your code (w/the addition of the delay just past Port B Enable) looks good and I leave you to Led replacement or further exploration. 

  • Hello Vikas,

    Couple of things

    1. There is no delay after ROM_SysCtlPeripheralEnable call. It could be that the code has gone into a Fault Loop. This you can check with the debugger by running the code again and then halting to see where it is

    2. You can use the debugger interface to check if the bits are written correctly and you can write through the debugger interface to the GPIODATA registers and then see if 3.3V is coming on the pins

    3. As cb1_mobile mentioned, the LED's may have already been damaged. It is always a good idea to have 220Ohms Current Limit Resistors.

    Regards

    Amit

  • cb1_mobile said:
    code reveals no issue that I can spot - other than the insertion of some delay just after, "ROM_SysCtlPeripheralEnable()."  MCU requires some time for that enable to take effect

    Earlier, that pitfall was immediately noted and mentioned - it remains unclear if poster really did comply.

    Even a worse horror may lurk - if unlimited 3V3 was introduced both to the Led anode - and to the driving MCU pin - and that pin was configured as an output - and set low - damaging current may have befallen that MCU...

    Believe that there's, "little magic" in constraining current limiting Rs for MCU driven Leds to 220 ohms.  Such tight specification likely will reduce use of the limiting R - due to, "that value not on hand/easily obtainable."  Believe the earlier suggested 68-220 serves as a, "safer recommendation" as potential R availability is much improved...