Jeff, Jim, Dave and Alex.

We worked today on adding more IPC channels using the GeFanuc Reflective Memory network which runs between the H2 EY systems h2susb6, h2seib6, h2pemey and the LVEA h2susb478. Senders and Receivers were added to several models as part of the code upgrade.

It was found that RCG2.5.1 does not allow DMA data transfer to the RFM card no matter what the no_rfm_dma setting is. With the non-DMA default of RCG2.5.1, it was found that the h2susetmy model was running too long, over its 60uS limit. Working with Alex, we overrode the "no dma" setting on 2.5.1 by editing the feCodeGen.pl handling of the no_rfm_dma CDS block setting. It was found that DMAing the IOP caused it to slow down to a point that the software watchdog on the ISI front end would not allow DAC activation. So we tried a hybridized system of non-DMA for IOP, and DMA for user model. All was looking good with CPU usage, except for the fact that the IPC did not in fact work. No data got through, and the IPC receive error rate was at the max value.

Alex did some digging and found that the RFM DMA can only work if both the IOP and the user model are set to use DMA. We tried this and indeed the model-to-model IPC did work with no errors and no CPU overruns, but the IOP again was running too long, causing Watchdog IPC errors of a rate of about 200 per second (out of 65536) which meant that the SEI front end DACs were disabled. We seem to have reached an impasse.

So for now we are reversing today's DMA changes. All DMA is turned off, in fact the RCG is reverted back to the 2.5.1 version of feCodeGen.pl which does not allow DMA at all. Jeff has backed off on the number of new IPCs in the SUS models to keep the CPU usage well below 60uS.