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.

Why are there ITRAP0 instructions in my bootload program 28034?

Other Parts Discussed in Thread: CONTROLSUITE

Hi 

I wrote my own bootloader for the 28034.

I have an application that calls the following code

unsigned long init_boot_addr = 0x003ff7dd;
Uint32 (*entry)();

entry = (Uint32(*)())(init_boot_addr);
init_boot_addr = entry();
entry = (Uint32(*)())(init_boot_addr);
init_boot_addr = entry();

I use a PC app to send the file f2803x_flash_kernel.txt compiled from this directory

C:\ti\controlSUITE\device_support\f2803x\v130\DSP2803x_examples_ccsv5\f2803x_flash_kernel

I then load my application. 

This has been working over and over again with no problems until yesterday when I made some changes to my application. "The one that calls the code above".  Then all of the sudden I started to get this isr

///////////////////////////////////////////////////////////////

interrupt void PIE_illegalIsr(void)
{

// The next two lines are placeholders
asm(" ESTOP0");

// endless hold loop
for(;;);

} // end of PIE_illegalI

/////////////////////////////////////////////////////////////////////////////

I then loaded the symbols f2803x_flash_kernel.out for the bootloader program to try and figure out what is causing the isr above.   To my surprise there are ITRAP0 instructions in the disassembly.  

///////////////////////////////////////////////////////

137 EALLOW;
DisableDog():
008024: 82B3 MOVL XAR3, *ARP3
138 SysCtrlRegs.WDCR= 0x0068;
008025: 0000 ITRAP0
008026: 01C0 SUBU ACC, *+XAR0[0]
008027: 56BF6829 MOVB @0x29, #0x68, UNC
139 EDIS;

///////////////////////////////////////////////////////////////////////

Why is happening? Where are these ITRAP0 instructions coming from? Why is the disassembly wrong? When I single step the ITRAP0 instruction it causes the isr I have shown?  Can someone please suggest a solution for this?

  • Some ideas....

    If you load f2803x......out in CCS, my guess is there will not be a 0x0000 opcode.

    If that is true, then it looks like something went wrong in the copy of the data. Maybe it was copied and then something copied over it creating an opcode of 0000. On this device, memory at 0x8000 is dual mapped to locations starting at 0x3F8000 - a write to one would impact the other.
  • Ok since I called the _SCI_Boot at 003ff7dd and send the f2803x_flash_kernel.txt to it. What can over write the memory? Could it be interrupts or something in my main application that calls the following code? I do call __disable_interrupts( ); before I call this code. Does __disable_interrupts( ); disable all interrupts?

    entry = (Uint32(*)())(init_boot_addr);
    init_boot_addr = entry();
    entry = (Uint32(*)())(init_boot_addr);
    init_boot_addr = entry();

    Can you suggest what could be overwriting the memory?
  • James,
    Once you call the function in ROM, it is downloading the kernel and copying it into RAM. So this download/copy is overwriting some of the RAM that your application needs. So check you application map file and the downloading kernel map file and you already know which RAM locations have 0x0 in them and see if you can move your application to different RAM or change the kernel linking.

    hope this helps.

    Best Regards
    Santosh Athuru
  • Hi Santosh,

    Since the zero's show up when I run the kernel that has been copied to RAM.  Would it not be my application that is overwriting the kernel?

    I'm not sure what could be doing this since I have disabled all interrupts in my application I think.  As long as that is what this function     __disable_interrupts( ) really does. If I have disabled interrupts.  What else could be overwriting my downloaded kernel?

    Don

  • Don,

    since the downloaded kernel is running fine byitself I think it is fine. The kernel then parses the incoming application and loads it into memory and I suspect that is what is overwriting the kernel. If you incoming application has any memory in common with the running kernel then we will see this kind of problem.

    The ITRAP is an exception that cannot be disabled, this exception usually occurs when an illegal opcode is fetched.

    Hope this helps

    Best Regards

    Santosh Athuru

  • Thanks Santosh. That was the problem. I reserved the portion of memory in my application that the kernel is using. Now my bootloader works over and over.