Hanging on WDT disable or reset

Hi,

The hang you are seeing is because the soft reset of WDT is not completed. Can you inlcude the bl_init.asm file and check?

Regards,

Jeethan

I am trying the bl_init asm code, but the IAR debugger does its own, very similar initialization. Why do you suspect that the bl_init code is what is needed?

Other code can run, and I can successfully initialize GPIOs, for example.

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 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.

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.

Hi,

It seems that the Clock to the WDT module is not enabled. Usually when the debugger is not able to read the memory space of a module then the module is probably not clocked.

To check if WDT 1 is clocked can you check for the status of this register -

At the same time can you check the sequence of WDT configuration by taking reference from the wdtReset e.g. of EVM-SK?

Regards,

Jeethan

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 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?

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".

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 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?

>>"Does the disable of IdleSt take precedence over the ModuleMode?"

'IDLEST' field is a status field and 'MODULEMODE' is a control field.

If MODULEMODE=enabled and IDLEST=disabled, it means you are trying to enable the module by writing to the control field, however the status of the module is still disabled. (Not sure why). and hence you are not able to access WDT1 registers.

Regards

Sandhya

>however the status of the module is still disabled. (Not sure why)

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

I suspect your functional clock to wdt1 is not setup properly. The func clock of wdt1 comes from per pll - M2 divider.

You need to ensure per pll and m2 dividers are configured properly as done in StarterWare code.

Refer below,

I can try the CLKSEL_WDT1_CLK register, but meanwhile it sure doesn't look like
it has to get set up in the Starterware version of the bootloader. The four
lines:
HWREGL(WDT_1_REGS + WDT_WSPR) = (unsigned long)0xAAAA;
while(HWREGL(WDT_1_REGS + WDT_WWPS) != 0x00);
HWREGL(WDT_1_REGS + WDT_WSPR) = (unsigned long)0x5555;
while(HWREGL(WDT_1_REGS + WDT_WWPS) != 0x00);
are very early in that code, and I can't see any WDT setup or PER PLL and M2
divider configuration prior to that. Is there any? Where? As I have noted, the
bootloader runs in the EVM SK module, but not in my new hardware, and the only
other difference is the debugger driver that I change in Project Options; I'm
not using any debugger macro because the bootloader has to work stand-alone.

is the board stable...were you able to run diagnostics on your board.

Since it is handling at startup itself, we need to make sure the board is in good condition. Can you run some regression tests on the board ?

Also i see that you have used HWREGL in your code. what does 'L' stands for ?

The four lines:
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);
are very early in the Starterware bootloader code, and I can't see any WDT setup
or PER PLL and M2 divider configuration prior to that. Is there any? Where?

I am not using HWREGL in the code that I posted in a .zip file; that is the
Starterware bootloader code. I repeat, it runs in the EVM SK board and not in my
new board. A difference is the debugger driver; I named them previously. Maybe
the emulator driver for the EVM SK board does some setup? The board might have a
problem, but I want to make sure I'm getting the software right.

The four lines:

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);
are very early in the Starterware bootloader code, and I can't see any WDT setup
or PER PLL and M2 divider configuration prior to that. Is there any? Where?

I set CLKSEL_WDT1_CLK (offset from CM_DPLL_REGS) to zero, selecting the RC
oscillator, which turned on the WDT module, so it got through the WDT disable.
You will need to understand previous messages in this thread about this.
My theory is that the emulator driver when using the EVM SK does a lot of setup
that is not in the Starterware bootloader, which is why the bootloader has the
WDT disable code in there. This looks like an undocumented dependency, and
should be escalated.

The emulator driver is not expected to do anything on Soc. If you dont connect the emulator and use bootloadr and application binaries will work on evm sk.

I guess there is something wrong in your ewarm project configurations.

Your above experiment proves that PLL was not able to source clock to WDT. You need to check that.

>The emulator driver is not expected to do anything on Soc. If you dont connect
>the emulator and use bootloadr and application binaries will work on evm sk.
Maybe a program that was already running on the EVM SK did set up.

>I guess there is something wrong in your ewarm project configurations.
Where? I did post a project. I repeat, it runs in the EVM SK board and not in my
new board.

>Your above experiment proves that PLL was not able to source clock to WDT. You
>need to check that.
So can I get an answer to this, please:
The four lines:
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);
are very early in the Starterware bootloader code, and I can't see any WDT setup
or PER PLL and M2 divider configuration prior to that. Is there any? Where?