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

Reply to
Thomas Obermair
Loading thread data ...

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

Reply to
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

Reply to
Thomas Obermair

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

Reply to
Vadim Barshaw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.