• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 917 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.

SYSBIOS app under bootloader gives exception

Barry Andrews
Genius 3460 points
Other Parts Discussed in Thread: SYSBIOS

I am trying to run a sysbios application under a bootloader.

I have now sorted out the .resetVecs = 0x00002000 and .vecs = 0x20000000 locations thanks to TI technical staff feedback.

The code loads okay but when I launch it the code freezes in

ti_sysbios_family_arm_m3_Hwi_startup__E

Running the code in the IDE does not cause any problems even with the resetVecs set to 0x00002000.

I fugure it must be something my bootloader initialises interfering with SYSBIOS, any idea where to start looking?

All I initialise in my bootloader is UART0 and SYSTICK and I diable both before launching the SYSBIOS task.

  • 0
    TI__Mastermind 30830 points

    Barry,

    Which device are you using?

    The Hwi_startup() function simply enables interrupts so I'm assuming that an interrupt is pending prior to that and is immediately vectored to. My initial thought is that the vector table hasn't been properly initialized when the interrupt occurs, thus causing the vector fetched by the NVIC to be bogus.

    You mention that you have the .resetVecs and .vecs locations sorted out. I'm wondering how you went about this and why you ended up placing .resetVecs at 0x00002000 when it would ordinarily be placed at 0x00000000?

    The proper way of configuring the above vector table placements would be by adding these statements to your .cfg file:

    var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
    m3Hwi.resetVectorAddress = 0x00002000;
    m3Hwi.vectorTableAddress = 0x20000000;

    Alan

  • 0 in reply to Alan DeMars
    Genius 3460 points

    Hello Alan

    Thanks for the reply.

    Device is LM3S9D92 - Reset vectors are at 0x00002000 because there is a bootloader stored at 0x00000000 .  Bootloader is used to install the sysbios application at 0x00002000.

    All I have changed is to add my own linker command file which is included before the sysbios generated linker file.

    In this linker file I set .resetVecs to 0x00002000 and .vecs to 0x20000000

    I did this in response to another question regards moving sysbios.

    #define

    APP_BASE 0x00002000

    #define

    RAM_BASE 0x20000000

    --retain=g_pfnVectors

    MEMORY

    {

    // This is where our application can start

    FLASH1(RX) : origin = 0x00000000, length = 0x00002000

    FLASH (RX) : origin = 0x00002000, length = 0x0007E000

    // FLASH (RX) : origin = 0x00000000, length = 0x00080000

    SRAM (RWX) : origin = 0x20000000, length = 0x00018000

    }

    SECTIONS

    {

    // Vectors are at start of FLASH after bootloader

    // .intvecs: > FLASH

    .resetVecs: > APP_BASE

    .text : > FLASH

    .const : > FLASH

    .cinit : > FLASH

    .pinit : > FLASH

    .init_array : > FLASH

    // .vtable : > RAM_BASE

    .vecs : > RAM_BASE

    .data : > SRAM

    .bss : > SRAM

    .sysmem : > SRAM

    .stack : > SRAM

    }

  • 0 in reply to Barry Andrews
    Genius 3460 points

    I have not added your suggested changes.

    I checked the MAP file and it shows correct location

    00002000 ti_sysbios_family_arm_m3_Hwi_resetVectors

    I tried using timer0 instead of systick n my bootloader but still get the same result.

    Run from IDE - okay

    Run from bootloader which does a check to see if application is there and waits 500ms for the loader application (if connected) then if it has a valid application jumps to that applications __cint00

    Application starts to run and then stops at the same address mentioned in orignal question

     

  • 0 in reply to Barry Andrews
    TI__Mastermind 30830 points

    Barry,

    The SYS/BIOS climbup process assumes the CPU is coming out of reset and initializes registers based on their reset values.

    Does your boot loader initialize any NVIC or CONTROL register bits?

    I'm a little troubled by the mixing of StellarisWare interrupts and SYS/BIOS interrupts. Who's vector table is being placed at 0x20000000? Is it g_pfnVectors or ti_sysbios_family_arm_m3_Hwi_ramVectors? For SYS/BIOS compatibility, the vector table must be provided by SYS/BIOS.

    Alan

  • 0 in reply to Alan DeMars
    Genius 3460 points

    I think I now have working - further testing to confirm but I am no longer getting exceptions.

    Like any bootloader it has to start with its own vector table and then replace this with the SYSBIOS one when it launches the SYSBIOS application.

    I initialise, UART and Timer0A to allow my bootloader to do its stuff and use flash programming operations if an application is downloaded. I also enable master interrupts so the timer can work.

    After a new applications is downloaded or there is no connection to the loader I launch the application if loaded.

    Before I launch the new application I disable the UART and Timer0A

    I changed my switch to the new application to operate same way as the example bootloaders where I copy the sysbios vector table over my bootloader, set the sysbios stack pointer and jump to the sysbios reset vector.

    Initially this still gave me same issue, then I traced through what I was turning On and OFF peripherals wise and found that the problem occurred because I disabled master Interrupts before switching to the new application (Thinking was if I enabled it, I should also disable it).  Not sure why but leaving the Master Interrupts enabled and just disabling the timer interrupts I use appears to have done the trick.

    Will confirm this with further testing today.