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.

EK-TM4C123GXL: Defective Boards.

Part Number: EK-TM4C123GXL
Other Parts Discussed in Thread: UNIFLASH

Hello,

I just ordered 5 EK-TM4C123GXL. from  the TI store. I plugged in the first one to the USB port, it doesn't even light up at all. I tried a different USB port, I get the same result it doesn't power up.Two other boards,. I programmed them once with Keil, using a working software that I used with other boards. The programming went well the first time but failed  the second time I tried to program them again. , I got the "could not initialize the target device", I tried to erase the flash by using the LM flash programmer. Build 1613, no luck at all. Can I send back those board for exchange?

Thank you

Hani

  • There are 2 micro USB ports that can supply power to the dev kit. The slide switch selects between the two. I'm not sure if if the boards are programmed to do anything out of the box. Do you see anything appear on your PC's device manager when you plug them in? Even without the driver, something should appear.

  • Sorry to hear you are having issues. The TI Store return and refund policy is posted here:
    www.ti.com/.../faq-returns-and-refunds.html
  • Hello,

    I'm using the USB port in the right of the switch, it is up top between the switch and the debugger chip. I'm not using PD0, PD1, PB6 and PB7. I'm not really sure why TI is putting R9 and R10 resistor, I find it kind annoying to have to remove those two resistors each time I want to use those 4 pins.
    No I have my 4th board doing the same thing. The only thing I changed in my software is port C initialization, I'm using only pin-4 to pin-7. Do you see anything wrong with the way I initialize Port C:

    void PortC_Init(void){

    volatile unsigned long delay;
    SYSCTL_RCGC2_R |= 0x04; // 1) activate Port C
    delay = SYSCTL_RCGC2_R; // allow time for clock to stabilize
    GPIO_PORTC_LOCK_R = 0x4C4F434B; // 2) To unlock GPIO Port D,C nd F write this value 0x4C4F434B; // 2) no need to unlock PB7-0
    GPIO_PORTC_CR_R |= 0xF0; // allow changes to PC4-7 The others are used JTAG on the board
    GPIO_PORTC_AMSEL_R =0x00;
    GPIO_PORTC_PCTL_R =0x00;
    GPIO_PORTC_AFSEL_R =0x00;
    GPIO_PORTC_DIR_R |= 0xF0; //Output PC4-PC7
    GPIO_PORTC_DEN_R |= 0xF0;


    }
    Thank you
    Hani
  • Hello,

    I'm not sure I understood your return policy, The policy has mention: " For purchased ICs, the warranty is for three years from ship date. " and also mention "There is no refund allowed for purchased ICs.". Is that means if I send them back, Ti is going to exchange them, repair them or nothing at all. I know the boards are not expensive at all, but its really annoying to see 4 boards going out so fast like that, actually one of them didn't power up at all out of the box. One more thing I would like to mention, the LM flash programmer, I find out that once keil can't program the board, then the LM flash programmer can't do a thing to help. I wish the LM flash programmer can force the board to be erased and reset it to factory state in a more successful way.
  • The EK-TM4C123GXL falls under "For Tools, EVMs or development kits, the warranty is for 90 days from ship date." Both Code Composer Studio and UnifFlash now support unlocking the TM4C123G part on the EK-TM4C123GXL. These are newer tools than LM Flash Programmer.
  • Hello again Bob,

    Where can I find the flash images for the ek-tm4c123gxl to be used with UniFlash.

    Thank you,
    Hani
  • Poster's "pain" is (somewhat) felt - yet not (fully) undeserved!     Let's all hope that,  "All FIVE LPads CAN be RECOVERED!"

    Having, "FIVE out of FIVE" LPads - "DOA" (Dead On Arrival) is statistically  (Off the Charts - UNLIKELY!)     Thus (some) attention must turn to, (pardon) "Poster's Handling and/or Programming."

    And Voila - "Crime Scene, Murder Weapon,  and Trace Blood Evidence" - all, "Jump Out" - landing at the feet of  (Homicide Detective) Crüe!

    First - presented here - the "Bloody Crime Scene:" 

    void PortC_Init(void){ 

    volatile unsigned long delay;
    SYSCTL_RCGC2_R |= 0x04; // 1) activate Port C
    delay = SYSCTL_RCGC2_R; // allow time for clock to stabilize
    GPIO_PORTC_LOCK_R = 0x4C4F434B; // 2) To unlock GPIO Port D,C nd F write this value 0x4C4F434B; // 2) no need to unlock PB7-0
    GPIO_PORTC_CR_R |= 0xF0; // allow changes to PC4-7 The others are used JTAG on the board
    GPIO_PORTC_AMSEL_R =0x00; 
    GPIO_PORTC_PCTL_R =0x00; 
    GPIO_PORTC_AFSEL_R =0x00; 
    GPIO_PORTC_DIR_R |= 0xF0; //Output PC4-PC7
    GPIO_PORTC_DEN_R |= 0xF0; 
    }

    And now - the  "Murder Weapon:"

    GPIO_PORTC_PCTL_R   = 0x00;         Note the "bloody knife" (the "=" (assignment)) used in place of the SAFER "|="
    GPIO_PORTC_AFSEL_R =
    0x00;

    And lastly - the "Trace Evidence:"        Note that (both) "GPIOPCTL and GPIOAFSEL" have been CLEARED by Poster!     Chart (evidence) below reveals both Registers - w/regard to PC0-PC3 - must be "1".

    Might this be yet ANOTHER CASE - where the "extraordinary  EFFORTS" demanded by "DRM" ...  have "DONE IN" (another) poster?       ("GPIODEN" is "unknown" - as its "update" was "safe.")

  • "I just ordered 5 EK-TM4C123GXL. ...Can I send back those board for exchange?"

    if one or two boards went bad, it is bad luck;

    if five boards went bad, you are / your code is the bad luck.

  • Danny F said:
    if If five boards went bad, you are / your code is the bad luck.

    NOT Conclusively!    The "Failure Number" - as a "Percent of Population" - (as detailed, above) provides a (far) better measure.

    As the, "Failure's Instrument/Method" (multiple, mistaken, Critical Register Settings) has been (earlier) identified - as has its, "Motive/Cause" (Use of the "Error Prone DRM") - the "CAP-Deprived" writing appears w/out (much) merit...

  • Thank you very much, it helped.
  • Thank you Bob for all your help. I was able to erase the flash, for some reason, I could not unlock the board with Uniflash, I had to first unlock it with LM flash programmer, then erase it with Uniflash. With LM, I was able to unlock only but not erase, with Uniflash I was able to erase but not unlock. Am I doing something wrong, or what you thing is going on?

    Thank you again
    Hani
  • Thank you very much, I think it was port C initialization that caused the issues. But, I still have one board that does not power up at all. I'm not going to worry about one board.

    Thank you again.
    Hani
  • Thank you - Do try the "Board Recovery Method" and be patient - you must follow (all) "Recovery Instructions" EXACTLY! (holding the reset switch - (assuming its available) appears mandatory - during the recovery process.)

    Your use of the forum search box (atop this page) upon your entry of "MCU Recovery" - should produce MANY "Guiding Posts..."
  • Yes I agree.
    Thank you
  • Well done CB1. Thank you!
  • Thank you, Bob. As stated - the "Mind Numbing" aspects of "DRM" must be taken into account - and offered up, "In Counter" ... to the (always) alleged - yet never documented - "Learning Enhancements" (teased) by DRM.

    It should be noted too - "NOTHING precludes API Users"- from reviewing the "Key Registers" in play w/in their "Assembly of API functions" - which further erodes the "Mirage-like" value - of DRM...
  • Hello Hani,

    Quick check for your one board which doesn't power-up: Is the switch set to DEBUG correctly? If not, the power LED won't light when plugging into the top USB port.