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

XMC™ Forum Discussions

Not applicable
Hello,

I am using the XMC4500-E144x1024 microcontroller with Dave Apps. I wrote a program to react on an external trigger signal that is repeated with a frequency of 2.5 MHz.

The ERU001 App gets the signal as Input A and triggers on a rising edge. The ERU002 App has the pattern edge trigger enabled (Pattern Match). The gated trigger output of ERU002 is assigned to an instance of the NVIC002-App. The corresponding interrupt handler toggles an output pin when the interrupt occurs.

I experienced that the response to my external trigger signal on Input A has a delay of more than 550 ns. In the picture the blue line is the input A signal, the yellow line is the output of the IO004-pin that is toggled by the interrupt handler.

429.attach

As I need a reaction in less than 400 ns in order to evaluate the 2.5 MHz input signal properly, I am trying to improve the timing of the ERU. I searched the reference manual of the microcontroller for some register settings which specify ERU delays or priorities but I wasn't successful. Does anyone have a suggestion to solve that problem?


Thank you in advance!


My Configuration:
Clock Settings: 120 MHz system frequency, 60 MHz peripheral bus frequency
Used Apps: ERU001, ERU002, IO002, IO004, NVIC002, PWMSP001
NVIC Priority: 63 (dec)
The project is small and simple, so I guess interferences of other apps can be excluded.
0 Likes
6 Replies
User6412
Level 4
Level 4
Make sure you run your interrupt routine in RAM, not in FLASH. Also for speeding up it is preferable not to use the Apps, or at least you can take a deep look inside the generated code. Some times this code it is not really optimal for speed. Take a look on compiler settings (optimization level -o3 is a good choice). From my personal experience the ERU unit has very fast reaction speed of a few nanoseconds.
0 Likes
Not applicable
Hello Dmitry,

thank you very much for your response!

Your advice to set optimization level to -o3 improved the performance of the above program so that the reaction occured after 410 ns.

By now I know that the NVIC App is slowing down the program, because I tried another approach:
ERU001 passes its flag status output to ERU002's pattern detect input. The ERU002's pattern match output is then directly put out to a IO002-Pin.
This results in a response delay of 30 nanoseconds.
466.attach

Unfortunately this solution is not adequate, because my application demands for a trigger signal on the output (i.e. a short chip select signal). Apparently the gated trigger output of ERU002 cannot be redirected to a pin.

Maybe your first suggestion can help speeding up my NVIC app. But I'm not sure how to determine whether the interrupt routine is located in RAM or in FLASH. Could you explain this to me?

Greetings!
0 Likes
Not applicable
hi!

I am trying to communicate with an IC which has a 3-wire serial communication protocol, CLK, DATA, and SCSB for communication start. The CLK signal i am using a PWMSP001 app with a duty cycle of 50% and frequency of 33Mhz. I am reading the data pin in the compare mach interrupt of the PWM. However, I believe the pin reading takes more time than the interrupt period. So, is there a way to increase the pin reading speed? How do I make sure that I am running the interrupt routine in RAM, and not in FLASH?
0 Likes
Not applicable
hi!

I am trying to communicate with an IC which has a 3-wire serial communication protocol, CLK, DATA, and SCSB for communication start. The CLK signal i am using a PWMSP001 app with a duty cycle of 50% and frequency of 33Mhz. I am reading the data pin in the compare mach interrupt of the PWM. However, I believe the pin reading takes more time than the interrupt period. So, is there a way to increase the pin reading speed? How do I make sure that I am running the interrupt routine in RAM, and not in FLASH?
0 Likes
Not applicable
Hi RicardoWT,

I believe your question is the same for this post How to read a port faster?
I think is better we keep it to one thread.
0 Likes
Not applicable
Yes it is true, the this is I am not sure if the thread is active.
0 Likes