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.

Hanging on WDT disable or reset

Hi All,

This is from the Starterware forum; see:

http://e2e.ti.com/support/embedded/starterware/f/790/p/294382/1027405.aspx

This may be chip-related:

In the Starterware bootloader, the first thing it always does is the following
four lines in BlPlatformConfig():

HWREG(WDT_1_REGS + WDT_WSPR) = (unsigned long)0xAAAA;
while(HWREG(WDT_1_REGS + WDT_WWPS) != 0x00);

HWREG(WDT_1_REGS + WDT_WSPR) = (unsigned long)0x5555;
while(HWREG(WDT_1_REGS + WDT_WWPS) != 0x00);

There is some voltage setup, but that is module-dependent, and not always done.
There is only BL_init before that, and that just sets up the stack and clears
BSS; there is nothing in there that has anything to do with the watchdog timer.
So why should the above hang when I try it in on my board? I can run a lot of
code.
I even tried MSR cpsr_c, #MODE_SYS|I_F_BIT
in my init code, in case the extra |I_F_BIT did something.

I tried the assembly language for the above four lines in my init code:

// 19 /* Disable the WatchDog Timer - writes documented in the TRM user guide */
// 20 HWREG(WDT_1_REGS + WDT_WSPR) = (unsigned long)0xAAAA;
  LDR R0,=0x44e35048
  MOVW R1,#+43690
  STR R1,[R0, #+0]
// 21 while(HWREG(WDT_1_REGS + WDT_WWPS) != 0x00);
??WDT_Disable_0:
  LDR R0,=0x44e35034
  LDR R0,[R0, #+0]
  CMP R0,#+0
  BNE ??WDT_Disable_0
// 22
// 23 HWREG(WDT_1_REGS + WDT_WSPR) = (unsigned long)0x5555;
  LDR R0,=0x44e35048
  MOVW R1,#+21845
  STR R1,[R0, #+0]
// 24 while(HWREG(WDT_1_REGS + WDT_WWPS) != 0x00);
??WDT_Disable_1:
  LDR R0,=0x44e35034
  LDR R0,[R0, #+0]
  CMP R0,#+0
  BNE ??WDT_Disable_1

It hangs on the first STR R1,[R0, #+0]

Any ideas?

  • I am skeptical of blaming it on the chip, but I have an experimental micro, XAM3359ZCZ, therefore silicon rev. 1.0 as well. It may be something about setup, but the Starterware seemed pretty simple.

  • Any ideas?

  • I am skeptical that the problem is the XAM3359ZCZ micro on my new board, since
    the code runs on the TMDXEVM3358-SK-LCD EVM module, and that also has an
    XAM3359ZCZ, the experimental micro, silicon rev. 1.0.

  • 1614.Bootloader.zip

    I managed to get the bootloader from Starterware into my new board, including
    BL_init.s for the evmskAM335x in EWARM, but it still hangs on the Watchdog
    disable, HWREG(SOC_WDT_1_REGS + WDT_WSPR) = 0xAAAAu;. I'm attaching the code,
    modified slightly from the original Starterware. Any ideas?

  • Trying other code, I also get a hang on writing to a different hardware register.

  • In the IAR debugger, the SOC_WDT_1_REGS + WDT_WSPR area comes up all dashes, blank, meaning that the debugger can't read the area. IAR tech support says that it should be able to read that area, since those areas seem to be listed as R/W in the TRM. That specific address = 0x44E3 5000 + 0x0x48 = 0x44E3 5048. What kind of problem can cause this?


  • The specific 4kB of WDT1 registers from 0x44e3 5000 to 0x44e3 5fff the debugger can't read, but before and after that area, it can.

  • The code that I previously attached, basically Starterware, runs on the EVM and
    gets through the "HWREG(WDT_1_REGS + WDT_WSPR) = 0xAAAAu;" line no problem. The
    same with a new version of that bootloader that I am building. The debugger can
    read the memory area in the EVM, but not in my new board. I can write a value to
    that register in the EVM, but when I try it on my new board, I get "Blocked
    misaligned 1-byte SFR write access at 0x44E35048, 0 byte(s) into 4-byte SFR at
    0x44E35048".
    The only change when I run it on my new board is the change from the "TI XDS
    100v2 USB Emulator" to the "I-jet/JTAGjet" in my debugger. It seems hard to
    escape the conclusion that there is a hardware problem in my new board. What
    kind of hardware problem could cause this?

  • Also, of course, the Starterware bootloader is supposed to run standalone, with no debugger macro setup, because it is supposed to be just run off of a MicroSD card, right?

  • Checking CM_WKUP_WDT1_CLKCTRL, I find
    Offset 0xD4 from CM_WKUP: 0x44E0_0400, so 0x44E0_04D4 = 0x44E004D4 .
    From that address, reading up, D4, D5, D6 and D7, I read: 02 00 03 00. That is
    little-endian, so the byte order is reversed for normal reading: 00 03 00 02.
    Referring to the TRM, 8.1.12.2.53 CM_WKUP_WDT1_CLKCTRL:
    IdleSt 3 = Module is disabled and cannot be accessed.
    ModuleMode 2 = Enabled.
    Does the disable of IdleSt take precedence over the ModuleMode?
    What enables or disables the entire WDT1 module? Something in hardware?

  • That is the question. What else needs to be enabled before I can use CM_WKUP_WDT1_CLKCTRL? Is this a hardware problem?


  • lets track this this thread in StarterWare forum.