• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 83 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.

AM2612-Q1: CPU jumps to Hwip_data_abort_handler when execute OSPI_writeFifoData()

Kita Li
Intellectual 2945 points

Part Number: AM2612-Q1

Hi experts,

 

Good day! I am asking for customer.

My customer is developing AM261 with their own board. They will call function function OSPI_writeFifoData() int their code. They found that when they build the code with build configuration "debug", it can operate flash well when debug the code. But when they build the code with build configuration "release", the CPU will jump to Hwip_data_abort_handler.

Before jumping to Hwip_data_abort_handler, it runs on CSL_REG32_WR(indAddr, *srcPtr). This issue will occurs on address 0x880000, length is 256 bytes.

IMG_1035.jpeg

IMG_1034.jpeg

Could you help to check what will cause the CPU jumps to Hwip_data_abort_handler when execute OSPI_writeFifoData()? What's difference between "release" and "debug" on function OSPI_writeFifoData()

 

Best Regards

Kita

  • 0
    TI__Intellectual 990 points

    Hi Kita,

    Thank you for reporting this issue. The behavior you're describing - where code works in Debug mode but fails in Release mode with a data abort exception - is typically caused by one of the following issues:

    1. Memory Alignment Issue:

    The CSL_REG32_WR(indAddr, *srcPtr) operation requires proper memory alignment. In Release mode, compiler optimizations may change how data is accessed.

    • Check: Ensure srcPtr points to 32-bit aligned memory
    • Solution: Declare source buffer with proper alignment attribute: __attribute__((aligned(4)))
    2. Compiler Optimization Issue:

    Release mode enables aggressive optimizations that can affect memory access patterns.

    • Check: Review compiler optimization level (-O2, -O3)
    • Solution: Try marking the buffer as volatile or reduce optimization level temporarily

    Key Differences Between Debug and Release Modes:

    Aspect
    Debug Mode
    Release Mode
    Optimization
    -O0 (none)
    -O2/-O3 (aggressive)
    Code reordering
    Minimal
    Extensive
    Inlining
    Limited
    Aggressive
    Stack usage
    Higher
    Optimized/reduced
    Timing
    Slower
    Faster (may expose race conditions)
    Cache behavior
    May differ
    May differ

    Could you please try addressing the compiler optimization and memory alignment issues mentioned above and let me know if the issue still persists? This will help us narrow down the root cause and provide more targeted assistance.

    Please try the above suggestions and share your findings.

    Best regards,
    Mayank Shadwani