Code stuck on 3FF9FA 6F00 SB 0,UNC

Are you running code from Flash or RAM?

One thing to look at is the value of the RPC register when you are stuck in the infinite loop.  This will hopefully give you an indication of possibly where the code has jumped from and narrow down the possible culprits.

Can you link your code where you access the data?

Tim

The instruction at address 0x3FF9FA is the last instruction of  function "_ITRAPisr" (code is documented in spru963A). This interrupt is triggered, when the machine code 0xFFFF (ITRAP) is executed. So I guess, soewhere in your FLASH start sequence the chip hits an unprogrammed FLASH address (0xFFFF). I would recommend to single step the code from RESET and see, where it hits an 0xFFFF instruction.

Thask for the info.

I am running out of RAM but added some data (that is too big to fit into RAM) in FLASH. The odd thing is that if I don't access the data, it runs fine. As soon as I start accessing the data, I have the problem.

I have single stepped the code but it doesn't appear when I am single stepping. I had breakpoints in the ISRs and stepped through them as well. I did that for several "loops". However, as soon as I hit run, it happens. The stack trace doesn't give me any useful info. I will look at RPC.

I got around the problem last night by running the code out of FLASH. Then every works fine.

Tim, you asked "Can you link your code where you access the data?" Are you asking if I am running the code in the same memory space (ie RAM vs FLASH)? If so, when I have the problem, all code and data (apart from a large array) are in FLASH. When I don't have the problem, all code and data are in RAM or all the code is in FLASH.

Thanks for the help!

The RPC register is 0

There was another aspect of this that I forgot to mention. This above problem only happens right after I download the code with the debugger. If I reset and restart and run, the code runs but not correctly. That is, some of the code appears to be executing but the program does not behave as expected. If I put the code in FLASH or get rid of my FLASH data and run out of RAM, the code runs as expected.

Thanks

Any other ideas? Right now I am running the code out of FLASH and program runs but it takes a lot longer to debug and of course there are limitations to debugging from FLASH.

Thanks

What is the status of the watchdog?  If it is enabled, try to run the program with a disabled watchdog and see if its doing better.

Watchdog is disabled. It disables it at the beginning of DeviceInit() which is called at the beginning of my code. It is also disabled in PLLSet().

void WDogDisable(void)

{

    EALLOW;

    SysCtrlRegs.WDCR= 0x0068;

    EDIS;

}

I did a search on my entire project (which includes some TI files) for "WDCR" and I only come up with the code in HVPM_Sensorless-DevInit_F2833x.c, which is the code above.

Is there any other way it could get enabled?

The idea to look into the status of the watchdog was just an attempt to corner your problem. Quite often the watchdog comes into play, when you change the timing (e.g. RAM vs. FLASH) of a project. Obviously not in your case, where the WD is actually disabled. 

Just to summarize your problem:  (1) You run code out of RAM. (2) Some data are stored in FLASH. (3) If you never touch the FLASH data, the code runs as expected. (4) If you access the data in FLASH, then and only then your code hits this the loop-instruction in the Itrap-isr.  Is that right?

If that's true, the only conclusion that I have now is that there must be something going on in your code, which uses the data from FLASH, computes something with these data and comes to a false decision ( for example a wrong pointer setting or something like this).  Did you check the values in your FLASH-data after programming? Are they as expected?  Without more knowledge about your project it is difficult to give more advice, at least for me.

Frank,

     Thank you for your time in looking at this. You understand it exactly right.

Before I posted, I thought it must be something with my code (and still may be) but the same code, linked to run out of FLASH, works. Once the code is in RAM, no go. Unfortunately, the problem doesn't happed right away or behaves different when stepping.

Thanks

I assume he got it solved but I was having the same problem using the ADC SYS/BIOS example.  In the example it was already set to run from flash and all but had the same failure with the SB 0,UNC if you ran it from hardware reset and not from main() which is the default entry point when you use the debugger.

I fixed it by enabling the C28x Boot/Startup screen in the BIOS configuration and setting "Boot from FLash".  Now the right "magic" code to get it from the reset vector to the program entry point is enabled.

jv