• State
  • Locked Locked
  • Replies 21 replies
  • Subscribers 34 subscribers
  • Views 2229 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

LM4F120 Launchpad bricked?

Kris Falkowski
Prodigy 30 points


Stellaris Launchpad on LM4F120H5QR.

I was following Lesson4 of Quantum Leaps on YouTube and was able to eventually use various ports and pins to light up an LED by manipulating memory bits from Debugger.

The next day, to reinforce my knowledge, I wanted to do the same thing, use random pins and light up the LED, but many careful attempts later, I was totally unsuccessful. I was still able to repeat the deal with built-in RGB LEDs, but when attempting to use other pins, invariably built-in Blue LED would light up but not the one I was trying to access, even though the RGB LEDs GPIO memory section was not enabled (at least in debugger memory window I could not see it being enabled: no RCGCGPIO set to enable PORTF, no GPIODIR, GPIODEN or GPIODATA bits set to enable PORTF bits).

Is it possible that because I left the debugger running with all RGB GPIO pins enabled plus one other pin enabled, and at some point shot down the computer without exiting the debugger the proper way, I have bricked the chip on Launchpad? Is it at all possible to do to the Launchpad?

If it is the case, could I just replace the uC on the board and if yes, which one: the one in the debugger section or in the development section?

I have just ordered new Launchpad but with TM4C based uC anyway, but I would love to know what am I doing wrong what exactly happened.

I will appreciate any explanation, just please make it in plain English because I am very beginner at this embedded thing.

Thanks a lot.

  • 0
    TI__Guru**** 244440 points
    Hello Kris

    Are you able to connect to the LaunchPad?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 30 points

    Hi Amit,

    Yes, I am able to connect and actually run the debugger and turn the RGB LEDs On and Off. Strange.

    I was/am thinking that maybe I am missing something but if so, how come the Blue LED comes On every time I am setting other Pins as outputs?

    I tried Ports A, B, D, E and of course repeat the experiment with 3 built-in LEDs on Port F. Port F seems to be working fine but when I try to repeat the same exact procedure with other ports pins it doesn't work.

  • 0 in reply to Kris Falkowski
    TI__Guru**** 244440 points
    Hello Kris,

    Maybe I am missing something here but the LED's are connected to Port F, so it will not work other ports.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 30 points
    I am using external LED with series resistor that I am connecting to the Pin I want to use and GND. Sorry, I wasn't clear on that.
    So when I exit the Debugger, all the registers and memory locations are cleared and when the Debugger is restarted I manipulate a given port/pin I want to use and connect external LED between that pin and GND. Why the built in Blue LED turns on instead of the one I just configured?
  • 0 in reply to Kris Falkowski
    Guru 47900 points

    Kris Falkowski said:
    Why the built in Blue LED turns on instead of the one I just configured?

    Might that be because your code (which has not been presented) has maintained Port "F" and not switched over to enable & output via other ports?

    It seems most likely that certain parts of your original code continue to run - and your new, alternate port-controlling code - does not.   And (strangely) your altered code is unavailable for review & comment...

  • 0 in reply to cb1
    Prodigy 50 points
    Sorry for not including the code but I thought it was irrelevant since I am working from the Debug and manually changing the bits at addresses.

    I have exactly the same code as in the lesson where the teacher is just using very simple piece of code to start the Debugger and then is able to change the bits relevant to the GPIOs of Port F. He was able to do it and I was able to do it, up to the point when, as I mentioned in my first post, I was trying to repeat the exercise the next day.

    I just downloaded into IAR IDE the code written earlier in which I am using the LM4F120H5QR macros and blinking all 3 built-in LEDs and my external LED in a while(1) loop and this time it works, while last time I tried it wasn't. My external LED was blinking in tandem with Blue one and when it was time to blink my LED, it wasn't blinking but code was running it, judging by the length of break before blinking the next (the built-in) LED.

    What could have changed? I didn't touch the code since last time I tried and it didn't work. I will now try to use the Debugger again and try to access the pins manually. Have the suspicion that now it will work. I will get back with the results soon.
  • 0 in reply to Krzysztof Falkowski
    Prodigy 50 points
    It didn't work!

    Here is the code, which I am not running, just use it to start the debugger (exactly the same code when exercising the built_in LEDs and exactly the same as the teacher uses it in his demonstration).

    int counter = 0;
    int main(){
    int *p_int;
    p_int = &counter;
    while (*p_int < 21) {
    ++(*p_int);
    }

    p_int = (int *)0x20000002U;
    *p_int = 0xDEADBEEF;


    return 0;
    }

    When in Debugger, I enable the Port D GPIOs clock by entering in Symbolic Memory window this: 0x00000080. This is equivalent to setting Bit3 in RCGCGPIO register at 0x400FE608 and when at the same time looking at address 0x40007000, I see the memory range for GPIOD is being enabled.
    Next at 0x40007400 I enter 0x08 in the LS Nibble to set Pin PD3 as output.
    Next at 0x4000751C I enter 0x08 in the LS Nibble to enable Digital Output of PD3.
    As a last step, at 0x400073FC I enter 0x08 in the LS Nibble to sent 1 as a Data to PD3.
    As soon as, in the last step, I send a "1" to PD3, the Blu built-in LED lights up, but not mine.
    The Debugger was started fresh in this exercise so no other than Port D GPIOs were configured.

    Here is the code that runs just fine, now.

    #include "lm4f120h5qr.h"
    #define LED_RED (1U << 1)
    #define LED_BLU (1U << 2)
    #define LED_GRN (1U << 3)
    #define My_LED (1U << 0)


    void my_Dlay(int d);
    void blink_LED(unsigned int color, int num);
    void blink_My_LED( int num );


    int main(){

    SYSCTL_RCGCGPIO_R |= (1U << 5); // enable clock for GPIOF
    SYSCTL_RCGCGPIO_R |= (1U << 1); // enable clock for GPIOB
    GPIO_PORTF_DIR_R |= (LED_RED | LED_BLU | LED_GRN); // set pins 1,2 and 3 as outputs
    GPIO_PORTF_DEN_R |= (LED_RED | LED_BLU | LED_GRN); // enable pins 1,2 and 3
    GPIO_PORTB_DIR_R |= (My_LED); // set pin 0 as output
    GPIO_PORTB_DEN_R |= (My_LED); // enable pin 0


    while(1){
    int volatile counter = 0;

    blink_LED(LED_BLU, 8);
    my_Dlay(1000000);

    blink_LED(LED_RED, 4);
    my_Dlay(1000000);

    blink_LED(LED_GRN, 1);
    my_Dlay(1000000);

    blink_My_LED(3);
    my_Dlay(1000000);
    }
    return 0;
    }

    /*****************************
    *
    * Delay routine
    *
    *****************************/
    void my_Dlay(int d){
    volatile int counter = 0;
    while (counter < d){
    ++counter;
    }
    return;
    }

    /********************************
    *
    * This function blinks the LEDs
    *
    ********************************/
    void blink_LED(unsigned int color, int num){
    for(int i=0; i < num; i++){
    GPIO_PORTF_DATA_R |= color;

    my_Dlay(100000);
    GPIO_PORTF_DATA_R &= ~color;

    my_Dlay(100000);
    }
    return;
    }

    void blink_My_LED( int num ){
    for(int i=0; i < num; i++){
    GPIO_PORTB_DATA_R |= My_LED;

    my_Dlay(100000);
    GPIO_PORTB_DATA_R &= ~My_LED;

    my_Dlay(100000);
    }
    return;
    }
  • 0 in reply to Krzysztof Falkowski
    Guru 117855 points

    Your code is entirely "Direct Register Macro" (DRM) based - which while purported to have educational value - places far more demands upon the programmer and all those (downstream) who must read, debug & edit it!   And w/MCU manual constantly/chronically, "At the ready."

    As small tech biz owner - we rarely employ that DRM code - instead this vendor (and most all others) produce a, "Tried/true/long tested" and "Far MORE UNDERSTANDABLE" API - rich in functions - and light years more intuitive than (archaic) DRM.

    Yes you require knowledge of Registers and their interrelationships - yet review of the vendor's source code (freely available) provides that as well. If my firm (and most others) coded exclusively via DRM - we'd NEVER ship on time - and 10 minutes after we "combed the MCU manual for that key/critical bit" it would be blurred and (quickly) forgotten!   And then what - we'd get to repeat that same cumbersome process when performing normal code maintenance - or God forbid - updating and/or correcting such unfriendly code.   Ask yourself - can that be (at all) good?

    Your studies should reveal that profit margin most always "peaks" during the "early entry" to market.    API usage gets small firms there - DRM - not a chance! Every small tech firm I know (and that's many) feel similarly - program efficiency and readability far trumps, "manual combing" to determine (maybe) exactly which one of 32 bits, "does what!"

    You may perform your own (more fruitful - I believe) experiment by attempting your project using the vendor's API. Do not discount, "Tried, True, Tested and Totally Readable" (i.e. Efficient!) API usage!    Pity that (some) schools reject KISS & Efficiency in favor of the complex...

    In closing - the method of, "poking bits w/in the debugger" (I would bet) stems from past - far less efficient & insightful IDEs - which often existed "devoid" of "real" hardware.   Yet clearly - that's not your case.   (can we say "another" retreat to the archaic?)   When will you graduate to (real) code - which is required by every single employer - and which may be "instantly" confirmed via your readily available Eval board?   That's a far better path - is it not?

  • 0 in reply to Krzysztof Falkowski
    TI__Guru**** 244440 points
    Hello Krzysztof,

    To better understand the code, I would suggest a paper schematic of how you have connected the Launchpad to the LED's?

    Secondly setting 0x00000080 in RCGCCPIO will not enable Port D but Port H. Port D would be 0x00000008 and not 0x00000080

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    But Amit - is not that an especially easy mistake to make under, "DRM?"

    And "not so much" under the superb, far-reaching API.

    If one cannot "light" an LED (via DRM) - please (someone) where is the "bettered understanding" and the "Quantum Leap?" ANS: both reside w/in the API - which proves almost universally, "illuminating!" (ideal for the Led challenged)

    Might the real, "Quantum Leap" result from "exploiting what's commonly  available - proven successful - and far faster/easier & crystal clear?"

  • 0 in reply to cb1
    TI__Guru**** 244440 points
    Hello cb1

    Yes, it is. That is why DRM is not recommended method to code and we have in the past asked users to refrain unless they have a full hold on the device. Amendment to solving the same has started in the next TivaWare release as well.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points
    Perhaps (some) of that "well proven" advice could land in certain, "hallowed halls." (darkened - I may add - due to the over-challenge & complexity of "only" DRM - while an "illuminating" alternative sits hidden - under wraps!)
  • 0 in reply to cb1_mobile
    Prodigy 50 points
    Thank you cb1 for your insight.
    I think the reason this teacher is getting into DRM is to impart deeper understanding of uCs and how they work and later will go on with regular programming in C and using API. That was my understanding so far , and I liked that idea.

    When I have a good grasp of workings of uCs than I will be happy to use API. I just hate the idea of not understanding, at least little deeper, how things work inside. I will get where you are with your philosophy little later, I think. Being a business owner and trying to get a product to the market as soon as possible gives you different perspective on these things.

    On the other hand there might be cases when you would need to make your code more efficient (faster, more compact) and wouldn't knowledge of the DRMs help you in achieving this?

    Anyway, I appreciate your view, however I still would like to know what I was doing wrong. Remember, I don't have to rush with product to the market! :).
  • 0 in reply to Krzysztof Falkowski
    Guru 47900 points

    Thank you for an unusually caring & thoughtful response. Well done.

    To your point - "Wanting to know what you were doing wrong - and getting those Leds to glow."  If the DRM was as powerful as (some) believe - and as useful - would not your Leds be glowing brightly?   (Ours - always under the API - surely are!)
     
     Would not the API (first) - then integrated w/DRM - prove far superior?

    You claim to "hate not understanding" - yet the DRM is hugely complex - demands pages & pages of manual turning/searching - and what (really) will you recall in two weeks?  Where is the "understanding" from the DRM wellspring.   Does western medicine "cast off" all modern advances - so that "MDs in training" - can (really) understand?   ANS: of course not - this is folly!

    The API can teach you as much - nothing requires that you just "cut & paste" via the API - as past stated - you can read/review the unusually good "source code" - and go down to the Register Level as much as you wish. (although this time - thanks to the API - the extra light thrown off by your (working) Leds should better illuminate your path!)

    Learning to use proper tools - and to investigate efficiently - will pay off in multiple life areas.   Blindly accepting & following a "lesser method" - not so much...   I doubt that "good" medical schools so emphasize the archaic...

  • 0 in reply to Amit Ashara
    Prodigy 50 points
    Hello Amit,

    I am dealing with one external LED that I am connecting to the uC's pin so schematic is not necessary.

    I seem to understand now, that it should be 0x00000008 and not ...80. I have no idea how I got this wrong! I was so careful with these bits, drawing tables with bits and converting it to Hex.....

    So acknowledging that mistake, still, why Blu LED would turn On and why the first time I run the C code my LED was blinking in tandem with Blue one instead of at the end of routine, but running the same code the next day would make everything work as it should?
    Also, one day I was able to access 3 or 4 random pins on random ports but next day I was unable to access any.

    I am positive that I was making some kind of mistake, as always is the case, but it would be nice to know what it was.
    It doesn't seem, however, that I will get any answers to it-who would be able to come up with reasons what kind of unpredictable mistakes some newbe made, so lets just forget about it. I will just forge ahead and maybe sometimes in the future I will have better understanding what did I do wrong.

    I thank everybody who took time to answer my call for help and for all the insight that it provoked.
  • 0 in reply to Krzysztof Falkowski
    Guru 47900 points
    You may (one day) come to accept that (both) this forum & ALL small biz must operate w/(some) efficiency to, "Keep the doors open!"

    Developing an exact answer for you - under the burden of DRM analysis - really does not, "rock" our desirability meter... (especially when a so superior method is upon your doorstep - although unadmitted!)
  • 0 in reply to Krzysztof Falkowski
    TI__Guru**** 244440 points
    Hello Krzysztof,

    I would agree with cb1. Move away from DRM to API.

    Also since there is no remnant of code or the object that failed to work, it would be almost impossible to put this puzzle together.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 50 points
    Hello Amit and cb1,

    Thank you guys for your input. I will be happy to do just that as long as I can find any decent tutorial for beginners. This one seemed to fit the bill. Any suggestion on the path to learn embedded for the beginner?
  • 0 in reply to Krzysztof Falkowski
    Guru 47900 points

    Posters & users have widely varying: interests, motivations, skills and objectives. Thus - recommending a "universal best path" - proves difficult.

    Usually - but not always - a mix of personal interest & academic study - done to your serious yet unrushed schedule - works best.  The learning curve w/these MCUs is steep - most require (some) fun to recover from the "fog of learning/battle."   (that's why choosing an MCU based project which overlaps your interests, hobby, or profession often works best...)

    Sustaining that interest and work ethic "does" require regular progress - which as you've noted - does not often (nor regularly) result from "DRM-only" attempts. That's (yet another) justification for the API - which makes your progress, "Faster, Easier, Better!"

  • 0 in reply to cb1
    TI__Guru**** 244440 points
    Hello cb1,

    During the migration of DRM to API for TivaWare, it was being debated that it could be added as another example. But then the level of expertise with the device was presented as a counter argument to the debate....

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Hi Amit,

    In politics, and law, and in engineering - there are most always, "trade-offs." Doing nothing - when the analysis does not reach 100% - may not prove best/brightest.    As young Army Officers - decades ago - we were taught to gather the facts as best we could - weigh each side - and then decide - and ACT!   
     
    "Sitting on the fence" - rather than deciding and launching - too often yields poor results. Being overly cautious - especially when such causes repeated user/client/soldier frustration and disenchantment (or worse) - may reflect, "poor decision-making" which proves sub-optimal...

    (and unfortunately - that condition seems to live/thrive & perpetuate at a place we both know & care for...) ... (that too has been "duly noted.")