F28M35H52C: IPC circular buffer problem when trying to increase size

Hi Nir,

Have you tried to increase the size and encountering any issue? I think it should work but we have not validated it.

Thanks & Regards,

Santosh

Hi Santosh,

Yeah I tried but it is then stuck in the code I mentioned above.

Can you try to see if that is working for you ?

Thanks you.

Nir,

Can you comment on the new size you've declared for the buffer size?  The only restrictions I see are the following:

1)Must be an even number

2)Must not exceed the allocated Shared RAM in the .cmd file.  The generic linkers we have in controlSUITE show the below size:

CTOMRAM     : origin = 0x03F800, length = 0x000380     /* C28 to M3 Message RAM */
 MTOCRAM     : origin = 0x03FC00, length = 0x000380     /* M3 to C28 Message RAM */

I would also double check that your linker is restricted the length to less than your buffer size.

Best,

Matthew

wMatthew,

I have tried buffer size of 6,8,16, none of them are working.

CTOMRAM     : origin = 0x03F800, length = 0x000380     /* C28 to M3 Message RAM */
 MTOCRAM     : origin = 0x03FC00, length = 0x000380     /* M3 to C28 Message RAM */

this is exactly what I have in my cmd file

MatthewPate said:

I would also double check that your linker is restricted the length to less than your buffer size.

 Can you explain what you mean about that ? how should I check that ?

Is it possible that this is restricting the ram size ? what is the page size ?

CtoM_DATARAM : > RAMS6 PAGE=1
MtoC_DATARAM : > RAMS7 PAGE=1

/* The following section definitions are required when using the IPC API Drivers */
GROUP : > CTOMRAM, PAGE = 1
{
PUTBUFFER
PUTWRITEIDX
GETREADIDX
}

GROUP : > MTOCRAM, PAGE = 1
{
GETBUFFER : TYPE = DSECT
GETWRITEIDX : TYPE = DSECT
PUTREADIDX : TYPE = DSECT
}

Nir,

Thanks for looking into my suggestions, the first response is what I wanted to see, that the allocation of 0x380 was the same as our examples.  The linker is allocating the max size -20h words already.  So values of 6/8/16 shouldn't be an issue.

For your second post, the PAGE declaration is a reference if the memory is used for program code(PAGE=0) or data (PAGE=1), so this isn't related to your issue.

I think the issue must be in the driver itself; I believe that you need to modify 2 .h files(or perhaps we are using one or the other), one for the C28x and the other for the M3

The M3 .h is in the path C:\ti\controlSUITE_latest\device_support\f28m35x\v220\MWare\driverlib\ipc.h 

The C28x .h is in the path C:\ti\controlSUITE_latest\device_support\f28m35x\v220\F28M35x_common\include\F28M35x_Ipc_drivers

Can you make sure and update both files and see if this resolves the issue?

Best,

Matthew

Hi Matthew,

I tried updating the files to last version (v220) , i was using 207.

It doesn't help, I also tried updating the .c files, but that didnt change things also.

Any thoughts on how I can debug the problem ?

Nir,

I'm still looking into this with some others on the team.  Please give me another day to provide an update.

Best,

Matthew

Nir,

We're still looking into this, in the meantime would you be able to single step through the increased buffer code to see what ends up happening when you go over the default value of 4?

Best,

Matthew

Matthew,

the code on the DSP side id stuck in this while loop:

IPCCtoMReqMemAccess (&g_sIpcController2, S1_ACCESS, IPC_SX_C28MASTER,
					 ENABLE_BLOCKING);
while ((RAMRegs.CSxMSEL.all & S1_ACCESS) != S1_ACCESS)
{
}

(cannot get access to S1)

Thanks,

Nir

S1 is where I write the data that is passed from dsp to arm.

Nir,

I'm trying to re-create this on my end as well.  Would it be possible to share your project file(s)?  Right now I'm trying to modify the IPC examples in controlSUITE, but if you think there would be any benefit of sharing files wanted to ask.  If needed I can set up a cloud share that is not visible to the E2E if your source code needs to be private.

Best,

Matthew

Matthew,

It's a problem for me to share all the source code of the project, if you think few files will be enough it's ok. Please tell me what you think and if you made some progress. 

Thank you,

Nir.

Nir,

I've been looking at our examples for this, and one difference is that we are using S0 memory vs the S1 that you are showing in your example above.  While this doesn't seem to explain adding the IPC buffer length directly, the fact that the C28x is stalled waiting on access permissions from the M3 makes me wonder if the M3 either didn't set up S1 at its boot or later on. 

Just to confirm, the use of S1 was not an issue before you increased the IPC buffer size?  Just want to rule out multiple code changes giving us some issues, but looking like the IPC buffer.

Best,

Matthew

Hi Matthew,

Yes I always use S1 for dsp to arm transfers, and S0 for arm to dsp transfers. no change before and after increase of buffer size.

Nir,

We have not had any success reproducing, if you could share a few relevant files to your setup it will help.

Best,

Matthew

How did you try to reproduce ? what project did you use ?

Nir,

I used C:\ti\controlSUITE\device_support\f28m36x\v220\F28M36x_examples_Dual\ctom_ipcdrivers\ examples.  I modified the .h files to increase the buffer sizes, but looking at the example code I'm not certain it is using the IPC RAM in the same manner as your code.

Best,

Matthew