We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi
I'm writing my first ARM application. I have C++ code that works in Visual Studio on Windows and I am porting it to ARM using ARM Dev Studio. I want to target Cortex M6 but am currently targeting Cortex-A53 as that is suggested in the tutorial. My code builds ok and runs ok in the debugger up to a certain point, at which the debugger hangs when I try to step over the next line:
It seems to be a consequence of accessing the pointer rather than the cout. Earlier cout's work ok. I think the pointer is valid.
Please can you help me find out why this is happening? I don't know what to do next.
Thanks
David
Hi David,To see which instruction causes the exception, you should either single-step at instruction level and watch the Disassembly view on each step, or run (not step) to the exception trap and then look at the instructions in the Trace view.From the output you gave, it looks like the instruction at/near 0x8000A40C is the culprit.In the screenshot below, using the startup_Armv8-Ax1_GCC (where I've deliberately changed SP to an invalid value), the Trace is showing that the STP instruction at 0x80003170 caused the exception.Stephen
Hi Stephen,
I mentioned above that the exception occurs when accessing a member of a structure:Execution stopped in EL3h mode at EL3:0x000000008000A40CEL3:0x000000008000A40C 168,38 unsigned sectionId = p_sectionInfo->sectionId_rb_symInc_startPrbc_numPrbc_struct.sectionId; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The interesting thing is that sectionId is a bit field in a union:
Are you aware of any restrictions of the armclang compiler that might prevent access to such bitfields?
Best regards
Hi DavidI suspect that the exception is being caused by an unaligned access to memory. To confirm this, you'll need to identify the exact instruction that triggers the exception (by trapping the exception and tracing instruction execution up to it, as described earlier), then place a breakpoint on that instruction in the Disassembly view, and run again. When the breakpoint hits, open the Registers view to see the exact address that the instruction is trying to access. Is it an unaligned (i.e. non-32-bit) address?If so, you can either configure the core in the FVP model to allow unaligned accesses (with the A bit in the SCTLR), or prevent the compiler from generating code that uses unaligned accesses - seehttps://developer.arm.com/documentation/101754/0616/armclang-Reference/armclang-Command-line-Options/-munaligned-access---mno-unaligned-accessThere may be a performance and/or code size impact, depending on your choice.See also "packed" structures athttps://developer.arm.com/documentation/101754/0616/armclang-Reference/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----packed---type-attributeandhttps://developer.arm.com/documentation/100748/0616/Writing-Optimized-Code/Packing-data-structuresHope this helpsStephen
Thanks very much for your help with this thread. I will accept your answer now so that we can close it.