1. Home
  2. Embedded Programming
  3. Can any one explain/clarify this behaviour of MIPS/VXWORKS

Can any one explain/clarify this behaviour of MIPS/VXWORKS

Hi All, We are trying to port our application from PPC405 to MIPS 4KC. I have come across one erratic behaviour of following code snippet.

******************************************************************************* /*Definitions for Safe Memory Backup, reboot reasons etc */ #define SAFE_MEMORY_BASE 0x81FB0000 #define SAFE_MEMORY_LIMIT 1024 char safeMemoryBackup[SAFE_MEMORY_LIMIT];

void sysHwInit(void) { int romStartedWatchdog = 1; unsigned int resetVal; unsigned int * location; int i; . . . sysBootLine = (char *)BOOT_LINE_ADRS; sysExcMsg = (char *)EXC_MSG_ADRS;

/* Copying Safe Memory contents (Reboot reasons etc) into structure and clearing the memory*/ bcopy( (char*)(SAFE_MEMORY_BASE), (char*) safeMemoryBackup,SAFE_MEMORY_LIMIT); bzero((char*)(SAFE_MEMORY_BASE), SAFE_MEMORY_LIMIT);

************************************************************************************************************

The purpose of above bcopy function is to write post-mortem(which is written in to SAFE_MEMORY_BASE while rebooting) data in to a variable called safeMemoryBackup.

And the bzero function is to erase the reboot reason from SAFE_MEMORY_BASE as we already stored RebootReason contents in to a variable called safeMemoryBackup.

But after execution of above code, safeMemoryBackup contents are always shows Zero instead of my reboot reason. If I comment bzero line, I could see the reboot reason contents in safeMemoryBackup as expected.

IS THIS MEAN, safeMemoryBackup IS GETTING UPDATED AFTER EXECUTION OF LINE bzero???????

to confirm that, I have used following code instead of bzero routine to erase the reboot reason.

bcopy( (char*)(SAFE_MEMORY_BASE), (char*) safeMemoryBackup,SAFE_MEMORY_LIMIT); location=(unsigned int *)SAFE_MEMORY_BASE; for(i=0;i

Reply to
mahendraguduru
Loading thread data ...

Are you certain safeMemoryBackup[] and SAFE_MEMORY_BASE aren't pointing to the same memory?

This is possible if safeMemoryBackup is the first static allocation and SAFE_MEMORY_BASE is aliasing (yes, this would be bizarre, but stranger things have happened).

Alan Nishioka

Reply to
Alan Nishioka

Hi Alan, Thanks for immediate repply. But I am sure that both of them are pointing to different memory. as you can see from below logs, safeMemoryBackup is at 0x805182c0 and SAFE_MEMORY_BASE was 0x81fb0000 [ODM-DEV-KERN >]safeMemoryBackup safeMemoryBackup = 0x805182c0: value = 572662306 = 0x22222222 [ODM-DEV-KERN >]d 0x805182c0

805182c0: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 805182d0: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 805182e0: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 805182f0: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518300: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518310: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518320: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518330: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518340: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518350: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518360: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518370: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518380: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 80518390: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 805183a0: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* 805183b0: 2222 2222 2222 2222 2222 2222 2222 2222 *""""""""""""""""* value = 21 = 0x15 [ODM-DEV-KERN >]

Thanks and Regards, Mahendra

Reply to
mahendraguduru

Are you sure sysHwInit is not called more than once?

Alan Nishioka

Reply to
Alan Nishioka

How recreatable is the failure? This sounds obvious, but what happens if you just step through the code and watch when the memory changes? If not, you could add some code to check your hypothesis, like if (*(long*)safeMemoryBackup == 0x22222222) printf("What the Heck?!?!\n"); stuck at the head of the routine to check for double-execution like Alan suggested and one before bcopy to verify what you saw.

Does the problem go away if you disable optimization in the compiler? I have stepped through optimized MIPS C code that reorders lines pretty radically, but it should still respect the order in which operations on the same memory occur. It's a stretch to think that this kind of thing could extend to calling complete macros out of order, but who knows.

- Tim.

Reply to
tbroberg

Hi Alan, You are very much correct. The sysHwInit is getting called twice(once from sysToMonitor while reboot and from usrInit as part of init. Thanks for the Help.

Regards, Mahendra

Reply to
mahendraguduru

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.