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.

AWR2944EVM: Data abort exception

Part Number: AWR2944EVM

Hello,

I'm getting data abort exception during the initialization of Autosar OS after QSPI SBL

According to data fault registers, it should be synchronus external abort due to write access but I'm not able to pinpoint the root cause because it happens in different places Everytime and debugging/stepping through the code delay the issue.

Also data fault address register points to strange address 0xfffffff8 which contains nothing.

Any idea what could be the reason or how to debug further?

Update:
After further investigation it seems that BL instruction with machine code "2AFFFFEB" and offset "8809CD60"causing the issue.
When I checked the instruction,code and offset, it's basically gonna jump to valid address which is located in map file and refer to specific symbol.

Is there compiler support here who can take a look at this? 

  • Hi Andrew,

    Please make sure that DSS_L3 is initialized and ARM R5F MPU is enabled and has a region for DSS_L3 with correct permissions. 

    Regards,

    Ajay

  • Hi Ajay,

    I am sure that L3 is initialized because I can write to it using QSPI copy in SBL.
    Also I have taken care of MPU region for it. Please check below screenshot and tell me if you see something wrong with my permissions.

    By the way I am bringing up L3 using below API and I don't need the core itself, just L3 memory.

    Bootloader_socCpuPowerOnReset(2,NULL_PTR);

    Am I missing something? Do I need to flash the DSP core?

    BR,
    Andrew

  • Hi Andrew,

    The L3 initialization sequence is fine.

    For access permission, can you open the memory browser when debugging and see if you are able to read/write from the memory browser in this L3 address.

    If this is fine, then I feel you should contact your Autosar vendor for support, as we are not aware of the vendors implementation.

    Regards,

    Ajay

  • Hi Ajay,

    Just to close the loop it seems that after SBL is finished, the MPU configuration is reset.
    I configured it again to be able to disable caching and enabling shareable flag which fixed the issue.
    This is not relevant to the OS.

    One more question what is the normal MPU behavior after SBL is finished.
    Does the SBL in the demo SDK performs a reset which erases the MPU configuration?

    BR,
    Andrew

  • Hi Andrew,

    Yes, The SBL does a R5 Core reset at the end of SBL execution.

    Regards,

    Ajay