• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 55 subscribers
  • Views 2412 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.

Compiler/AM3352: Crash on SVC instruction

GerryL
Intellectual 640 points
Part Number: AM3352
Other Parts Discussed in Thread: SYSBIOS

Tool/software: TI C/C++ Compiler

I have bare-metal application which always runs fine under debug, but crashes consistently when the same code is loaded into ram and executed from my secondary bootloader.

Loading of the application code has been verified, and the branch to its start address works as well.  The culprit is always the "svc" instruction used by the (standard) start files in the application, and the problem is that no specific svc exception vector has been loaded -- it just goes to a standard branch-to-myself loop of death.

Curiously, under debug, you can step through the svc command, and it goes to the exception vector ok, but then magically returns to the instructions following the svc.  But when loaded and executed by the bootloader the svc exception is taken correctly, and it ends up in the death loop.

I've tried a lot of different ways to get around this, and put too many hours into it, all to no avail.  Can someone please help out here?

Here's a dump from the reset vector (at 0x86000000) through to the svc instruction in _start . .

86000000:   E59FF018            ldr        pc, [pc, #0x18]
86000004:   E51FF008            ldr        pc, [pc, #-8]
86000008:   E59FF018            ldr        pc, [pc, #0x18] <<< svc exception (load pc from address 0x86000028)
8600000c:   E51FF008            ldr        pc, [pc, #-8]
86000010:   E51FF008            ldr        pc, [pc, #-8]
86000014:   E51FF008            ldr        pc, [pc, #-8]
86000018:   E51FF008            ldr        pc, [pc, #-8]
8600001c:   E51FF008            ldr        pc, [pc, #-8]
86000020:   86000050           .word       0x86000050
86000024:   00000000            andeq      r0, r0, r0
86000028:   86000049            strhi      r0, [r0], -r9, asr #32  << thumb mode vector to 0x86000048
8600002c:   00000000            andeq      r0, r0, r0
86000030:   00000000            andeq      r0, r0, r0
86000034:   00000000            andeq      r0, r0, r0
86000038:   00000000            andeq      r0, r0, r0
8600003c:   00000000            andeq      r0, r0, r0
86000040:   8600004F            strhi      r0, [r0], -pc, asr #32
86000044:   E7FEE7FE            udf        #0xee7e       }
86000048:   E7FEE7FE            udf        #0xee7e       } pairs of Thumb instr's, all branch to self
8600004c:   E7FEE7FE            udf        #0xee7e       }

          Entry():
86000050:   E59F002C            ldr        r0, [pc, #0x2c]
86000054:   EE0C0F10            mcr        p15, #0, r0, c12, c0, #0
86000058:   EE113F50            mrc        p15, #0, r3, c1, c0, #2
8600005c:   E383360F            orr        r3, r3, #0xf00000
86000060:   EE013F50            mcr        p15, #0, r3, c1, c0, #2
86000064:   E3A03000            mov        r3, #0
86000068:   E3A00101            mov        r0, #0x40000000
8600006c:   EEE80A10            vmsr       fpexc, r0
86000070:   EE073F95            mcr        p15, #0, r3, c7, c5, #4
86000074:   E59FA00C            ldr        r10, [pc, #0xc]   <<<<< load _start address from 0x86000088
86000078:   E1A0E00F            mov        lr, pc
8600007c:   E12FFF1A            bx         r10

86000080:   E24FF008            sub        pc, pc, #8
86000084:   86000000            strhi      r0, [r0], -r0
86000088:   86000128            strhi      r0, [r0], -r8, lsr #2  <<<<<<<<<< _start
8600008c:   00000000            andeq      r0, r0, r0

.....

          _start
86000128:   E3B00016            movs       r0, #0x16
8600012c:   E28F1F4A            add        r1, pc, #0x128
86000130:   EF123456            svc        #0x123456       <<<<< CRASH - no real vector loaded for svc exception
86000134:   E59F0120            ldr        r0, [pc, #0x120]
86000138:   E5901004            ldr        r1, [r0, #4]
8600013c:   E59F2138            ldr        r2, [pc, #0x138]
86000140:   E5821000            str        r1, [r2]


[My setup is:
Custom PCB
AM3352BZCZ30
CCS Version: 6.1.2.00015
bios_6_45_01_29
pdk_am335x_1_0_3
GNU v4.9.3 (Linaro)
Win 7 64-bit]

Thanks,
GerryL

  • 0
    TI__Guru**** 393215 points
    The RTOS team have been notified. They will respond here.
  • 0
    TI__Guru** 116170 points

    Gerry,

    We got a notification that you were able to determine Semihosting or "rdimon" library was causing this issue in your code. 

    SVC goes into supervisor mode on the ARM which requires the core to make calls to the boot monitor.  Please refer to the following when GCC is used with TI RTOS, the semi hosting support seems to require a SVC HAndler to be installed.

    http://processors.wiki.ti.com/index.php/SYS/BIOS_with_GCC_(CortexA)#How_do_I_enable_Semi-Hosting_for_Cortex-A_GNU_targets_.3F

    You can also check the source file :

    bios_6_46_05_55\packages\ti\sysbios\rts\gnu\SemiHostSupport.c

    You could also check GCC or ARM forums to see if this issue has previously been reported.  Hope this helps.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Intellectual 640 points

    Hi Rahul,

    I deleted the post about semihosting because it was a false lead. I don’t need semihosting (now that I know what it is).

    So, taking a cue from the post unable to get to main in new board (am3352), I have changed library “rdimon” to “nosys”, and disabled semihosting in the debug setup.

    But the svc instruction is still there, and there is still no valid svc vector, and the crash persists.

    The only way that I can get this to work is to install my own svc vector after loading the code into ram and prior to jumping to the start address. The new vector jumps to a simple return from svc (movs pc, r14) which I was able to compile into the custom start files that I had to use for the SBL (see SPI boot fails).

    Why should these custom modifications be necessary, not to mention all the debug time that precedes them? All I am trying to do is “load executable into ram, jump to start address”.

    Thanks,
    GerryL

  • 0
    Guru 92251 points

    GerryL said:
              _start
    86000128:   E3B00016            movs       r0, #0x16
    8600012c:   E28F1F4A            add        r1, pc, #0x128
    86000130:   EF123456            svc        #0x123456       <<<<< CRASH - no real vector loaded for svc exception

    That Semihosting call in the _start function is SYS_HEAPINFO (0x16) (as listed in http://processors.wiki.ti.com/index.php/Semihosting#Supported_Calls). 

    To be able to run a program without the debugger attached my understanding is that the program can't make any Semihosting calls.

    Where did the _start function come from?

    I think the solution is to change to using a _start function which don't make a Semihosting call, but haven't (yet) looked at start up code provided in pdk_am335x_1_0_3.