ram data corrupt

Guess you'll need to open the debugger and some listing files, and review the code and its interaction with memory.

No one here has much insight into your random musings, which lack substance and detail.

Guess you'll need to open the debugger and some listing files, and review the code and its interaction with memory.

No one here has much insight into your random musings, which lack substance and detail.

hello Pier

if I add function UIP_writeSdo(0x80,appBuf) in the thread TASK1 , the data in RAM(0x20000000 to 0x200025a0) is ok,

but if I remove the function UIP_writeSddo(0x80,appBuf) in the thread TASK1 as picture indicate, all the data in memory 0x20000000 to

0x200025a0  is corrupted. 

Hard to say, does issue change if you define the appBuf as a static?

static UIP_UCHAR appBuf[APP_MSG_SIZE];

Does UIP_writeSdo modify the buffer?

The buffer did not modified in UIP_writeSdo.

It seems ok since I write static UIP_UCHAR appBuf[APP_MSG_SIZE].

What I wondering is why all the global data is corrupted since I use UCHAR appBuf[APP_MSG_SIZE]?

just like the picture indicate:

I just declare UIP__UCHAR appBuf[APP_MAG_SIZE] as an local variable in thread, why it cause this problem?

I don't know what the definition for the size is, but if it is large it will blow out the stack, corrupting statics and locale information potentially.

ok, thanks，and what will happen if I define an array which is larger than stack size in a thread, but the thread is never active?

will the array damage global data memory?

Trying to use  more memory than you actually have is never a good thing!

Does MDK assign memory for local data since compile in stack? I know stack is first in last out, is it suitable to pass a local pointer to a function as argument like the following code?

TASK(TASK_1)
{
    UIP_UCHAR appBuf[APP_MSG_SIZE];
   
    while(1) {

        if(WaitEvent(APP_EVENT_TASK_1) == E_OK) {
            ClearEvent(APP_EVENT_TASK_1); 
            ReceiveMessage(MSG_ID_1, &appBuf[0]);
            UIP_writeSdo(0x80,appBuf);
            test1++;
        }
    } 
}

Yes, virtually every 'C' compiler puts automatic variables on the stack.

Sure, you can have a pointer to an auto variable - but you have to be certain that it will only ever be used while it remains valid.

Once the function where the auto variable was defined returns, the pointer will no longer be valid.

Google "lifetime" of variables in 'C' ...

I found that my code cause data in RAM corrupted during startup. I know CORTEX-M3 could copy RW DATA and ZI data from flash to RAM ,it means my code in thread has damage this procedure, I want inquire to how data in flash copy to RAM?

JackShan said:

it means my code in thread has damage this procedure

No, it most certainly doesn't mean that, because that procedure has finished long before any code in your thread gets executed.  What can happen is if you overflow the stack wildly enough, your code may overwrite any variable of the entire program.  Which is why you really have to take care not to do that.  Ever.

hello broeker

I operate like the following procedure, open debugger window and then click next step. I found the data has been modified before enter main function. so I suspect my code influnce the procedure that CORTEX-M3 copy data from flash to RAM, I do not know much about that, so I want to inquire you that. 

does the data copy from FALSH to RAM by linker? I think my code has impact on linker

hello pier

 I found since implement code in 0x08003E32 in function _scatterload, the data copy from Flash to RAM is not correct. I paste the code here, do you have idea about this? If I want to check the relative data in Flash, how can I know the exact data address?

0x08003E20 4C06      LDR      r4,[pc,#24]  ; @0x08003E3C
0x08003E22 4D07      LDR      r5,[pc,#28]  ; @0x08003E40
0x08003E24 E006      B        0x08003E34
0x08003E26 68E0      LDR      r0,[r4,#0x0C]
0x08003E28 F0400301  ORR      r3,r0,#0x01
0x08003E2C E8940007  LDM      r4,{r0-r2}
0x08003E30 4798      BLX      r3
0x08003E32 3410      ADDS     r4,r4,#0x10
0x08003E34 42AC      CMP      r4,r5
0x08003E36 D3F6      BCC      0x08003E26
0x08003E38 F7FCF9C0  BL.W     __main_after_scatterload (0x080001BC)
0x08003E3C 3F04      DCW      0x3F04
0x08003E3E 0800      DCW      0x0800
0x08003E40 3F24      DCW      0x3F24
0x08003E42 0800      DCW      0x0800