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.

TM4C1294kcpdt: XDS100v2 debug program MAC USER1/2 registers

Guru 56033 points
Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL

Getting some strange MAC address returned even after a full erase of  flash. Flashing each USER register separately committing or flashing the entire MAC address writes the wrong data yet the firmware flashes and seems to work even with the odd MAC address. Verified XDS100v2 JTAG test passes several times without any errors.

The odd thing is the first attempt to flash this MCU's MAC partially succeeded then degraded as shown below when the MAC is quarried. Debug USER registers 1/2 have the same wacky MAC written that XDS100V2 reads back.

Any Idea why this happening?

CORTEX_M4_0: Initializing device...
CORTEX_M4_0: Operation completed successfully.
CORTEX_M4_0: Erasing device...
CORTEX_M4_0: Performing Mass Erase on Flash memory
CORTEX_M4_0: Operation completed successfully.
CORTEX_M4_0: Programmed value was committed to User Register 1
CORTEX_M4_0: Operation completed successfully.
CORTEX_M4_0: User Register operation...
CORTEX_M4_0: MAC address value: 0-10-2-0-10-0
CORTEX_M4_0: Operation completed successfully.

  • Recall only partial MAC was written prior to committing USER0/1

    Register 53: User Register 0 (USER_REG0), offset 0x1E0
    Register 54: User Register 1 (USER_REG1), offset 0x1E4
    Register 55: User Register 2 (USER_REG2), offset 0x1E8
    Register 56: User Register 3 (USER_REG3), offset 0x1EC

    Note: Offset is relative to System Control base address of 0x400F.E000.
    These registers each provide 32 bits of user-defined data that is non-volatile. Bits can only be
    changed from 1 to 0. The reset value shown only applies to power-on reset when the register is not
    yet committed; any other type of reset does not affect this register. Once committed, the register
    retains its value through power-on reset. The only way to restore the factory default value of this
    register is to perform the "Recover Locked Device" sequence detailed in the JTAG section.

    So we try JTAG unlock but in CCS debug is a bit tricky since XDS100v2 can not be connected to the target on debug entry. So target can be unpowered on entry into debug or even repowered in debug since XDS100v2 is not connected to the DAP. Yet the unlock procedure fails for unknown reasons.

     

  • Hi BP101,

      Can you tell me what tool you use to perform the mass-erase (unlocking the device) with XDS100v2 debug probe?

  • Hi BP101,
    Sorry, I didn't see your second reply. So you are using CCS. How did you do the JTAG unlock in CCS?
  • Using CCS debug flash utility without connecting to XDS100v2 or flashing firmware on entry to debug, only way it gets this far into procedure.
  • Hi BP101,
    After you complete the mass erase can you immediately check if the MAC address is erased to all F's?
  • That's the first thing tried last night and did not erase the MAC USER areas.
  • Another odd thing is UART3 RIS register FEIS & BERIS are stuck on, set to 1. Both bits will not clear by RWIC, very odd since the MIS is not even setting these bits for Break or Framing interrupts so the TXD (PA5) output stays high. That one is even harder to track down.
  • CORTEX_M4_0: GEL Output:
    Memory Map Initialization Complete
    CORTEX_M4_0: Erasing device...
    CORTEX_M4_0: Performing Mass Erase on Flash memory
    CORTEX_M4_0: Operation completed successfully.
    CORTEX_M4_0: Performing Blank Check...
    CORTEX_M4_0: Performing Blank Check on the following (aligned) memory range: 0x0 - 0x7ffff
    CORTEX_M4_0: Operation completed successfully.
    CORTEX_M4_0: Calculating CRC-32...
    CORTEX_M4_0: The following range was selected: 0x0 - 0x%7ffff
    CORTEX_M4_0: The calculated CRC-32 value: 0x504bf849
    CORTEX_M4_0: Operation completed successfully.
    CORTEX_M4_0: User Register operation...
    CORTEX_M4_0: User Register 0 value: 0x21000
    CORTEX_M4_0: Operation completed successfully.
    CORTEX_M4_0: User Register operation...
    CORTEX_M4_0: User Register 1 value: 0x1000
    CORTEX_M4_0: Operation completed successfully.
    CORTEX_M4_0: User Register operation...
    CORTEX_M4_0: MAC address value: 0-10-2-0-10-0
    CORTEX_M4_0: Operation completed successfully.

  • Hi BP101,
    I have trouble to use CCS's flash utility to perform device unlock myself with XDS100v2 debug probe. Unless the device is truly mass-erased in which case the USER0/1 registers are erased, you can't reprogram the MAC address even though the console might have shown that it programmed something into the USER0/1 registers. The console's output is not correct to me. Do you remember what values were stored in the USER0/1 register as soon as the mass-erase you performed in CCS?

    I will suggest you try dbgjtag.exe to mass-erase (device unlock) the device and then program the MAC address in CCS and see if that works.
  • Hi Charles,

    Same MAC as is in the printout above (Mass Erase) did not flash USER0/1 correctly or at all. Odd thing is the mass erase blank verify put the MCU flash back to factory ROM boot loader mode so USER0/1 should have erased but did not. 

    Also discovered UART3 ISRAW & IMS are not reporting correct info after finally have it transmit data via EK-XL ICDI JP5 header & Widows COM port terminal. It seems the XDS100v2 emulator is refreshing read data in most other peripheral registers without errors and may need an flash update to properly read peripheral registers above UART2. 

    I see an update ICDI listed in debug console but was afraid to flash XDS100v2 and make it fail after doing so. Would that ICDI update be ok for XDS100v2?

  • Hi BP101,

     I really doubt your mass-erase was successful. As far as I know the blank check does not check the USER0/USER1 registers. These are special flash location in OTP section. Can you for experiment purpose try to do mass-erase using dbgjtag.exe. Please see below and replace the xds200 with xds100v2.

      I will suggest you NOT do the ICDI update. I just did with the XDS100v2 connected and below is the console log. The problem is that it rendered my LPad not usable afterward in ICDI mode. I needed to use the LM flash programmer to update the ICDI firmware again for it to work again.

    CORTEX_M4_0: GEL Output:
    Memory Map Initialization Complete
    CORTEX_M4_0: Checking connected devices...
    CORTEX_M4_0: Opening ICDI device...
    CORTEX_M4_0: Checking connected device type...
    CORTEX_M4_0: Checking firmware version...
    CORTEX_M4_0: Connected ICDI Firmware Revision: 12630
    CORTEX_M4_0: Updating to the following version: 9454
    CORTEX_M4_0: Switching ICDI to update mode...
    CORTEX_M4_0: Waiting for ICDI update to connect...
    CORTEX_M4_0: Open ICDI device for update...
    CORTEX_M4_0: Programming ICDI with new firmware...
    CORTEX_M4_0: Closing ICDI device.
    CORTEX_M4_0: Firmware Update completed.

  • dbgjtag is the only way I have erased the MAC address. Otherwise you are just writing 1's to 0's which is a bitwise AND operation of your new value with what's present.

    A GUI would be nice.

  • Had to finally make EK-TM4C1294XL remote MCU ICDI via U6, removing R40 & target JTAG zero ohm resistors. Unlock via ICDI worked to clear USER0/1 in CCS debug and read UART3 IM & RIS where XDS failed. Thanks for verifying XDS100V2 had issues and a few I noted above with UART3 seem less threatening via EK-ICDI connected to target system.

    Decided to power EKXL ICDI via targets 3v3 LDO being no way to stop ICDI 3v3 on U6 pin 1 header into remote target or stop USB from powering target too. A Single 3v3 power from target to supply both systems seems to make CCS flash verify hang and not progress to launch target or the hardware break point is not being cleared from the last hang. Doesn't it sound odd to have two 3v3 power sources playing against each other?
  • BP101 said:
    A Single 3v3 power from target to supply both systems seems to make CCS flash verify hang and not progress to launch target or the hardware break point is not being cleared from the last hang.

    Required checking box to reset target on ICDI connect even though reset target after program load had been checked, CCS debug would not jump to programs main even though checked too. That reset target on connect checkbox was not required with XDS100v2, there are minor differences between the flashing techniques of each of the emulators.