Setting MSC1 on StrongARM causes "data abort"

Hi all!

I'm stuggling with setting of MSC1-Register on Intel StrongARM CPU. Most
times it works just fine to set the desired value, but sometimes I get "data
abort" oder "undefined instruction" exception.

Are there any considerations to take care of when setting MSC1-register? Eg.
regarding caches, mmu, flush of pipes, ... ?

This VxWorks-testcase reproduces the problem after about 10..300 loops:

#define SA1110_MEMCTRL_BASE 0xA0000000
#define SA1110_MEMCTRL_MSC1 (SA1110_MEMCTRL_BASE + 0x14)
#define SA1110_MEMCTRL_MSC1_VAL 0xf08591c4
void TestMem(void) {
while (1) {
*((volatile UINT32*)(SA1110_MEMCTRL_MSC1)) = SA1110_MEMCTRL_MSC1_VAL;
taskDelay(1);
}
}

ANY help is very much appreciated!

Thanks a lot,
Thomas

 

Do you have any doubly mapped virtual addresses? If yes, they must be
accessed as non-cacheable.

Does it happen only with MSC1 register or other registers in vicinity are
also affected? What happens if you try to read OSCR (0x90000010)
continuously?

Does the page that maps MSC1 have both B and C bits set to 0?

HTH,

Vadim Barshaw

 

Hello Vadim! Thanks for the quick answer!

Reading continuously from OSCR-register works fine.
I don't think that there are any doubly mapped addresses. But I'm not
100% sure, and I don't know how to really check. Memory mapping is 1:1
(PA:VA) and done by vxWorks MMU-functions.

B and C bits are both 0 in the pages that are controlled from MCS1, and
also in the page that holds the MSC1-register itself.

Yes, the same problem also occures when I try to write MECR for
instance. Seems that the registers of the memory-controller have some
kind of problem when writing to...
Reading from MECR works fine.

Did some more tests today, and finally gave up. I now set all the
memory-controller registers in early boot-state, where mmu and cache is
still disabled. Seems to work there...

Many thanks,
Thomas

 

Do you see the counter values that are consistent with free-running 3.68
MHz oscillator?

I am not familiar with VxWorks, but if you have source code you could
trace the initialisation of translation and page tables. Or you can
examine the translation table at the address pointed to by register2 of CP15.

This sounds like the page is being cached, and sporadic data aborts or
undefined instruction exceptions might indicate the address is being
mapped to more than one page.

Looks like inconsistency with translation. Probably, try disabling Dcache
and/or write buffer globally in CP15 register1 to see the difference?

Vadim Barshaw