• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 1179 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.

TM4C1294NCPDTI3: LM-Flash fails to halt ICDI running DAP after WDT1 was recently added & completely removed.

Genatco
Guru 55913 points
Other Parts Discussed in Thread: TM4C123GH6PM

Recently enabled configured the WDT1 watchdog timer and forgot to enable the peripheral. After LM reset MPU the Fault LED was flashing so fast it was hardly visible.

Removed all WDT1 configurations, cleaned the build, re-compile application and LM-Flash being very difficult to program the Launch Pad.

Unlocked the DAP programed MAC user registers then erase entire Flash, program the Boot Loader then Application with no trouble.

Long story short: It is now only possible to LM flash launch pad between two very rapid back to back hard MPU resets when ever the MPU is executing the program.

Consequently if LM (reset MPU after Program) is !checked then programs flash repeatedly without having to force several manual hard resets. 

If the application is running having to hit return key LM rapidly, program rapidly cycles in order to randomly flash Launch Pad.

The MPU is being soft reset every time prior to the beginning of each program cycle that fails. The application can no longer save parameter blocks to flash invoking (flash_pb.c) and that only soft resets MPU no writes of parameter. BTW: The application uses WDT0 load/reset and that dog still works great and EEROM writes and reads succeed.

Has this TM4C1294 MPU been damaged internally or does the TM4C123 ICDI need to be re-flashed?

Why would enabling the WD1 Timer bake the MPU or set some kind of issue that resetting the DAP can not fix?

  • 0
    TI__Guru**** 244400 points
    Hello BP101

    Unlock Sequence is the mechanism to recover the device. None of the devices should be damaged... as the entirety of the operation is in SW.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Hi Amit,
    Did unlock 4 times getting very same results. Think this engine has a couple fouled spark plugs now.

    Guessing CMOS excessive current draw could be the culprit here. MPU still online to IOT with a new CIK but has several issues especially in asserting Flash peripheral from the application. Even try to set disable WDT1 peripheral in SW renders the same results. Seems this MPU is either toasted, even the ICDI TM123 has been compromised.
  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101,

    When you connect the board, does the Device Manager show the ICDI or does it detect an unknown device? May be time to try the ICDI Firmware button

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

    May I add that these MCUs prove to be pretty tolerant little beasts?

    Do follow Amit's keen guides - we've (really) abused several - and most have survived - continue to operate (in our shop) today.

    May I suggest the (temporary) replacement of your large/complex program w/a short/sweet factory approved one? In that manner - one peripheral at a time - you may be able to secure order! (we've succeeded - doing just that)

    Perhaps Amit can confirm - yet it's hard to imagine any programming error causing the destruction of your ICDI MCU.    In your haste/desire to "restore" you may have done something to "disturb" the ICDI's program - but it's hard to see chip level destruction as the outcome...

  • 0 in reply to Amit Ashara
    Guru 55913 points

    does the Device Manager show the ICDI: What tab if is important?

    Message popup dialog box states "Unable to innate device-0!" That message is not displayed upon striking the enter key rapidly. So it take one mouse click to start the sequence then hit enter key (program) cycles write mode in a loop.

    LMFP eventually programs the device hitting enter key whilst rapidly pushing reset button! The strange part is WD1 uses ALTCLK-PIOS source, REG8 WDTCL is restricted to writes during GAP, never between to back to back reads. After the WDT1 is configuration is removed the DAP seems to have morphed to the GAP restriction of WDT1, but how can that be. ;-)

  • 0 in reply to Amit Ashara
    Guru 55913 points

    "May be time to try the ICDI Firmware button" Didn't help several times reloaded ICDI. 

    See a pattern: LMFlash all versions might should issue a HALT instruction to stop the application loop during program mode assert. When the processor is idle LM Flash connects to the DAP every time and can program the device repeatedly if (reset device after program) is unchecked. 

    Same behavior of the DAP entering CCS Debug, flash erase IPL often hangs on first attempt then succeeds every time when the MPU is idle.

    Many posts this forum over past year having similar issue depending on what program lines are first asserted in the entry of the application. We have a 1 second delay added then clear out any encountered NMI faults after which most all peripherals have been initiated then the application launches into hyper space.

    Even that delay may some how be compromised by the recent WDT1 addition, now removed.

     

  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101

    It would be worthwhile to condense your test to a small code that we can replicate on our side.

    Regards
    Amit
  • 0 in reply to cb1
    Guru 47900 points

    cb1- said:
    May I suggest the (temporary) replacement of your large/complex program w/a short/sweet factory approved one?

    Let the record show both Amit & this reporter suggest similarly...

  • 0 in reply to Amit Ashara
    Guru 55913 points

    Point is the TM4C1294NCPDTi3-XL and LM-Flash 100's of times prior but on the rare occasion would refuse to flash the Launch Pad device.

    Now testing a (brand new board) behaving the same way. Pattern symptom releasing reset exactly in sync with pushing program button LM-Flash often succeeds to erase/flash. Guessing the DAP wins the race over the ARM to take priority of the flash memory in that scenario.

    Observation reveals this to be a hardware related timing issue while invoking the DAP.

    Best practice: Seems the DAP should halt the MPU execution decode cycle prior to ever invoking the DAP regardless of SW that may be running. Attempts to access the DAP in reset cycle while the MPU is in execution decode is like playing Russian Roulette. Try experiment setting a boards (Systick=SYSCLK / 200) and another periodic timer (SYSCLK / 100)  and see how easy the ARM gives his priority to the DAP.

    Simply resetting the DAP is not fool proof: Upon entering CCS debug often get error (Frequency out of range). Did Experiment setting the (target_.ccxml) ICDI as TM4C123GH6PM 16Mhz. That worked flawlessly one time upon entering debug, simulator erased necessary pages then loaded the entire 1.01Meg *.Out file. The next time entering debug "Error frequency out of range."

    Could it be TI engineers have been getting lucky all this time?

  • 0 in reply to Genatco
    Guru 47900 points

    While you've been kind enough to "Like" both Amit's and this reporter's suggestion to, "Employ a small, simple test code" it remains unclear if you've, "Done such!"

    Minus that report - your last (borderline, vendor-attacking) sentence is unfounded - likely unwise.       (edit button exists for such "excise" purpose)

    Of course you're frustrated - yet certain of your methods appear to reach far - flirt w/witchcraft...

  • 0 in reply to Genatco
    TI__Guru**** 244400 points
    Hello BP101,

    Not really lucky but depends on the JTAG procedure. At factory we have multiple tools being used (some more frequently than other) to test the 1MB Flash and so far no tool has broken when downloading code. Of course it assumes that the underlying flash has not been programmed 100's of times, which may affect some of the bit cells. The 100's of time is not yet quantified in your post v/s data sheet. Ot could be some of the sector may have been seeing it 1000's of time wakening the flash cell.

    That is why the suggestion to use a simpler code.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 55913 points
    Seems a halt instruction benefits more time for the main oscillator cool down meshing precisely with DAP/ACK at this incredibly fast MPU clock speed. It really shouldn't matter what SW is loaded the DAP should OBEY the command and it fails every time. The procedures and tools used to flash the device should be bullet proofed and quite obviously they are not. We are the messengers back to engineering when something is behaving oddly it usually means human error is involved. This a good thing not meant to be condescending but will end up in a better working and hardened system.

    Added a 2 second delay after the main MPU clock is configured gives time for hard reset and user to click on program button before the application fully engages. Not sure what changed so suddenly other than program having a few more bytes for WDT1 and later optimized the program speed to level 3. Thought it might be the bulk USB driver so uninstalled it but still had same issue.