This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

S310 and IAR I-jet load/run

I've been successfully using IAR and I-jet with the 51822 and S110. I can build, download and run under the debugger with no problems.

I recently switched to the 51422 and S310, starting with a port of the S110 application template project to the S310. I can build and download, but instead of hitting a breakpoint at main(), the debug session crashes and the last message from the debug log window is "Stopped by a vector catch..." with PC at address 0x00019416 in 0-filled memory.

The loaded application verifies correctly against the IAR-produced hex file using nRFgo Studio. If I exit the debugger and power cycle the prototype, the application appears to be running normally. I can connect to it with the Master Control Panel app on my Galaxy S3.

Using the 51422 with the device set to 51422-QFAA in IAR, I can build, load and run the S110 led/button demo app using the I-jet, no problems running under the debugger.

I'm using IAR EWARM 7.20.2.7431, S310 v1.0.0, and SDK v6.0.0. I've updated the IAR .icf to reflect the application flash ROM base address at 0x00020000 and RAM base address at 0x20002400, and am using "--drv_vector_table_base=0x0" in the debugger extra options config. I've also #ifdef'd the "sd_ble_enable()" code block in ble_stack_init(), and removed the S110 definition from the preprocessor directives.

There doesn't appear to be an S310 demo app using the IAR flow in the 6.0.0 SDK. The IAR flash loader file names are all 15822 specific, although they seem to work with the 51422 and an application based on the S110. Is there some inherent problem running under the debugger using the IAR flash loader and I-jet with the S310 soft device?

Thanks and Best Regards, Matt Barr

Parents
  • The ANT softdevices (S210, S310) read protect region 0, the non-ANT softdevices (S110, ...) do not. When you point the debugger at the vector table at location 0 using the startup option "--drv_vector_table_base=0x0" it can't read the vector table values and startup fails.

    To work around this, find the initial SP and PC values in the softdevice vector table. These are the first two 32-bit values respectively (little endian), and are visible in the .hex file data. For example, in S310 version 1.0.0 we have:

    :10000000B0210020E19401003104000017940100A8

    The first two 32-bit values are 0x200021b0 and 0x000194e1. Create a execUserSetup() function in a C-SPY .mac file and assign the initial SP and PC based on these values:

    execUserSetup()
    {
        SP = 0x200021b0;
        PC = 0x000194e0;
    }
    

    Enable the macro file in the project debugger options. With this workaround an application based on the S310 will load, break at main() and run normally. Breakpoints work in the application, subject to the usual caveats for timeouts in the softdevice stack when execution is halted.

Reply
  • The ANT softdevices (S210, S310) read protect region 0, the non-ANT softdevices (S110, ...) do not. When you point the debugger at the vector table at location 0 using the startup option "--drv_vector_table_base=0x0" it can't read the vector table values and startup fails.

    To work around this, find the initial SP and PC values in the softdevice vector table. These are the first two 32-bit values respectively (little endian), and are visible in the .hex file data. For example, in S310 version 1.0.0 we have:

    :10000000B0210020E19401003104000017940100A8

    The first two 32-bit values are 0x200021b0 and 0x000194e1. Create a execUserSetup() function in a C-SPY .mac file and assign the initial SP and PC based on these values:

    execUserSetup()
    {
        SP = 0x200021b0;
        PC = 0x000194e0;
    }
    

    Enable the macro file in the project debugger options. With this workaround an application based on the S310 will load, break at main() and run normally. Breakpoints work in the application, subject to the usual caveats for timeouts in the softdevice stack when execution is halted.

Children
Related