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.

TM4C1294NCPDT: TM4C1294NCPDT not boot without ICDI debugger ou a manual RST assert to GND

Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: ENERGIA

Hi,

We are using Tm4C1294NCPDT with a custom board and We are having some trouble with the boot process. 

The boot only runs the internal flash code if we have ICDI debugger connected to board or if assert manually RST pin to GND after the POR process.

Could anybody face the same issue? Thaks.

  • What is your reset circuit? Do you have a supervisory IC on the power (always recommended, the simple passive circuits are somewhat trouble prone)?

    Robert
  • Hi

    Yes I am using MCP100 as supervisory IC.

    It is ok. I measue its signal with a oscillopscope. The rst pin Góes high after 200ms the power is on.

  • Hello Leticia

    Can you check the image file to see if it is correctly being located at 0x0 address of the flash?
  • Hi, I check the binary file and I can read some bytes starting at 0x0000 address. 

    I know that the initial code is about boot, that is right?

    Thanks.

  • Hello Leticia

    Yes, the location 0x0 and 0x4 contain the Stack pointer (SRAM location) and PC (mapped to flash).

    Since it is an issue when running after reset/power-on, but not under debugger control, the issue is most likely to be an incorrect programming of the first two locations. I would suggest to do the following

    1. When you load the program under debugger control and perform a CPU reset using the CCS CPU reset button, what does the PC show the value as?
    2. Does the code run well if a CPU reset and a System reset is done using Code Composer Studio?
  • Hi Amit,

     I´ll try your suggestion and give a feedback as soon as possible.

    Thanks

  • Leticia Gomes said:
    boot only runs the internal flash code if we have ICDI debugger connected to board

    As your management of MCU "Reset" appears correct - might you have left the JTAG pins, "floating?"   (for instance - you rely upon the "too high resistance" of MCU's internal pull-up R's which attach (maybe) to JTAG)

    Properly valued, closely placed, (real) external pull-ups prevent many such issues.

    Also it proves wise to (really/systematically) check the power/ground connections @ the MCU.   And insure that your 3V3 Regulator has sufficient capacity for task.   Viewing that voltage @ the MCU proves useful.

    There's no mention of any, "Off board" connections.   None should be allowed at this stage in your "Test/Verification."   Everything is suspect - especially any switching supplies (on board/nearby) - and the presence of high speed switching signals - should they route too close to sensitive MCU pins

  • Amit, the behaviour would not be different for a reset after power on vs a Power on reset would it? Surely the micro behaves the same in both cases.

    Robert
  • Good, how stable is the supply?

    Robert
  • Hello Robert,

    Quite often I have seen loading via debugger causes the PC to be set to the PC location as set by the application code (at the non 0x0 location). Folks disconnect and reload the application and see it to be working under debugger control, but not when a CCS reset is done or the device is powered on.
  • Yes but the OP claims it works when reset but not on POR. It was pretty explicitly a manual reset so CCS was not involved. That suggests either power or as cb1 suggested some interference from connected circuitry.

    It could be that the program is starting and then wandering off because the program has encountered an input condition it is not proofed against.

    Or maybe the IC doesn't work as expected and POR and reset by pulling reset to ground behave differently. I think that's unlikely.

    Robert
  • Or possibly, the OPs report was mistaken and pulling reset to ground doesn't cause the program to work either.

    Robert
  • Indeed - and each/every "custom board" will be forever "suspect" - and subject to (dreaded) single board anomaly. Never are we told: "N" boards have been built - and "M" have been tested - and present identical results/findings...

    Vendors ill placed "belief" that posters cannot benefit from written guidance is the (largest) factor here in need of (real) Reset!

  • Yes, multiple boards necessary here, a bad solder on the supervisor would be enoungh to explain this.

    Robert

  • Hi,

    I'm still trying here but nothing. Thanks for suggedtion about to try another board. The problema is it is a prototype and I don't have a clean pcb. I will send you some signals I 've measure with scope. The issue is I can not use debugger. When I run the code in debugger mode it works fine.

    Thanks.

  • Hi guys, I´m back to lab today trying to get my board works. So, I will teste another board to check if it is a single problem or not. There is a new information. I program a simple code at the same board using Energia and It works fine with POR. My complete code uses Ti_RTOS and several peripherals... I am guessing that some initialization is locking the MCU. I look at datasheet and user guide for some signal I could measure to check if the boot process is ok or not, clkout or something like that but I have no success. Do you know anything about a signal (not a GPIO)? Thanks.
  • Hi... some updates...
    I found another way to boot the MCU and runs firmware. With ICDI connect and using LM Flash Programmer, if I send a command to get current values of User Register Programming the code works fine. But If I power off the board and power on again not.
  • Leticia Gomes said:
    There is a new information. I program a simple code at the same board using Energia and It works fine with POR.

    That's a pretty good indication there is likely a SW issue (could be made worse by HW, so still worth testing another board)

    Leticia Gomes said:
    Do you know anything about a signal (not a GPIO)?

    GPIO would be simplest and most sure. If you have a serial ouput you can ignore or some other pins you are not using that's the route I'd be tempted to use. Even if you have to tack on flywires to probe it is likely useful.

    Basically if there is a pin you can waggle to indicate progress the micro will have used it as an I/O. There are "serial" channels on the debug port but since connecting that cures the problem they may not be much of an option.

    Finally if you have a serial port connected you can co-opt it and send progress messages.

    Probably the most important place to put a serial output would be your exception vectors. If you ever reach those a little routine can dump the exception information.

    Robert

  • Do you know where I can find exception vectors in CCS? I'm using TI-RTOS and I could not find them. Thanks.
  • Hello Leticia,

    Leticia Gomes said:
    Do you know where I can find exception vectors in CCS? I'm using TI-RTOS and I could not find them.

    As far as I know, TI-RTOS moves the exception vectors into SRAM. I have not yet figured out where they are moved. It would be better to post on TI-RTOS forum here: 

    Thanks,

    Sai

  • Overheard:

    Gunney: - "bad guys @ 3 o'clock!"
    Crew Chief: - "Nah - that's Bravo's fire sector."

    We'll (surely) solve this "needle w/in haystack" by adding MORE hay!

    KISS is supremely in violation here. RTOS, Energia, awol Exception Vectors ... AND a SINGLE, Custom pcb.

    Would not an especially basic program (blink a single Led) - NOT burdened w/(laundry list items (above)) - establish the "reality" of POR issue?

    "One small step for Leticia - one giant step for MCU board troubleshooting...