• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 1110 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BIOS_start() fails with unplugged interrupt

Kai Neumann1
Prodigy 150 points
Other Parts Discussed in Thread: SYSBIOS

Hi there,

I have a serious problem, I'm not able to figure out:

When I call BIOS_start(), the system crashes (goes somewhere into exit.c, I cannot see where exactly)

Inside BIOS_start(), at some point the ti_sysbios_BIOS_startFunc__I is called.

When I step through this function, at the last call (ti_sysbios_knl_Task_startup) there seems to be a problem:

The function         ti_sysbios_knl_Task_startup__E: is called and the disassembly shows:

       ti_sysbios_knl_Task_startup__E:

00c007: 0010 INTR INT1
00c008: C006 AND @0x6, AL
00c009: 0000 ITRAP0
00c00a: 0006 LRETR

So it jumps right into INT1, which is not plugged in.

I have another project using SYS/BIOS and there the disassembly code of  ti_sysbios_knl_Task_startup__E looks completely different.

Do you have any idea, why this could be?

Thanks!

  • 0
    TI__Mastermind 21645 points

    Hi Kai,

    What target and platform are you using ? Also, what version of SYS/BIOS and XDC are you using ?

    The Task_startup__E code looks corrupted.

    Best,

    Ashish

  • 0 in reply to Ashish Kapania
    Prodigy 150 points

    I found the error!

    The problem originated from a erroneous linker file.

    In the linker file, some area was assigned to PAGE 0 and PAGE 1 simultaneously. It seems, that the linker put some program code at (say) address 0xc000 as well as an instance of a class. Then through the constructor loop, the memory was altered, so when the program code was called at that address, it was corrupted (of course).

    Stupid error on one hand, on the other, it seems weird to me that the linker is not able to prevent the double usage of a memory address.

    However, the case is solved.

    Thanks anyway for the reply Ashish!