Too many interrupts

I have another clue, I also use DMA to tranfer replies up to the FPGA, DMA in this case signals an empty buffer so I can reload and trigger the next transfer.

The IRQs from the TX side seem to cause IRQs on the RX side.

Chris

Chris,

Are you using the EDMA3LLD driver for programming the EDMA?

when you are mentioning "edma 1.x and 2.x" are you mentioning the driver version?

Also was it working earlier and now you are facing issues, then please mention if there was any change in the hardware?

Regards,
Prasad

Hi Prasad,

Sorry long reply, while I write I might get inspiration from thinking it through...

Yes it is driven by the edma3 lld, the history is convoluted, I have essentially a board support package from an outside contractor, this went as far as echoing network traffic on the two ports. I have merged this code into our larger codebase which will provide the real functionality.

The code I got though was pretty difficult to work with, it was just a collection of cygwin make files that were derived from but no longer compatible with a CCSv4 project, this was based on edmd3 1.x and bios 5.x etc.

I recreated the project in CCSv5 (edma 2.x, sysbios 6.x etc) and now have a working debug environment that produces the code with this IRQ poblem.

I still have the bare bones early build from before I touched it that has the echo functions, this works on the same hardware and does not have the multiple IRQ problem. So it is a software change - something I messed up or a change in the libraries, something like different defaults maybe.

I have done lots of comparisons of the code to see what I could have done wrong, but as you can guess merging in a BSP is fairly striaght forward, it is merging in files I did not have before so there is very little actual merging in the lower level support code.

By passing data to the tcc callback function and counting IRQs I can see what is happening but am struggling to work out why.

The system is supposed to work like this

FPGA IRQ on GPIO87 triggers a DMA transfer:

I can see the code which set GPIO87 as a rising edge IRQ, but nothing to specifically link it to the DMA controller. The EDMA3_DRV_requestChannel call carries channel 45 which I think is associated with interrupt bank 5 which is where a an IRQ from GPIO87 might fall.

This is not in the cfg file, the LLD seems to sort this out (with some c code to set the GPIO pin as a rising IRQ input).

This works - my code reacts to recieved data.

Once the DMA has copied in the data from the buffer it raises an IRQ (an internal tcc callback).

I pass in marker values to the requested channels to check on callback to be sure I am only getting the expected callback.

This works - I get call backs on the first channel, there are actually 3 channels, control, ping and pong. The TCC is always my channel number and the completion code is always 1.

After parsing the message my application code constructs and sends a reply. To do this I put the message into memory and trigger DMA to transfer it to the FPGA, when this is finished the DMA controller does a call back so I can release buffers and Q up the next part.

This works - I am not leaking buffers.

If the FPGA is full the Q stalls while it clears and I get another IRQ from the FPGA when there is free space, wherupon I manually trigger the DMA again.

This IRQ comes in on GPIO01 (through a mechanism I have not worked out this is IRQ4), this one is created in the cfg file with event ID 65.
There is also a "EventCombiner.dispatchEventGroup(1, 8);" statement which I think is involved.
I have not sent messages long enough for this to be a factor.

Where this all goes wrong is that when I send a message I get called back from the recieve DMA channel, it goes a little deeper, I believe the DMA HW is also triggered to fetch the data from the FPGA again because the data in the buffer is refreshed.

So what seems to happen is that when I manually trigger the transmit DMA channel, it also triggers the recieve DMA channels. Somehwere the callbacks, irqs and dma triggers have got linked.

I have been reading various SPRU documents, but what eludes me most is a straightforward description of the relationship between pins, irq numbers, DMA triggers and events.

Specifically the library versions are these
 EDMA LLD    1.10.0.1  --> 2.11.4
 BIOS   5.x   --> 6.33.2.31
 XDC  3.20.x  --> 3.23.0.63

I am using a DM6433, the contractor modified the XDC files to support the 6433 as a 64P, I have carried these modifications forward - is this usual?

BR

Chris

Hi Prasad,

Yes it is event triggered, a HW IRQ, I enable the rx channels like this.

EDMA3_DRV_enableTransfer(rx[0].channel.hEdma, rx[0].channel.channel, EDMA3_DRV_TRIG_MODE_EVENT);

Allowing only input or output to be enabled is a workaround possibility, but I would like to avoid it.

I am not linking to an edma sample library, but the code I have got has functions like "edma_support_create_peripheral_channel" which look like they were lifted straight out of the sample code.

Can I ask possibly an easy one, I think I have worked out all the linkages now to get from IRQ to edma channel to event etc but my understanding requires a bit of guesswork on my part?

I think the relationship between GPIO and GPIO Bank X Interrupts is a simple OR function, GPIO pins are grouped in 16s so that my pin 87 IRQ for instance comes to bank IRQ5, I have not found a piece of documentation to confirm this or not yet.

The reason why this might help me is that I have checked the cct and found that the buffer free IRQ is linked to GPIO 1 and GPIO 86, this could explain my problems, if the irq destined for GPIO 1 also gets thru GPIO 86 into the bank 5 IRQ that would generate some excess IRQs.

The problem with this is why is now suseptible are there changes in defaults around this piece of code?

Well that is the rabbit hole I am off down next :)

Chris