Having trouble with interrupt latency and cycle time in M0+

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Zahir
Level 1
Level 1
First reply posted First question asked Welcome!

Hello. This is my first time using an ARM MPU having trouble from past 2 weeks trying to figure out why there is higher than normal interrupt latency and about 125+ns of cycle time for a Nop.

https://www.infineon.com/dgdl/Infineon-S6E1A_Series_32_bit_Arm_Cortex_M0+_FM0+_Microcontroller-DataS...

Using a cypress arm M0+ for which the datasheet is above. Running the CPU at 40Mhz using an external oscillator which should give a cycle time of 25ns. Verified the prescaler values and also verified the clock by generating a PWM of 5Khz using the formula they provide. Everything checks out. But when i run the following code they dealy for one NOPs measured to be about 125ns. I know there is a latency for the I/O but comparing the timing for toggling the I/O without a NOP and with one i get the time for it. 

 FGpio1pin_Put(GPIO1PIN_P21, 0u);
  __ASM volatile ("NOP");
 FGpio1pin_Put(GPIO1PIN_P21, 1u);
  __ASM volatile ("NOP");
 FGpio1pin_Put(GPIO1PIN_P21, 0u);
  __ASM volatile ("NOP");
 FGpio1pin_Put(GPIO1PIN_P21, 1u);
  __ASM volatile ("NOP");
 FGpio1pin_Put...

 

 

Code

 

I have also tried using a loop to generate busy waits using NOPs over a longer duration and got the same result. 

Is this something to do with ARM? I checked the clock prescalers and generated a PWM everything checks out. When i try to do busy waits the cycle time is no where near 25ns. Moreover the interrupt latency is 3ms at best for NMI and 4-6us for GPIO interrupts. From the datasheet the interrupt should be in 500ns. Also from the datasheet this particular MPU has zero wait states.

The code is bare bones main loop using the PDL library cypress provides.

 

I know these are two different problems or maybe not but I am trying to understand why a NOP which should take a cycle to complete, at 40Mhz it is behaving as though it is running at 8Mhz. Reducing the clock prescalers does increase the cycle time of NOPs.

How do I verify clock in Arm M0+ other than what i have tried with PWM and NOPs ? Any pointers will be appreciated.

0 Likes
1 Solution

> How is SysTick timer different from just using an oscilloscope to measure the toggle? 

The idea <is> to use a scope for verification.

You are expecting a core clock frequency of e.g. 40MHz, and set an appropriate SysTick value. Like with such a call:  SysTick_Config (SystemCoreClock / 100);

Toggle a GPIO in the SysTick interrupt handler, and you can measure the actual clock frequency with a scope.  Clock setup can fail e.g. for specifying a wrong quartz frequency (which had happened to me), and the system falls back to the internal RC oscillator.

For interrupts itself, latency of the Cortex M is generally 12 cycles. Perhaps you know, but here is a reference explaining it a bit in detail: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/beginner-gui...

And, as said, GPIO accesses have to routed via internal busses to the peripheral unit. The Cortex M does not behave like a 8051 or PIC18 in this regard, were you can specify an exact cycle number.

 

View solution in original post

0 Likes
3 Replies
zzz_3221081
Level 5
Level 5
25 solutions authored 100 sign-ins 10 likes received

> I know there is a latency for the I/O but comparing the timing for toggling the I/O without a NOP and with one i get the time for it. 

I know of no Cortex M that does a GPIO access in one cycle. To the contrary, most devices have bandwidth filters to avoid glitches.

> FGpio1pin_Put(GPIO1PIN_P21, 0u);

I would recommend to check what this function call actually evaluates to. Most probably not even a single instruction.

> How do I verify clock in Arm M0+ other than what i have tried with PWM and NOPs ? Any pointers will be appreciated.

I use the SysTick timer. The respective code is CMSIS, and thus part of basically every Cortex M BSP/library. This is a 24 bit timer, and I usually set it to 10ms and measure the actual duration via GPIO toggle.

Clock/PLL setup for external quartzes can fail, so checking the frequency is a good idea.

0 Likes

How is SysTick timer different from just using an oscilloscope to measure the toggle? 

The FGpio function generates 3 assembly lines.

0x000002A2 2000 MOVS r0,#0x00
0x000002A4 4902 LDR r1,[pc,#8] ; @0x000002B0
0x000002A6 6388 STR r0,[r1,#0x38]

Have already checked external quartz also checked PWM for the set frequency. It is the cycle time per instruction i am not able to match up to the set clock of 40Mhz

0 Likes

> How is SysTick timer different from just using an oscilloscope to measure the toggle? 

The idea <is> to use a scope for verification.

You are expecting a core clock frequency of e.g. 40MHz, and set an appropriate SysTick value. Like with such a call:  SysTick_Config (SystemCoreClock / 100);

Toggle a GPIO in the SysTick interrupt handler, and you can measure the actual clock frequency with a scope.  Clock setup can fail e.g. for specifying a wrong quartz frequency (which had happened to me), and the system falls back to the internal RC oscillator.

For interrupts itself, latency of the Cortex M is generally 12 cycles. Perhaps you know, but here is a reference explaining it a bit in detail: https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/beginner-gui...

And, as said, GPIO accesses have to routed via internal busses to the peripheral unit. The Cortex M does not behave like a 8051 or PIC18 in this regard, were you can specify an exact cycle number.

 

0 Likes