Forums

Setting MSC1 on StrongARM causes "data abort"

Started by Thomas Obermair July 10, 2006
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


Thomas Obermair wrote:
> 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.
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 


Thomas Obermair wrote:
> Reading continuously from OSCR-register works fine.
Do you see the counter values that are consistent with free-running 3.68 MHz oscillator?
> 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.
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.
> 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.
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.
> 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...
Looks like inconsistency with translation. Probably, try disabling Dcache and/or write buffer globally in CP15 register1 to see the difference? Vadim Barshaw