• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 591 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.

CCS 5.5.0.00077 with XDS200 halts on ARM SWI vector

Robert Sprowson
Prodigy 70 points

Hi,

On a Cortex-A series ARM the XDS200 + CCS seems to get stuck at the SWI vector for no reason.

I've checked that semihosting is turned off in the ccxml setup, the MMU is active and I can single step through normal code. However, as soon as a SWI instruction is encountered the debugger stops at address 0x00000008 (the SWI vector), including if I set it free running.

The breakpoint dialogue thinks there are no breakpoints enabled, and "Break on SWI" are all turned off in the advanced ARM setup dialogue.

The disassembler and memory views agree with eachother, and show

  LDR PC, 0x1C0

and address 0x1C0 does indeed contain the address of the SWI handler proper. Single stepping does not result in the PC advancing - the various viewer can be seen to refresh but the PC is stubbornly at 0x00000008.

Is there an option somewhere I've missed? I'd simply like to free run the processor processing SWIs on the target (no semihosting, no breakpoints).

Thanks,

Robert.

  • 0
    TI__Guru**** 172109 points

    Robert,

    If you are using the Linaro GCC bundled with CCS, I wonder if the issue is because you are still linking the semihosting libraries. The options you need to change are shown in the Linaro's GCC <readme.txt> file, typically located at:

    <CCS_INSTALL_DIR>\ccsv5\tools\compiler\gcc-arm-none-eabi-4_7-2012q4\share\doc\gcc-arm-none-eabi

    Basically you need to replace the library rdimon with nosys on the linker options. Also, you need to remove the option rdimon.specs from the compiler.

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Prodigy 70 points

    Hi Rafael,

    desouza said:

    If you are using the Linaro GCC bundled with CCS, I wonder if the issue is because you are still linking the semihosting libraries. The options you need to change are shown in the Linaro's GCC <readme.txt> file, typically located at:

    Thanks for your thoughts, but I can confirm I'm not linking in semihosting versions of any libraries (for example, if I manually skip into the SWI despatcher it is code I recognise as my own rather than library code).

    Two extra observations I've made since reporting this, which might be relevant are

    a) when the debugger does halt on the SWI vector the debug window says it's a "SW breakpoint", however the breakpoints window shows that no SW breakpoints are enabled, and I also turned off software breakpoints in the debugger setup.

    b) when halted, if I modify the SWI vector contents in any way (eg. LDR pc, 0x1C0 to LDR pc, 0x1C4 then back to LDR pc, 0x1C0) everything then works fine.

    So while option (b) does give me a way to proceed, it seems that the debugger is retaining a stale view of the vector contents and showing the live contents in the disassembler/memory views, and my workaround (b) is forcing the debugger to update its interception of the vectors in some way. 

    If there was a programmatical way to achieve (b) that'd be great. I don't think there are any coprocessor ops that I could spot to call, for example,

    Robert.

  • 0 in reply to Robert Sprowson
    Prodigy 70 points

    Robert Sprowson said:

    So while option (b) does give me a way to proceed, it seems that the debugger is retaining a stale view of the vector contents and showing the live contents in the disassembler/memory views, and my workaround (b) is forcing the debugger to update its interception of the vectors in some way. 

    After some more experimenting by seeding the vectors with some dummy code that loads various magic values into registers I have discovered that the data cache flush wasn't working properly due to a bug on my part.

    From this I conclude that the disassembly view (and memory view) windows are showing the data cache view of the world, but single stepping the debugger executes via the instruction cache - this is why it all looked fine in Code Composer but the behaviour was incorrect.