OMAP-L137 EVM stuck at HWI_RESET

Arvid,

After giving David Anderson some time to respond, we will split this into a new thread so you can get the right people looking at it. The old thread is marked Answered and is a different situation than yours (OMAP-L137 vs.C6745 , sometimes fails vs. always fails, etc.).

The location you are stuck at is the reset vector. This is a set of no more than 8 assembly instructions that will branch to the location of _c_int00. If you look at the code in the Disassembly Window and use the Asm Single-Step-Into button on the Debug Window of CCSv4, you can see the assembly code step to the Branch instruction, and 6 steps later it should be at the address _c_int00.

If it goes to _c_int00 when you do the single-stepping, then you may have some code condition that causes a new reset or some errant pointer that gets you back there.

If it acts erratically and does not get to _c_int00, then the ARM core may be holding the DSP in reset or the Power and Reset Module may be holding it there.

It would be good to get some more detail on what "stuck at the last line" means.

What title would you like for the new thread? You can change it after the split, but "OMAP-L137 EVM stuck at HWI_RESET" seems like a good choice.

Regards,
RandyP

If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

Hi,

Despite the fact that i could get around this problem for a while, its come back to rear its ugly head.

I noticed that when I loaded my program onto the EVMOMAP-L137 with CCS3.3 the first time after connecting the EVM, running it would often cause the program to lock up before doing anything meaningful. When I'd stop it, the program counter or pointer (the little arrow in the disassembly and C code windows) would be pointing to this line:

    HWI_Obj 1, HWI_RESET, 0, _function, _monitor, _addr, _dataType, _operation, _client, _iUseDispatcher, _iArg, _IntrMask, _iCCBitMask, _iLoadTrack

in evmboardcfg.s62 (my tcf file is evmboard.tcf). But I always got it to work by simply re-loading the program onto the EVM and run again - that would always work. Simply resetting the program and running again would not fix it - I had to load the program a 2nd time - as if something that happened when loading the program onto the chip from CCS a 2nd time was essential. I have no idea what this could be - it seems to me there should not a be a reason for it to act this way... but if course there must be :)

Now I am trying to flash the EVM for standalone use using the SPI0 flash and the AIS bootloader (D800K001 on my EVM). I've successfully written the program to flash memory and get it to start running (set some LEDs at the beginning of main so I know what is happening) and every time it boots, the DSP gets stuck at this very same place again.

When I re-connect to the EVM with CCS and do "Load Symbols Only..." it always beings me to that line - the same one as above. So the problems must be related somehow.

I've peppered my main() with LED changes so i can track exactly where it locks up when booting standalone and it seems that as i comment out different sections of the code in main(), it just locks up at the next one, implying that the problem is not something in the code, but rather something timing related, or something in a different thread than main().

My code is definitely getting to _c_int00 because it sets the LEDs as coded in main(), so maybe something else is putting the chip back in reset?

I'm not using the ARM core at all. Is there something I should do to make sure it's not doing something like being in reset and causing problems with the DSP putting it back in reset? I know nothing about the ARM side of things.

If anyone with a better knowledge of the inner workings of DSP/BIOS (I assume that is where this problem is happening) could suggest a direction for me to look in as to what might be the problem, that would be fantastic. Thanks!

as an addendum, i did try to start my main() with a while loop blinking an LED - and that continued to run forever without locking up - so it is something to do with my code in main(). I'll have to keep trying to find what is in common between the things that lock it up.

Maybe I'm missing something in my initialization. I've covered all the basics like PLL, EMIFB, PINMUX and LPSC...

OK - so I solved this problem - not sure why what I did solved it, but I did. I stuck short delays ( EVMOMAPL137_waitusec( 25000 ); ) between each and after the last of the initializations the the gel file would usually do that i put at the beginning of my main( ). I also realized that I was initializing the EMIFB again later in main (though setting it to the same settings it was already set to in the gel file / functions I inserted in main to imitate the gel file I think) so I got rid of the 2nd EMIF initialization. One or both of these two things fixed my problem on SPI0 flash boot - not sure which. I may test at some point to see which it was - see which of the delays can be removed, etc -  so if anyone is interested, I can post that info here.

So relieved I got this working though.

cheers,
Arvid