LP-AM243: interrput handler, r5f core

Hi Manoj,

What version of the SDK are you using?

Manoj Koppolu said:

why i am able to see this behaviour ?

I gather you're using the AM243x LaunchPad. How are you generating the GPIO input to the LP? Can you share an example code with this behavior?

Manoj Koppolu said:

what happens when the interrupt with same priority(the same interrupt happens again) interrupts the r5f core  ?

Please see the TRM:

• Section 6.2.3.5.5 VIM Interrupt Prioritization
• Section 6.2.3.5.8 VIM Interrupt Handling

When an interrupt goes from pending to active, then the interrupt is loaded into the corresponding active register, and all interrupts of an equal or lesser priority are masked off ("masked off" means that they are masked off from priority arbitration to interrupt the currently active interrupt).

This means the same interrupt can't interrupt the current ISR, even if interrupt nesting is enabled.

The ISR clears the interrupt on the VIM and at the interrupt source. Typically an interrupt source won't generate a new interrupt until an existing interrupt has been cleared (acknowledged). The order of the clearing depends on whether the interrupt is pulse or level. Please see: <SDK>\source\kernel\nortos\dpl\r5\HwiP_armv7r_handlers_nortos.c\HwiP_irq_handler_c.

The source can then generate another interrupt, which the VIM will process as a new interrupt. If this is the highest priority pending interrupt, the VIM will send this interrupt to the R5F.

Regards,
Frank

Hi Manoj,

I gather you're bit-banging the ADC output interface using SOC GPIOs.

DCLK is the output clock from the ADC? This is connected to GPIO1_7?

The interface is configured in Double Data Rate mode, i.e. the ADC drives output data on each DCLK edge (low-to-high and high-to-low)? The data pin(s) are connected to other SOC GPIOs?

Your code takes the GPIO bank ISR on both DCLK (GPIO1_7) edges?

The ISR reads the ADC data pins from the connected GPIOs?

The IRQ dispatcher executes before and after the registered ISR function executes. My guess is the dispatcher time plus the registered ISR time is taking more than 1 usec. As a result, the ISR doesn't always sample the data bits at the correct time.

Can you measure the time between ISRs using the PMU? See See https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_05_00_24/exports/docs/api_guide_am243x/KERNEL_DPL_CYCLE_COUNTER_PAGE.html

Regards,
Frank

Frank Livingston said:

DCLK is the output clock from the ADC? This is connected to GPIO1_7?

yes

Frank Livingston said:

Your code takes the GPIO bank ISR on both DCLK (GPIO1_7) edges?

yes

Frank Livingston said:

The ISR reads the ADC data pins from the connected GPIOs?

yes

Frank Livingston said:

My guess is the dispatcher time plus the registered ISR time is taking more than 1 usec. As a result, the ISR doesn't always sample the data bits at the correct time.

i will check this

Is it like my isr cannot handle at 3MHZ as i am not able to see values of ESDRAM changing at 3MHZ...how to check what is the maximum interrupt frequency of isr?

Hi Manoj,

Manoj Koppolu said:

how to check what is the maximum interrupt frequency of isr?

I suggest measuring the time between ISRs using the cycle counter (PMU): See https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_05_00_24/exports/docs/api_guide_am243x/KERNEL_DPL_CYCLE_COUNTER_PAGE.html

This will tell you how many R5F clock cycles (@ 800 MHz) are consumed between ISRs.

Another thing you could try is driving a GPIO output inside your ISR (e.g. high at ISR entry and low at ISR exit). Then look at the GPIO output timing on a scope or logic analyzer.

Start with an ISR frequency that works (0.5 MHz) and then progressively increase the ISR frquency 'till your ADC sampling stops working.

Let me know how it goes.

Regards,
Frank

1)

isr without memory transfer (if i include block transfer dma(UDMA) it will take atleast take 2.4us) :-1.2*2= 2.4us us

isr with mem transfer(without udma):-1.3*2= 2.6us
dclck:-at 2.5MHZ 0.4us

Is it possible to use pdma to directly read from gpio's and store in memory without isr?

2)

is it possible to increase input clock frequency of r5f core?

Hi Manoj,

Manoj Koppolu said:

Is it possible to use pdma to directly read from gpio's and store in memory without isr?

 Please see the AM243x TRM Rev E, Table 11-626. PDMA Allocation across Device Domains. The table shows the PDMA serviced peripherals. GPIO is not included in the list.

Manoj Koppolu said:

is it possible to increase input clock frequency of r5f core?

The maximum R5F clock frequency is 800 MHz. By default, the R5F cores are configured for this frequency.

Manoj Koppolu said:

isr without memory transfer (if i include block transfer dma(UDMA) it will take atleast take 2.4us) :-1.2*2= 2.4us us

isr with mem transfer(without udma):-1.3*2= 2.6us
dclck:-at 2.5MHZ 0.4us

Can you please elaborate? Do you mean GPIO ISR with/without UDMA being used for transfer from GPIO to memory?

Regards,
Frank

Frank Livingston said:

The maximum R5F clock frequency is 800 MHz. By default, the R5F cores are configured for this frequency.

Even the R5F has input clock frequency max upto 800MHZ, but in sysconfig we making it as 25MHZ as it is sourced from 25MHZ LVCMOS oscillator, is there any way to increase the frequency to 800MHZ

Frank Livingston said:

Can you please elaborate? Do you mean GPIO ISR with/without UDMA being used for transfer from GPIO to memory?

yes, there is no use if i use udma to tranfer data into memory after one  sample from gpio's using isr

Hi Manoj,

Manoj Koppolu said:

Even the R5F has input clock frequency max upto 800MHZ, but in sysconfig we making it as 25MHZ as it is sourced from 25MHZ LVCMOS oscillator, is there any way to increase the frequency to 800MHZ

The max frequency of R5F is 800 MHz.

Please see the TRM:

• Table 4-3. PLL Reference Clock Selection
• 4.5 PLL Configuration
• Table 4-37. MAIN_PLL14 (PULSAR PLL) (2400MHz)

Manoj Koppolu said:

yes, there is no use if i use udma to tranfer data into memory after one  sample from gpio's using isr

Ok, it seems to me DMA has little effect on the timing (200 ns).

The key issue isn't the amount of time required to read data from GPIOs, but rather the amount of time required to service the GPIO ISRs. Hence, the GPIO ISR response time needs to be optimized.

Are you building your code in Release mode?

Have you considering using PRU IO instead of GPIO for interfacing to the ADC?

Regards,
Frank

Frank Livingston said:

Have you considering using PRU IO instead of GPIO for interfacing to the ADC?

iam doing it now

Hi Manoj,

Ok, let me know if you encounter any issues.

Regards,
Frank