Cortex A8 GPIO toggle speed limitation and interrupt latency

Gilen

Other Parts Discussed in Thread: AM3354, AM3352, AM3359

Dear Sirs,

I am toggling the GPIO1_23 in a baremetal firmware with only one instruction in dissasenbly to set and another one to clear. The cortex A8 has a 550 MHz clock, but I only get 12,5 MHz toogle in the GPIO. I have enabled MMU and Cache.
The reference manual says that the GPIO clock is 100 MHz, so I expected to obtain close to this frecuency toggle.
Is there any limitation on the GPIO toggle?

I am studying the performance of the Sitara microprocessors family, to validate its viability in an application with real-time requirements.

I have been measuring the interrupt latency in GPIO1_28 too, and I have get arround 600 nanoseconds. I expected better performance, 100-200 nanoseconds that I could obtain with a Cortex M3 at 120 MHz. Can I do something to improve this latency? Is there any pragma or configuration setting in TMS470 compiler to avoid storing the context and records in the interruption service routine?
Thanks,

Gilen

over 12 years ago

0 Biser Gatchev-XID over 12 years ago

TI__Guru**** 393215 points

Hi Gilen,

Here is a post that may help you understand the low GPIO toggle frequency: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/202814.aspx

0 Gilen over 12 years ago in reply to Biser Gatchev-XID

Intellectual 300 points

Hi Biser,

This post doesn't answer my question.

It says: "So, it is unlikely to be the CPU operating frequency that is causing the delay. At 200MHz L3 speed, 470ns is 94 cycles for two - set and clear - operations."

So, what is causing the delay? My dissasembly code with optimizations is of an instruction for set and clear, theorically 2 cycles. In my case, with cache and MMU enabled, the delay time is of 80 nseconds. So, at 200 MHz, time for 16 cycles. Where are spending the rest of the 14 cycles?

What about the GPIO interrupt latency?

Thank you for your time and regards,

Gilen

0 Biser Gatchev-XID over 12 years ago in reply to Gilen

TI__Guru**** 393215 points

Hi Gilen,

The cause for this latency is that the Cortex-A8 MPU is on the L3F interconnect, and GPIO's are on L4_PER. So the path is Cortex-A8 -> L3F -> L3S -> L4_PER -> GPIO. Each of these transitions introduces a delay of several cycles (I don't have the exact figures). It's pretty much the same for the GPIO interrupt.

0 Gilen over 12 years ago in reply to Biser Gatchev-XID

Intellectual 300 points

Dear Biser,

That could explain the GPIO toggle delay.

But the Technical Reference Manual describes the Interrupt Handling, with 4 cycles for interrupt generation, 10 functional clock cycles for priority sorting and some more cycles for the time that could be spent in context save at CPU clock of 550 Mhz. What is the reason for 600 ns latency? It could be that 80-100 ns are for GPIO managetment, but what about the other 500 ns? The context save is large enough to spend this time? And could I optimize this by don't saving the context? How could I configure the TMS470 compiler to don't save that? Is there any other reason for this high latency that I'm not considering?

Thanks,

Gilen

0 Biser Gatchev-XID over 12 years ago in reply to Gilen

TI__Guru**** 393215 points

Hi Gilen,

Can you tell me what processor you are talking about?

0 Gilen over 12 years ago in reply to Biser Gatchev-XID

Intellectual 300 points

Hi Biser,

I'm doing the test with the Beaglebone (Am3359), but we are thinking for the final product in a cheaper one of the same family, maybe AM3352 or AM3354.

Regards,

Gilen

0 Biser Gatchev-XID over 12 years ago in reply to Gilen

TI__Guru**** 393215 points

I was asking because I got confused from your mentioning the TMS470 compiler. Aside from that, all the processors in the AM335X family have generally the same characteristics, except speed grade and +/- some peripherals. Regarding interrupt handling, the TRM is the correct source of information. Figure 6-2 shows the typical flowchart.

0 Gilen over 12 years ago in reply to Biser Gatchev-XID

Intellectual 300 points

Hi Biser,

I understand the "Figure 6-2. IRQ/FIQ Processing Sequence", but the question is, if can this sequence spend 600 nseconds at 500 MHz CPU clock, 1000 ARM MIPS as datasheet says? Or am I missing any cosideration?

Thanks,

Gilen

0 Biser Gatchev-XID over 12 years ago in reply to Gilen

TI__Guru**** 393215 points

I don't know how you have setup your experiments and how are doing your measurements. Here are some measurements done under Linux:

http://processors.wiki.ti.com/index.php/AM335x-PSP_04.06.00.08_Features_and_Performance_Guide#Interrupt_Latency_Measurement

However, have you considered using the PRU_SS. Here is a post which states that they have achieved 200MHz toggle speed via PRU_SS:

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/194511.aspx

0 Gilen over 12 years ago in reply to Biser Gatchev-XID

Intellectual 300 points

The Linux tests have an interrupt latency 10-15 useconds. I am testing with a baremetal software, a simple GPIO interrupt, with 600 nseconds latency. However, I think that is too long for a processor running at 720 MHz. And I have no explanation for this behavior.

The AM3352 and AM3354 haven't got PRU-SS unit, that are our selection for cost requirements.

Any other performance analysis of AM335x without operating system or with SYS/BIOS?

Thanks and regards,

Gilen

Processors

Processors forum

Cortex A8 GPIO toggle speed limitation and interrupt latency