AM6422: Inttrupt delay on MSRAM and DDR

wanglili 王

Part Number: AM6422

Tool/software:

Hello，

I am using SDK version 8.6, booting R5F via A53, with IPC (Inter-Processor Communication) involved. During operation, I found that the delay time from detecting a change at a hardware IO port to the start of entering the interrupt handling function is unstable. Sometimes it is over 500 nanoseconds, and sometimes it can reach 1 microsecond or even 2 microseconds. I measured this using a logic analyzer and by toggling the IO pin level within the interrupt entry function. This situation occurs when the R5F core is running on DDR. When I do not use A53 to boot R5F and instead run the entire program from MSRAM, the measured results are also unstable. I am quite confused about this part. Can you help analyze it? Even with stack operations during this process, could such a large delay occur? It is worth noting that the priority of the external interrupt I am using is set to 0, which should be the highest priority.

The rising edge of the green (signal) is the actual moment when the hardware external interrupt arrives, and the falling edge of the blue (signal) is the moment when the interrupt handling function is just entered.

The entire program comprises three tasks:

UART data processing task:
- Priority: 30
- UART uses interrupt-driven reception, with an interrupt priority of 4.
SPI wireless module communication task:
- Priority: 33
- Processed only once every 2 seconds, using polling mode for SPI communication.
LED control task:
- Priority: 25

This configuration balances real-time responsiveness (e.g., UART handling higher-priority interrupts) with periodic background tasks (SPI) and low-priority visual feedback (LED control).

Glad to receive your message!

4 months ago

0 Swargam Anil 4 months ago

TI__Mastermind 45756 points

Hello ,

I am looking at your queries and you may expect reply in next week..

Regards,

Anil.

0 wanglili 王 4 months ago in reply to Swargam Anil

Intellectual 680 points

Hello,

Do you have any suggestions regarding the question I posed above?

0 Swargam Anil 4 months ago in reply to wanglili 王

TI__Mastermind 45756 points

Hello,

Debugging Interrupt Latency – Step-by-Step Approach

To determine whether FreeRTOS tasks or critical sections are causing the observed interrupt delay (500 ns to 2 µs), follow this isolation-based method:

Step 1: Run the Example from MSRAM (Internal SRAM)

Ensure that your entire application—including the interrupt vector table, ISR code, and stack—is placed in MSRAM instead of DDR. This removes the impact of DDR latency and bus contention.

Step 2: Run Only One Task (or No Tasks)

Instead of running three FreeRTOS tasks, simplify the setup:

Run only one minimal task.
Just enable the external interrupt and handle it in the ISR.

Step 3: Measure Again with Logic Analyzer

With this minimal setup:

Toggle a GPIO at the start of the ISR to mark ISR entry time.
Compare against the external interrupt signal (input edge).

You should now observe a much more consistent interrupt latency. If the jitter is gone or significantly reduced, then the root cause is likely:

FreeRTOS disabling interrupts during critical sections
Context switching overhead.

Regards,

Anil.

0 wanglili 王 3 months ago in reply to Swargam Anil

Intellectual 680 points

Hello，

Sorry for update.Following your suggestions for re-testing, the interrupt response latency has been significantly reduced when running only a single task. The root causes appear to be the two factors you mentioned: FreeRTOS' interrupt-disabling operations in critical sections and context switching overhead. How can these two factors be optimized to reduce the latency?