DMA crash ?

[tnt]

[ysapir]

@sylvain,

Can you please specify what board you are using and what HAL revision?

It will also be useful if you could quote the compilation command line you used and/or attach the SREC.

[tnt]

I'm using epiphany-libs at commit 2ae10592a1a0cf7862ce714ba4b477d1bae6dbcd from 22 Feb.

All the files and their compiled version is attached.

The board I'm using is a zedboard with a E16G3 FMC daugthercard. And when I referred to the "patched up" nature of it is because the zedboard had some power rail failure that I had to fix.

[ysapir]

Could you please add a pause between the runs (in the while true loop) and see if it changes the result?

The reset on that revision was a soft core reset. There is a slight chance for things messed up if DMA transactions are still on the way. Basically, the "busy" loop blocks the flow until the last read transaction leaves. It is possible that you restart the program before the writeback completes (I think it is very unlikely, but the chance is there).

[tnt]

I just tried added various delays:

- Between calls to main_host in the "while true" bash loop, I tried a "sleep 1;"
- I added delay at the epiphany program main() start
- I added delays inside the while(1) epiphany loop and those delays were actually longer than the DMA complete time, so it doesn't even attempt to start a new DMA before the old is complete
- I changed the epiphany program so that when main_host exists, it disables the "while (1)" loop using a mailbox

And no changes ... Depending on the delay length , I can make it happen a bit less often, but that's most likely because it just executes less loops. In anycase, in less than 1 min of run, I can get either a full crash, or have the epiphany core not execute anything anymore.

[tnt]

I should add that using the same code but copying from SRAM to DRAM seem to work just fine.

[aolofsson]

I am guessing that this wasn't clear in our documentation, but the default behavior is for the DMA status register to indicate "done" when the last read transaction leaves the core (not when the last read transaction data returns!). I believe this may be the reasons for the erratic behavior. In the matmul example, Yaniv has some code to check that the last data transaction returned.

Doh! Realized that Yaniv already answered this..

Andreas

[tnt]

[tnt]

I just tried updating the epiphany libs from the git (had to adapt a bit to make it work for the E16, also had to adapt the host software to add e_init).

But exactly same results. SRAM->DRAM works fine. DRAM->SRAM has very weird behaviors.

[ysapir]