TMS320F28375D: Help understanding EMIF1 slow down

Hi Shawn,

Basically when you setup GPIO107 as XINT, due to EMIF1 access XINT is triggering and hence CPU goes into ISR hence CPU performance numbers wrt EMIF access goes down. Is that correct?

If yes then have you scoped the GPIO107 pin to see if there are any glitch on this pin?

Would it be possible for you to send me a sample CCS project which has this issue. I would like to run that on my setup here.

Regards,

Vivek Singh

Even though we setup for EMIF1 32bit operation, EMIF2 signals are also acting.

GPIO107 share pin with EMIF2. Somehow that EMIF2 activities tunneled through XBAR into XINT and triggers interrupts that supposed to be triggered by external GPIO activity.

Yes GPIO107 is muxed with EMIF2 A9 pin but that should not toggle due to EMIF1 access. Also you must have not setup mux option to select GPIO107 as EMIF2 pin. Could it be possible that some of the EMIF1 pins are interfering with GPIO107 on board (due to board routing issue) and causing this issue?

I am pretty sure the GPIO107 is setup for GPIO since the external interrupt does work. The problem is that EMIF1 activities also triggers the interrupt. The GPIO107 input is clean without any noise. I monitored it with a scope.

Additionally: 

I just checked the layout and the only signals that GPIO107 runs parallel to for any distance are other GPIO lines (specifically GPIO0, GPIO1, GPIO4, GPIO99 and GPIO102) none of which are part of the EMIF1 interface (we do not make use of EMIF2).

Actually the same problem also happens to GPIO108. Just the interrupt didn’t get triggered frequent enough to cause EMIF1 performance degrade.

Could you send the CCS project if no issue in sharing?

Would it be possible to share the project or issue is resolved?

Found the issue with XINT configuration in the code due to which EMIF1 pin was used as XINThence on every EMIF1 transaction, XINT ISR wa called and that impacted the EMIF throughput.