• Locked Locked
  • Replies 5 replies
  • Subscribers 55 subscribers
  • Views 1472 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.

CCSV6 ARM Compiler generated problematic instruction

guosheng jin
Prodigy 130 points


I have a simple function (memcpy16lite()) to copy 16-bit data from Shared RAM to SDRAM.

An unaligned 16-bit destination address 0xC0008021 was passed into the function. And when the memcpy16lite() starts executing, the entire processor goes headwire...And an assembly-step through discovered that some malicious assemble code has been generated. See the last assembly line "80007c10:   E1C020B0 STRH          R2, [R0]", this line tries to write content of 0xC0008023 to some unknown address stored in R2 (R2's content actually is the data loaded from copy source and that content is supposed to write to 0xC0008021, so the actual operation should be the other-way round).

And as soon as I step through that malicious instruction, the processor goes headwrie.

 

Processor I am using: OMAPL137 ARM

Compiler: Arm v5.1.5 from CCS6.0

  • TI__Guru* 84285 points
    1. Does this function expect that the destination address may be misaligned?
    2. Is the address 0xC0008021 in valid memory?
    3. Are you copying function code?  Don't forget that pointers to thumb-mode functions have the LSB set to indicate they are thumb mode.
    4. Register R13 is the stack pointer; you are clearly compiling without the optimizer turned on, so the compiler will keep all local variables on the stack, and load and store to this location when the value is read or written.
    5. Although ARM usually puts the destination register as the first operand, load and store operations always put the memory operand second, even if it is the destination operand.  "STRH R2, [R0]" writes to location R0, and is displayed as I would expect.
    6. Could you be a bit more specific about how you know things have gone haywire?  Does the PC or SP change to an unreasonable value?  What symptoms are you seeing?
  • in reply to Archaeologist
    Prodigy 130 points

    Archaeologist said:
    1. Does this function expect that the destination address may be misaligned?
    2. Is the address 0xC0008021 in valid memory?
    3. Are you copying function code?  Don't forget that pointers to thumb-mode functions have the LSB set to indicate they are thumb mode.
    4. Register R13 is the stack pointer; you are clearly compiling without the optimizer turned on, so the compiler will keep all local variables on the stack, and load and store to this location when the value is read or written.
    5. Although ARM usually puts the destination register as the first operand, load and store operations always put the memory operand second, even if it is the destination operand.  "STRH R2, [R0]" writes to location R0, and is displayed as I would expect.
    6. Could you be a bit more specific about how you know things have gone haywire?  Does the PC or SP change to an unreasonable value?  What symptoms are you seeing?

     

    See my reply below.

    1. Does this function expect that the destination address may be misaligned?

                 YES.

    1. Is the address 0xC0008021 in valid memory?

                  YES. It's a valid data memory. I have two memory, 0x80000000 range is for code while 0xC0000000 is for data storage

    1. Are you copying function code?  Don't forget that pointers to thumb-mode functions have the LSB set to indicate they are thumb mode.

                 I am copying data only.

    1. Register R13 is the stack pointer; you are clearly compiling without the optimizer turned on, so the compiler will keep all local variables on the stack, and load and store to this location when the value is read or written.
    2. Although ARM usually puts the destination register as the first operand, load and store operations always put the memory operand second, even if it is the destination operand.  "STRH R2, [R0]" writes to location R0, and is displayed as I would expect.
    3. Could you be a bit more specific about how you know things have gone haywire?  Does the PC or SP change to an unreasonable value?  What symptoms are you seeing?

                I see my PC counter point to 0x00000010 after the instruction, 0x00000010 is not a valid memory location.

  • in reply to guosheng jin
    TI__Guru* 84285 points

    guosheng jin said:
    I see my PC counter point to 0x00000010 after the instruction, 0x00000010 is not a valid memory location.

    Well, that's definitely bogus behavior.  Unfortunately, I'm stumped as to why that is happening.  I don't see anything in that sequence of instructions that could cause such behavior.  The only thing I can think of is that perhaps an interrupt or trap occurs right at that very moment, but that doesn't seem likely.  Perhaps one of the other forum readers might have an idea?

  • in reply to Archaeologist
    Expert 1830 points

    Um, as far as I can see, the OMAPL137 has an ARM926EJ-S processor which implements the ARMv5 architecture (http://www.arm.com/products/processors/classic/arm9/arm926.php) which does not permit unaligned memory accesses (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0473c/CHDDCFFH.html)? Sounds like an alignment exception.

  • in reply to Markus Moll
    TI__Guru**** 171309 points

    Hi,

    I think Markus nailed it. The offset 0x10 of the interrupt vector table indicates an ARM Data Abort Exception.

    In your case, I imagine the ISR vector table is not properly set (check this document) and therefore the processor is jumping to what it thinks there is the correct exception handler.

    Hope this helps,

    Rafael