This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

F28377D-SEP: issues happen when Gxram is allocated to .ebss

Part Number: F28377D-SEP

Hi team,

This is Kim, a FAE from south china I&A.

Now my costumer has meet an issue when set the GXRAM as .ebss.

The device they use is F28377, and dual core is used in their application.

They have used the shared ram (GXRAM), GXRAM0- GXRAM4 for cpu1 and others for cpu2, and the handshake mechanism is used, cpu2 will wait for the shard ram is available. Further, the normal debug step is load cpu1 then load cpu2, and run cpu1 then run cpu2. 

But there is a problem that according the above, the initial of time in cpu2 is failure. Costumer finds the value of the struct about timer are all 0 which should have a fix value in normal.

And when costumer change the .ebss to LSxRAM the timer can be correct initial.

I see the similar question in E2E: link

and the expert has mentioned it is ok to set the GxRAM to .ebss, but there are maybe some question, but we have confirmed the step is according to the expert has mentioned in the link. but there still has some question. Could you pls help to find out if there some error in our step? Thank you.

Kim Lan.

  • Kim,

    I believe this is an issue of ownership.  At reset all GSx RAMs are owned by CPU1.  Customer will need CPU1 to change the ownership of the GSx RAMs to CPU2 via the GSxMSEL register.  There should be a driver function for this setup that customer can call from CPU1 application. 

    CPU2 can read this register, to know that CPU1 has passed control of the RAMs, but cannot modify it.

    Best,

    Matthew