problem with slow toggling GPIO on SAMA5D27C

Discussion around products based on ARM Cortex-A5 core.

Moderator: nferre

Posts: 11
Joined: Tue Oct 03, 2017 11:29 am

problem with slow toggling GPIO on SAMA5D27C

Fri Feb 01, 2019 10:22 am


could someone, please, help me understand what's going on?

Consider the following main loop:

int main(void)
unsigned int out = 0;
out = ~out; //this is logical negation, I'm not sure if tilde or hyphen is displayed
piob->PIO_MSKR = (1 << 14);
piob->PIO_ODSR = out;
return 0;

(The variable 'out' undergoes logical negation, but on my screen tilde is displayed as a minus, so it looks like assigning -0. This is not the case here - it is 0 to 0xffffffff and the 0 again, and...)

This program just toggles PB14. I don't present initialization here. The main clock is generated by the 12 MHz internal RC oscillator, and then multiplied in PLL (by factor 83). The core runs at 498 MHz, MCK = 166 MHz, so I assume that peripheral clock of PIO is 83 MHz. This peripheral clock is enabled in PMC. Frequency of MCK can be verified by configuring, say, PCK1 to use MCK and divide it by 250. The resulting square waveform (PCK1) has frequency near 666 kHz, that is the expected value.

The program is built with GCC 4.9, with optimization -Os. The while loop disassembles to:

2104ec: 43e4 mvns r4, r4
2104ee: f44f 4280 mov.w r2, #16384 ; 0x4000
2104f2: 601a str r2, [r3, #0]
2104f4: 619c str r4, [r3, #24]
2104f6: e7f8 b.n 2104ea <main+0xae>

I would expect that this loop takes more or less 10 processor cycles, some in the core, some accessing the system bus. Assuming that all cycles are of MCK (lower bound), the waveform generated by toggling PB14 has frequency equal to MCK / 10 = 16.6 MHz.

My oscilloscope shows only ca. 1.85 MHz. What is going on?

Best regards,
Posts: 14
Joined: Fri Sep 28, 2018 2:51 pm

Re: problem with slow toggling GPIO on SAMA5D27C

Fri Feb 01, 2019 10:41 pm

I'd first verify that your clocks are doing what you think they should be. If you are using the atmel software package like I have been, it isn't foolproof.

For example, with manually calling slowclock_select_external(SLOWCLOCK_DOMAIN_DEFAULT) , the stock build doesn't use the external 32khz crystal, rather the internal oscillator.

You can check actual cycles by using the PMCCNTR

Code: Select all

 static inline void enable_PMCCNTR(void) {
     asm volatile ("mcr p15, 0, %0, c9, c12, 1" :: "r"(1 << 31));
     //Enable PMCNTENSET
     asm volatile ("mcr p15, 0, %0, c9, c14, 0" :: "r"(1));
     asm volatile ("mcr p15, 0, %0, c9, c12, 0" :: "r"(0xD));//PMCR Enable(0) Reset(2) Div64(3)
 static inline uint32_t pmc_cntr(void)
      uint32_t pmccntr;
     asm volatile("MRC p15, 0, %0, c9, c13, 0" : "=r"(pmccntr));
     return pmccntr;
I'm not sure how active this forum is, I'm not sure if this is the official one or not, judging by the lack of traffic I see.
Posts: 14
Joined: Fri Sep 28, 2018 2:51 pm

Re: problem with slow toggling GPIO on SAMA5D27C

Fri Feb 01, 2019 10:44 pm

Also, you should make sure data and instruction cache is enabled, or it isn't going to be real fast.
Posts: 18
Joined: Wed Apr 25, 2018 6:36 pm

Re: problem with slow toggling GPIO on SAMA5D27C

Tue Feb 19, 2019 7:11 pm

Any resolution of this?

I am very interested in this subject as I too have been stymied when trying understand processor speed in terms of instruction execution. And, I am NOT interested so much in improving performance (making it run faster), I'd like to be able to predict speed by understanding what the important factors are. I suspect that is processor clock but also maybe RAM access timing etcetera.

It would be interesting if you could get the compiled code to use registers only without accessing memory and see if the 16 MHz rate is achieved. Or just code it up in assembly language.

Return to “SAMA5D Cortex-A5 MPU”

Who is online

Users browsing this forum: No registered users and 8 guests