TDA2HG: [EDMA] MCSPI EDMA in IPU1 lost event when run with other EDMA in other Core.

From "Statistics Collector" I also notice:

 [HOST] [IPU2  ]    870.046330 s:        STATISTIC          Avg Data        Peak Data 
 [HOST] [IPU2  ]    870.046544 s:        COLLECTOR          MB/s            MB/s      
 [HOST] [IPU2  ]    870.046727 s:  -------------------------------------------------- 
 [HOST] [IPU2  ]    870.047001 s:  SCI_EMIF1 RD+WR      |   1783.792013   2963.038875

And we only have I EMIF in use. So it may possible that EMIF load is overrun and then make MCSPI EDMA went abnormal.

Is it possible? If yes, why I can work fine on MCSPI FIFO mode? And is there is any workaround? Since reduce EMIF load is huge project...

Thanks!

Hi Tim,

Which usecase are you running on vision sdk? I mean, is your usecase using any EDMA channels? Also is the EDMA task set to sufficient higher priority to get scheduled without affecting?

Camera does not use EDMA. so it should not affect EDMA traffic. 

Regards,

Brijesh 

Hi Tim,

Can you please share complete statistics? It would be difficult to figure out from this snapshot.

Rgds,

Brijesh

My usecase use channel 40 and 41. It is created by ourself. And it is use to transfer video data not camera sorry. Those two channel is set as Edma no.1 event queue, But mcspi edma I set as No.0 event queue. So I think those channel could not block mcspi edma event.

Because I'm off office, I will share complete statistic tomorrow.

Thanks for your reply!

Hi,

oh ok, there is a big data transfer on TC1, i guess this is for camera. and some small traffic on TC0, guess, this is SPI. 

Yes, TC0 has higher priority over TC1. 

At what frequency, are you running DDR? The peak DDR BW is almost reaching around 2.9GB/s. So depending on your DDR frequency, it might already be reaching to edge. 

Regards,

Brijesh 

Hi Brijesh,

Thanks for your reply.

there is a big data transfer on TC1, i guess this is for camera. and some small traffic on TC0, guess, this is SPI. 

Yes, you guess is right.

My DDR frequency is 533Mhz, DDR3-1066, so I think it should reaching to edge.

But I notice IPU have 64k ram, can I configure EDMA destination to there? Or can I configure EMIF or some registers to higher priority of MCSPI EDMA DDR I/O operation?

Thanks!

Hi,

Complete statistics: 1070.statistics.txt

Hi Tim,

The peak BW is reaching to almost crossing edge. so may be few of the modules are getting affected. 

I think we can change priority, but it would affect somewhere.. Are you ok with it? 

The other way, can you bring the BW under control? Hopefully, then, your transfer will not get delayed. 

Regards,

Brijesh

Hi Brijesh,

I think we can change priority, but it would affect somewhere.. Are you ok with it? 

Yes! why not try it at first! Would you please tell me how to do that?

The other way, can you bring the BW under control?

Our team is struggle with it day and night, but I think it is not such easy to do that.

And is it  available configure EDMA destination to IPU local 64K RAM?

Thanks!

Hi Brijesh,

Any update?

Thanks!

BR/Tim

Hi Brijesh,

Any update?

Thanks!

BR/Tim

Hi Tim,

Something simple like, can you use internal buffer of McSPI and see if it helps?

Regards,

Brijesh

Sorry Brijesh,

Would you please tell me which simple code? And is the internal buffer same as  IPU local 64K RAM? Would you please tell me how to use it?

Thanks!

BR/Tim

Hi Tim,

I mean, did you try using CPU mode? Any specific reason for not using CPU mode? I think McSPI has internal buffer of around 64 (or may be 128)bytes, can you use it to transfer your data using CPU mode?

Regards,

Brijesh

Hi Tim

I see this thread has stalled. Did you try any further experiments? Did you try the EDMA mode and still seeing the issue?

Regards

Piyali