Problems with shared memory in Release mode

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Problems with shared memory in Release mode

Jump to solution
1,174 Views
michaelschuehle
Contributor II

Hello,

I have developed a multicore application on a LPC4357 on a Embedded Artists OEM Board (LPC4357 OEM Board | Embedded Artists AB ).

The Programm works perfect if I run it in Debug mode with a LPC-Link2. But if I change to Release I get problems with the shared memory for the interprocess communication.

The OEM Board provides a 32Mbyte SDRAM wich I use succesfully and I have defined four memory locations for the interprocess communication. !The locations are in both cores the same.

#define IPC_M0_CMD                  (uint32_t *)0x28000000
#define IPC_M0_CMD_PARAM    (uint32_t *)0x28000004
#define IPC_M4_CMD                  (uint32_t *)0x28000008
#define IPC_M4_CMD_PARAM    (uint32_t *)0x2800000C

uint32_t *m0_cmd                  = IPC_M0_CMD;
uint32_t *m0_cmd_param     = IPC_M0_CMD_PARAM;
uint32_t *m4_cmd                  = IPC_M4_CMD;
uint32_t *m4_cmd_param     = IPC_M4_CMD_PARAM;

typedef enum{
    M4_NOP                                          = 0,
    M4_M0upAndRunning                      = 1,
    M4_Err                                              = 2,
    M4_SetInSyncBaseAddr                  = 3,
    M4_SetBufferReadFinishBaseAddr = 4,
    M4_SetBufferIndexToReadBaseAddr = 5,
    M4_ReadMeasureData                      = 6,
    M4_SkippedCycle                              = 7,
} M4_CMD;

If the M4 core reaches the point to start the M0 core, the M4 core waits after the start till the M0 core responds with a UpAndRunning command:

// Start M0APP slave processor
DEBUGOUT("  - start M0 core ... ");
    cr_start_m0(SLAVE_M0APP,&__core_m0app_START__);
    while((*m4_cmd) != M4_M0upAndRunning){}
    DEBUGOUT("\n    M0 responds: M0upAndRunning\n");
    *m4_cmd = M4_NOP;
DEBUGOUT("    done\n");

And the M0 core set the command if the initialization is done and waits till the command is cleared:

DEBUGOUT("  - send upAndRunning back to M4 core ... ");
    *m4_cmd = M4_M0upAndRunning;
    while(*m4_cmd != M4_NOP){}
DEBUGOUT("done.\n");

As written above in Debug mode all worked perfect but in Release mode both cores stay forever in their while loops...

I'm happy if anybody have an idea what the problem could be.

Kind regards
Michael

Labels (2)
1 Solution
843 Views
converse
Senior Contributor V

You need to declare the variables in shared memory as ‘volatile‘.

ser this for more info

How to Use C’s Volatile Keyword 

View solution in original post

3 Replies
843 Views
michaelschuehle
Contributor II

Thanks, that was the solution!!!!

Now I know the detailed function of volatile.

But it's confusing that the problem dont show up in debug mode. However it works now.

0 Kudos
844 Views
converse
Senior Contributor V

You need to declare the variables in shared memory as ‘volatile‘.

ser this for more info

How to Use C’s Volatile Keyword 

843 Views
starblue
Contributor III

In release mode, the compiler optimizes away accesses to main memory and keeps the variables in registers, so the change in memory done by one core is not seen by the other. The compiler can also reorder accesses, which can mess up your data structures.

You can prevent this by declaring the variables which are accessed concurrently `volatile`, then all accesses to these variables go to main memory and are also not reordered.

A more efficient but also more complicated solution is to use memory barriers, which only force accesses and prevent reordering where it matters.