Data abort after enabling Data Cache on iMX6SL

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Data abort after enabling Data Cache on iMX6SL

Jump to solution
1,535 Views
nathanpalmer
Contributor IV

I am looking for some debug help on an iMX6SL.  I have configured cache memory access for instruction and data based on the SDK and some feedback from this forum.  However, after enabling cache I SOMETIMES get a data abort with a misaligned access:

------------------------------------------------------------------------------------------

Oops, data abort occurred!

Registers at point of exception:
cpsr = nZCvqeAIFt Supervisor (0x600001d3)
r0 = 0x00000001    r8 =  0x00000000
r1 = 0x80000000    r9 =  0x00000001
r2 = 0x00080000    r10 = 0x00000000
r3 = 0x020e0001    r11 = 0x8226a0f4
r4 = 0xdeadfeed    r12 = 0x8226a0f8
r5 = 0x80083344    sp =  0x8226a0e8
r6 = 0x00000000    lr =  0x80083b58
r7 = 0x00000094    pc =  0x80086b40
dfsr = 0x00000801
dfar = 0x020e0001

Access type: write
Fault status: 0x1

------------------------------------------------------------------------------------------

Oops, data abort occurred!

Registers at point of exception:
cpsr = nZCvqeAIFt Supervisor (0x600001d3)
r0 = 0x00000001    r8 =  0x00000000
r1 = 0x80000000    r9 =  0x00000001
r2 = 0x00080000    r10 = 0x00000000
r3 = 0x020eff1f    r11 = 0x8226a0f4
r4 = 0xdeadfeed    r12 = 0x8226a0f8
r5 = 0x80083344    sp =  0x8226a0e8
r6 = 0x00000000    lr =  0x80083b58
r7 = 0x00000094    pc =  0x80086b40
dfsr = 0x00000801
dfar = 0x020eff1f

Access type: write
Fault status: 0x1

------------------------------------------------------------------------------------------

These are two runs of the same executable.  However, note that the memory address of the violation (0x020eff1f and 0x020e0001) is different even though the PC is the same location.  This is very surprising that the same code would fault at the same line of code in different ways.   The code that is causing the fault SEEMs to be in the iomux_config() code that is just a string of writes to set IO PAD settings.  It is the code from the Freescale SDK for the MCIMX6SLEVK  and I think it is OK

I would like some help with debug procedure.  What could cause this error?  I think the MMU is configured OK and the Cache seems OK. Could it be related to the debugger or clock settings?

Here is a snippet of my init code:

    mmu_init();

    arm_branch_prediction_disable();
    arm_icache_disable();
    arm_dcache_disable();
    arm_icache_invalidate();
    arm_dcache_invalidate();
    arm_icache_enable();
    mmu_enable();
    arm_dcache_invalidate();
    arm_dcache_enable();

    iomux_config();  /////////// Seems to fail somewhere in here....

Labels (1)
Tags (3)
0 Kudos
1 Solution
930 Views
nathanpalmer
Contributor IV

This problem seems to be related to the IO drive strengths being different between my bootloader and the data in the iomux_config().  If the iomux_config() changes the values the program sometimes aborts.  I assume that the reason caching causes this problem is that the code gets executed earlier (less time between bootloader and iomux_config()).  Any further insight in to this would still be helpful...

View solution in original post

0 Kudos
3 Replies
931 Views
nathanpalmer
Contributor IV

This problem seems to be related to the IO drive strengths being different between my bootloader and the data in the iomux_config().  If the iomux_config() changes the values the program sometimes aborts.  I assume that the reason caching causes this problem is that the code gets executed earlier (less time between bootloader and iomux_config()).  Any further insight in to this would still be helpful...

0 Kudos
930 Views
Yuri
NXP Employee
NXP Employee

If the issue concerns with drive strength of memory signals - again - this may
be just a memory configuration problem.

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos
930 Views
Yuri
NXP Employee
NXP Employee

  Have You tried to test memory for assurance. When processor caches

are enabled, memory load may increase because of bursts, provided

by the ARM caches.

"i.Mx6DQSDL DDR3 Script Aid"

https://community.freescale.com/docs/DOC-94917

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos