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

This is a discussion on Can any one explain/clarify this behaviour of MIPS/VXWORKS - 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 ...

+ Reply to Thread
Results 1 to 4 of 4

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

  1. 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<256;i++){
    *(location)=0x22222222;
    location++;
    }

    YES, safeMemoryBackup is getting updated with all 0x22222222.
    How this is possible?.
    How can be a lower function(bzero) executes BEFORE the function that is
    above in execution order?

    I have also used following cache routines before bzero, to ensure that
    cache is not creating problems.
    cacheFlush (DATA_CACHE,(int *)SAFE_MEMORY_BASE, ENTIRE_CACHE);
    cacheClear (DATA_CACHE,NULL, ENTIRE_CACHE);

    Can anybody clarifies this behaviour.

    Thanks in advance for your time.
    Mahendra.


  2. Re: Can any one explain/clarify this behaviour of MIPS/VXWORKS

    I can't see any problem in your code snippet.

    But, when and how did you check safeMemoryBackup's content? that may be
    the reason of the problem.



    mahendraguduru@yahoo.com 写道:

    > 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<256;i++){
    > *(location)=0x22222222;
    > location++;
    > }
    >
    > YES, safeMemoryBackup is getting updated with all 0x22222222.
    > How this is possible?.
    > How can be a lower function(bzero) executes BEFORE the function that is
    > above in execution order?
    >
    > I have also used following cache routines before bzero, to ensure that
    > cache is not creating problems.
    > cacheFlush (DATA_CACHE,(int *)SAFE_MEMORY_BASE, ENTIRE_CACHE);
    > cacheClear (DATA_CACHE,NULL, ENTIRE_CACHE);
    >
    > Can anybody clarifies this behaviour.
    >
    > Thanks in advance for your time.
    > Mahendra.



  3. Re: Can any one explain/clarify this behaviour of MIPS/VXWORKS

    I think what unicell means is that you should make safeMemoryBackup as
    volatile storage if it is getting written from a device, another
    processor, DMA, etc.


  4. Re: Can any one explain/clarify this behaviour of MIPS/VXWORKS

    Thanks for your advice Fred.

    And I suggest Mahendra using objdump to recheck the code according to
    the assembly.


+ Reply to Thread