• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 33 subscribers
  • Views 603 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MCU-PLUS-SDK-AM243X: data abort exception with R5F memcpy from ICSSG0 RAM

Sven K
Prodigy 80 points
Part Number: MCU-PLUS-SDK-AM243X

Hello,

when using on R5F core a memcpy with size 4 from a ICSSG0 RAM byte address I got a data abort exception.

See this code snippet:

Fullscreen
1
2
3
void* pvTest = (void*) 0x30010002;
uint8_t au8Array[8];
memcpy(au8Array, ((uint8_t*) pvTest), 4);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

In assembler its realized as ldr.

Fullscreen
1
2
3
4
> memcpy(au8Array, ((uint8_t*) pvTest), 4);
E59D0024 ldr r0, [r13, #0x24]
E5900000 ldr r0, [r0]
E58D001C str r0, [r13, #0x1c]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

This code is working with other memory areas (MSRAM, DDR4) but not with ICSSG0 or ICSSG1 RAM.

Do you have any solution for this problem?

Best regards,

Sven

  • 0
    TI__Mastermind 26025 points

    Hi Sven,

    Can you also share your MPU settings for this region ?

    Thanks,

    Aakash

  • 0 in reply to Aakash Kedia
    Prodigy 80 points

    Hi Aakash,

    we didn't have a MPU region for this memory area. We tested it with a MPU region but without any difference. Do you have any recommondations which we can test?

    Sven

  • 0 in reply to Aakash Kedia
    Prodigy 80 points

    Hi,

    this problem occurs on access to GPMC SRAM too.

    In my view the problem is a optimization of memcpy of ti compiler when size of copied data is fixed to 2 or 4. The resulting ldr / ldrh assembler code is not valid for every peripheral memory controller which results to a data abort exception.

    When copy size is not fixed the code is branching to __aeabi_memcpy() which handles these accesses correct.

    Proposal: Is it possible to acoid this optimization in the compiler and ever branch to __aeabi_memcpy?

    Best regards, Sven

  • 0 in reply to Sven K
    TI__Expert 4600 points

    Hi Sven!

    When it comes to memory with special access requirements or memory-mapped peripheral registers (and the like), use of memcpy() is considered invalid.  A compiler's implementation of memcpy() does not make any guarantees about how it will access the memory for the copy, including inlining fixed-length copies in an optimization as is happening for you here.  Also, the pointer through which you access this memory should probably be marked as 'volatile', and then the compiler would tell you that it is incompatible with use of memcpy().

    For this use case, you should use your own copy function and use 'volatile' to ensure the compiler does what you want it to do.

    Hope that helps!

    -Alan

  • 0 in reply to Alan Phipps
    Prodigy 80 points

    For the reason we use external SRAM as execution in place memory for code execution and data access that is no option. As far as I know __aeabi_memcpy is avoiding unaligned memory access by splitting the copy to seperate smaller copy units. Thats not high-performant but is avoiding data aborts.

  • +1 in reply to Sven K
    Prodigy 80 points

    From a collegue of you I got the hint to use -mno-unaligned-access as compiler flag. That works fine as memcpy with fixed size n is realized as n ldrb assembler commands.