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.

TM4C123GE6PM: Unable to flash micro after the first time

Part Number: TM4C123GE6PM
Other Parts Discussed in Thread: TM4C123GH6PM, , EK-TM4C123GXL

Hi,

I have a problem where after flashing the micro in a custom board for the first time, I can't either debug nor program it again. 

I'm using TI-RTOS (2_16_00_08) and I've created my project in two ways to see if there was any difference, but unfortunately the result is the same.

One way is importing an example from the Resource explorer and modify it to my selected micro. Since the examples are meant to be for the TM4C123GH6PM, I change the device and linker command in the general tab of the project properties (to the micro I'm using TM4C123GE6PM) and also the flags in the XDCtools tab. 

The other way is creating a project from scratch for the selected device, selecting an empty RTSC project option, selecting the appropriate linker command file and the correct platform in the XDCtools platform option (ti.platforms.tiva:TM4C123GE6PM). After creating a new .cfg file, importing my code and compiling correctly I've the same result. I can flash the micro once, but after trying one more time, I get an error. The only way I can access the micro again is using the LM flash programmer and do a Debug port unlock. Obviously, this is a temporary solution.

There is obviously something not right and I've not been able to figure what it is. I'd appreciate your help on this.

Best,

Alberto. 

  • Hi,

      Your screenshot shows you are unable to even connect to the target device. I don't think the problem is with the software. You can easily try the same examples on a LaunchPad. The screenshot also shows you are using Stellaris ICDI debug probe. How are you using a ICDI debug probe and where did you get it? Are you using a LaunchPad as a ICDI debug probe to debug out your custom board? Do you have a standalone debug probe that you can test out your custom board? There are some low cost probes like XDS110 and XDS200 that I normally suggest to customers. 

  • Hi Charles,

    I'm able to connect to the target device the first time. Then I'm able to program it, but after flashing it for the first time, I get that error message if I try to program it it again. I'm using a EK-TM4C123GXL as the debug probe to flash the target device and I also have used a XDS110 and the result is the same. The problem is not the debugger/programmer. 

  • Can you load a simple example like blinky or hello? Do you see the same problem after the first successful flashing? I want to know if it is software dependent. Please try XDS110 instead of EK-TM4C123GXL to debug your custom board until we narrow down the problem cause. 

    Try these examples and see if you can repeatedly program them. 

    You can find the examples in C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c123gxl\blinky

    C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c123gxl\hello

  • The examples you are proposing are intended for the launchpad, which comes with the TM4C123GH6PM. The device I'm using in my custom board is the TM4C123GE6PM. I've tried the blinky example (the one using tivac libraries), modified for my device and I'm able to program the board several times with no issues. 

  • But, when I use a RTSC project(TI-RTOS), from scratch or take an example from resource explorer and modify the device to match mine, then I encounter the issue 

  • TM4C123GE6PM and TM4C123GH6PM are identical in terms of peripherals and pinouts. The only difference is that TM4C123GE6PM has only 128kB of flash as opposed to 256kB on TM4C123GH6PM. You should be able to take any TI-RTOS example and load it to your device. If you use a TI-RTOS stock example as is without modification, do you see the issue? None of the examples will take up more than 128kB. 

  • That is correct regarding the difference between the processors. I tried compiling projects with both devices as I mentioned before, to rule out the possibility of that being the issue. The examples you proposed, as I explained, use TIVA C libraries and they work ok on my custom board. When TI-RTOS examples are used, they come with files that are specific to the board used. By default they come with EK-TM4C123GXL.h and EK-TM4C123GXL.c (since it's targeting the launchpad). This files contain the configuration of the peripherals, initialization, etc. Since I've got a custom board, I have a modified version of those files to declare what peripheral will be use in what pins, etc accordingly to my design. All this is to say, that common examples with tivac libraries work ok, but with TI-RTOS does not. 

  • In a few words, using TI-RTOS and programming my board locks the device every time

  • This files contain the configuration of the peripherals, initialization, etc. Since I've got a custom board, I have a modified version of those files to declare what peripheral will be use in what pins, etc accordingly to my design. All this is to say, that common examples with tivac libraries work ok, but with TI-RTOS does not. 

    Hi,

      I have yet to know what went wrong. Can you show exactly what you change?

      You have not answered me if you take a stock TI-RTOS example (the one that targets the EK-TM4C123GXL board) and just load the .out into your custom board, will it work?

  • If I load a stock .out that targets the EK-TM4C123GXL, it still locks.

  • That is certainly very weird. As I mentioned the only difference between TM4C123GE6PM and TM4C123GH6PM is the flash size. Everything else is identical. I can't image a stock TI-RTOS example would not work on TM4C123GE6PM. 

      Can you tell me:

      - How many custom boards do you see the problem? All of them of just one of them?

      - Which example did you use? 

      - Does the example you use are using certain pins that are available on the LaunchPad but on your custom board these pins might be tied low or high or to some other components on your board? In another word, I want to know if some type of drive conflicts is present. 

      - Can you try the attached hello.out file? This example will not use any pin but just printing Hello on the console window. 

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/hello_5F00_EK_5F00_TM4C123GXL_5F00_TI.out

  • I've tried in 3 boards so far. Same result. I've used several examples (GPIO, hello world, blinky, etc) all with the same result. Also, the GPIOs can be changed to match my design in the files EK-TM4C123GXL.h and .c as I explained in a previous post. That's does not seem to be the problem.

  • Ok. I kind of run out of ideas. I suppose all of these examples work on the LaunchPad, correct?

    The below are data points I gather so far. Correct me if any one is not correct. 

    - Custom board works fine with non TI-RTOS examples (e.g TivaWare SDK examples). 

    - Custom board cannot program and connect the second time after a stock TI-RTOS example without modification is loaded.

    - The same TI-RTOS examples work fine on your LaunchPad.

    The only thing left I can think of is to do a ABA swap test. You can swap the TM4C123GH6PM from the LP to you custom board and the TM4C123GE6PM on your custom board to the LP. What is the result? I can't think of any other suggestions as I have not come across an issue like this in the past. 

  • One more question. Are you using the crystal and MOSC? 

  • The data points you gather are all correct.

    I've diverted my attention to a different front. In my custom board I didn't use external crystals/oscillator. The rationale is that the device has an internal oscillator PIOSC (16 MHz), so an external source for the main it's not necessary. For the RTC, an external oscillator of 32.768 kHz is only necessary if the hibernation module is used, which I assumed I wouldn't need it. Do you think that might make TI-RTOS go nuts for some odd reason?

  • I think that might be the reason. TI-RTOS uses MOSC as the source clock to generate the system clock. Since you use PIOSC then it can't load the second program the second time as your running program is expecting a functional MOSC. I think you will have the same problem if you were to run the TivaWare SDK example that uses MOSC to generate SYSCLK. Why don't you try C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c123gxl\hello. It has the below snippet of code that configures SYSCLK based on MOSC. 

    int
    main(void)
    {
        //volatile uint32_t ui32Loop;
    
        //
        // Enable lazy stacking for interrupt handlers.  This allows floating-point
        // instructions to be used within interrupt handlers, but at the expense of
        // extra stack usage.
        //
        MAP_FPULazyStackingEnable();
    
        //
        // Set the clocking to run directly from the crystal.
        //
        MAP_SysCtlClockSet(SYSCTL_SYSDIV_4 | SYSCTL_USE_PLL | SYSCTL_XTAL_16MHZ |
                           SYSCTL_OSC_MAIN);
    
        //
        // Enable the GPIO port that is used for the on-board LED.
        //
        MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOF);
    

  • That exactly what's happening. If I load the .out as is, I get the same issue. If I change the clock source to SYSCTL_OSC_INT the problem goes away. I've looked in the .cfg to see if I can make TI-RTOS to use PIOSC, but it seems like there is no way. Do you know a way to achieve this or is it mandatory to use an external oscillator with TI-RTOS? 

  • I was also looking for a way to manually change to PIOSC. See below. Bring up .cfg using XCONF. In the Available Products, search for Boot. You can then select PIOSC and disable MOSC. 

  • That works! Thank you Charles!!