LPC5536- ISR initialization time.  How fast do ISR's startup generally? - Page 1
Forum section: electronics / general

author: tangomonky
author_rank: Newbie
timestamp: August 06, 2025, 11:54:00 am
content: Hi guys,Kind of a general MCU ISR question, but specifically I have a LPC5536 with a 150Mhz clock.I am doing an application where I am triggering an interrupt on a pin, and than trying to toggle a different output pin based on the rising/or falling edge of my input pin. I wanted to do this very fast and it works, but for very fast speeds it starts to fail.So essentially around the <300ns mark, I can't really catch both the rising and falling edge of a signal and properly mirror it to the output.I guess my question is I never really thought about how many clock cycles I expect the MCU to take to initialize the ISR. It feels like that initialization time is around that 300ns mark right now, but I think intuitively I was expecting it to be 1/10th of that.Was hoping someone with more experience might tell me what they would consider an appropriate startup time for this type of function.Thanks!

author: Berni
author_rank: Super Contributor
timestamp: August 06, 2025, 12:21:50 pm
content: It is normal for MCUs to take a few cycles to enter an ISR because they have a fair bit of stuff to do in the background.Typically ARM cores need around 10 to 20 cycles to enter an ISR, this is because they have to backup the state of the CPU, then after leaving the ISR have to restore the CPU to this state before continuing execution.However this is only the CPU core cycles. It is likely that code is being executed from flash memory and the cache likely doesn't have the ISR service routine in it, so you also have to add in the flash read latency before the CPU gets instructions to execute. However this can be easily mitigated by placing the ISR routine inside a RAM area that is close to the CPU (Since that can typically run at 1:1 speed to the CPU, so access is single cycle)If you need to go this fast then GPIO interrupts are the wrong way to do it. Process the signal into something more friendly with external dedicated digital circuitry, or abuse some peripheral into looking for the pulses (like counting them with a timer).

author: Psi
author_rank: Super Contributor
timestamp: August 06, 2025, 12:36:23 pm
content: I've not looked at your specific MCU, but consider that the GPIO block doesnt always run at core CPU clock speed. It can be slower.

author: tangomonky
author_rank: Newbie
timestamp: August 06, 2025, 03:20:47 pm
content: Thanks for the tips guys, I thought they were great. Unfortunately adding it to RAM didn't seem to impact it, and the GPIO's are already running at max clock.I know hardware is the way to go forward, but I wanted to make sure I shook this tree as much as I could before looking toward the next goal.Thanks!

author: ejeffrey
author_rank: Super Contributor
timestamp: August 06, 2025, 03:22:47 pm
content: 300 nanoseconds is 45 clock cycles at 150 MHz. You are at the level where you need to count each one individually. That includes interrupt latency, isr execution time, and interrupt return.Can you show your isr, ideally including the generated assembly as well as the C source? It's easy to spend a dozen clock cycles or so without realizing it.From what I recall the NVIC also has some settings that might make a couple of clock cycles difference.Also check the issues mentioned with flash latency and GPIOs peripheral clock. Both are easy ways to lose a few clock cycles at a time. The NMI pin should have lower latency than the peripheral interrupt sources, so see if that's an option.How fast do you want it to go? My rough feeling from working with other arm chips is that you should be able to do better than 300 ns, but you probably aren't going to do better than 150 ns. If that's not fast enough you likely need a different design.

author: hans
author_rank: Super Contributor
timestamp: August 06, 2025, 03:41:35 pm
content: Interrupt latency on a Cortex-M33 is 12 cycles. The exit latency is iirc similar.So of those 45 cycles, already 24 of it is spent in saving and restoring context to jump in or out of the IRQ routine.Assuming 300ns is the time between interrupts, then I think 45-2*12=21 is a fair amount of time for reading and writing a few I/O registers.There is not much to gain here.. going the interrupt route always requires those 24 cycles. Maybe the 21 cycles can be optimized further (e.g. in case you're not using the compiler optimizer), but its not going to suddenly make this 2x better.Adding the code to RAM probably isn't going to fix the latency issues if you're using a repetitive signal to test. That means the interrupt code will remain on the FLASH cache line since the CPU is near 100% utilized to handle these interrupts. The worst case performance is possibly encountered right at startup, and is probably a few cycles slower.

author: ejeffrey
author_rank: Super Contributor
timestamp: August 06, 2025, 03:50:51 pm
content: Quote from: tangomonky on August 06, 2025, 03:20:47 pmA non-interrupt loop would probably be considerably faster, but of course you couldn't do anything else with the CPU at the same time. If your pulses are narrow but infrequent you could try sticking around in the interrupt handler polling for the falling edge.One thing I forgot about is tail chaining. Returning from an interrupt takes approximately the same time as entering an interrupt. But the Cortex M33 can do tail chaining where it skips un-stacking and re-stacking registers when an interrupt is already pending. That really reduces latency, but I don't know precisely the conditions to allow tail chaining. For instance, I don't know if you can tail chain from a single interrupt source back to itself.

author: tangomonky
author_rank: Newbie
timestamp: August 06, 2025, 05:12:56 pm
content: Good advice to look at the assembly. Seems to be telling me I am already around my limit here with what I was trying to do. Even when I break it down into just a toggle with no conditionals I can only save 75-100ns or so.Code:PIN_INT4_IRQHandler:20000000: push {r7}20000002: add r7, sp, #0359 PINT->IST = (1U << 4);20000004: mov.w r3, #1073758208 ; 0x4000400020000008: movs r2, #162000000a: str r2, [r3, #36] ; 0x24360 if (fps_active || system_fault) return; // Block on FPS active OR fault2000000c: ldr r3, [pc, #112] ; (0x20000080 <PIN_INT4_IRQHandler+128>)2000000e: ldrb r3, [r3, #0]20000010: uxtb r3, r320000012: cmp r3, #020000014: bne.n 0x20000076 <PIN_INT4_IRQHandler+118>20000016: ldr r3, [pc, #108] ; (0x20000084 <PIN_INT4_IRQHandler+132>)20000018: ldrb r3, [r3, #0]2000001a: uxtb r3, r32000001c: cmp r3, #02000001e: bne.n 0x20000076 <PIN_INT4_IRQHandler+118>362 if (MOD_FOLLOW_IN_GPIO->PIN & (1U << MOD_FOLLOW_IN_PIN)) {20000020: ldr r3, [pc, #100] ; (0x20000088 <PIN_INT4_IRQHandler+136>)20000022: add.w r3, r3, #8192 ; 0x200020000026: ldr.w r3, [r3, #260] ; 0x1042000002a: and.w r3, r3, #1048576 ; 0x1000002000002e: cmp r3, #020000030: beq.n 0x20000054 <PIN_INT4_IRQHandler+84>363 MOD_FOLLOW_OUT_GPIO->CLR = (1U << MOD_FOLLOW_OUT_PIN);20000032: ldr r3, [pc, #84] ; (0x20000088 <PIN_INT4_IRQHandler+136>)20000034: add.w r3, r3, #8192 ; 0x200020000038: mov r2, r32000003a: mov.w r3, #16384 ; 0x40002000003e: str.w r3, [r2, #644] ; 0x284364 V1_SW1_GPIO->SET = (1U << V1_SW1_PIN);20000042: ldr r3, [pc, #68] ; (0x20000088 <PIN_INT4_IRQHandler+136>)20000044: add.w r3, r3, #8192 ; 0x200020000048: mov r2, r32000004a: mov.w r3, #2097152 ; 0x2000002000004e: str.w r3, [r2, #512] ; 0x20020000052: b.n 0x20000078 <PIN_INT4_IRQHandler+120>366 MOD_FOLLOW_OUT_GPIO->SET = (1U << MOD_FOLLOW_OUT_PIN);20000054: ldr r3, [pc, #48] ; (0x20000088 <PIN_INT4_IRQHandler+136>)20000056: add.w r3, r3, #8192 ; 0x20002000005a: mov r2, r32000005c: mov.w r3, #16384 ; 0x400020000060: str.w r3, [r2, #516] ; 0x204367 V1_SW1_GPIO->CLR = (1U << V1_SW1_PIN);20000064: ldr r3, [pc, #32] ; (0x20000088 <PIN_INT4_IRQHandler+136>)20000066: add.w r3, r3, #8192 ; 0x20002000006a: mov r2, r32000006c: mov.w r3, #2097152 ; 0x20000020000070: str.w r3, [r2, #640] ; 0x28020000074: b.n 0x20000078 <PIN_INT4_IRQHandler+120>360 if (fps_active || system_fault) return; // Block on FPS active OR fault20000076: nop370 }Code:__attribute__((section(".ramfunc"))) void PIN_INT4_IRQHandler(void){PINT->IST = (1U << 4);if (fps_active || system_fault) return; // Block on FPS active OR faultif (MOD_FOLLOW_IN_GPIO->PIN & (1U << MOD_FOLLOW_IN_PIN)) {MOD_FOLLOW_OUT_GPIO->CLR = (1U << MOD_FOLLOW_OUT_PIN);V1_SW1_GPIO->SET = (1U << V1_SW1_PIN);} else {MOD_FOLLOW_OUT_GPIO->SET = (1U << MOD_FOLLOW_OUT_PIN);V1_SW1_GPIO->CLR = (1U << V1_SW1_PIN);}}

author: Siwastaja
author_rank: Super Contributor
timestamp: August 06, 2025, 06:15:47 pm
content: You can do tricks...For example, loading constants to CPU registers is an annoying delay. You could load the MOD_FOLLOW_OUT_GPIO->CLR (and similarly for SET) addresses into two CPU registers during initialization, and prevent compiler from using those registers elsewhere (-ffixed-reg, but beware of pre-compiled libraries!), which could make your critical piece faster with the expense of making everything else slower with fewer registers to use.And, do you really need to evaluate (fps_active || system_fault) at the ISR? You could have another fps_active_or_system_fault, and whoever writes to fps_active or system_fault, would also write to the combined flag. Orring isn't the expensive part, but you also need to load two variables. Or, even better, when fps_active or system_fault is updated, disable the interrupt instead, and remove the whole check. But be careful and think about edge cases.Needless to say, investigate the compiler-generated assembly very carefully (take a full day for it) and try to come up with something better.But, even more importantly, try to figure out creative ways of offloading this task, at least partially, to peripherals.

author: peter-h
author_rank: Super Contributor
timestamp: August 06, 2025, 07:18:31 pm
content: I vaguely recall the FPU has selectable status save, and that can take some time... No idea if this chip has got one.

author: ejeffrey
author_rank: Super Contributor
timestamp: August 06, 2025, 10:54:55 pm
content: What optimization setting are you using? The following pattern appears several times:Code:2000000e: ldrb r3, [r3, #0]20000010: uxtb r3, r3That looks redundant to me.

author: tggzzz
author_rank: Super Contributor
timestamp: August 06, 2025, 11:15:33 pm
content: Saving the context can be very veryveryslow on complex processors. That was one unsolved and unsolvable problem with the Itanic.There can be alotof undocumented internal state in a processor, and on top of that there's data/instruction/TLB caches to be flushed/reloaded.Best to have a very simple processor/process, preferably one without any state to save - i.e. just hardwareLet that very simple processor/process handle the short-latency requirements and buffer the information until an MCU can get around to it at its leisure.Or better use a hardware+software system where the IDE will state the exact number of cyclesbefore running the program. None of this "measure and hope we blundered across the worst case" rubbish. See the XMOS xCORE devices with the xTIME IDE.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 07, 2025, 08:22:52 am
content: Quote from: peter-h on August 06, 2025, 07:18:31 pmCortex-M FPUs have lazy stacking and start stacking when first FPU operation is encountered. Which is quite neat because it's "automagic" without having to configure anything. Just don't use floating point stuff in ISRs and there is no penalty. Or if you need float stuff, do timing critical things first.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 07, 2025, 08:26:48 am
content: Quote from: tggzzz on August 06, 2025, 11:15:33 pmtggzzz, let me remind you once more this forum section is called microcontrollers, and the particular example here is Cortex-M33. Your hallucination is completely irrelevant.

author: tangomonky
author_rank: Newbie
timestamp: August 13, 2025, 02:38:10 pm
content: Thanks for the help on this one guys. Ended up just using the SCT IN/OUT pins. I knew those would work, but was trying to get it to work without haha.

author: tggzzz
author_rank: Super Contributor
timestamp: August 13, 2025, 04:47:45 pm
content: Quote from: Siwastaja on August 07, 2025, 08:26:48 amNote the first sentence in the OP: "Kind of ageneral MCU ISR question..." Hence the OP is interested in behaviour exhibited intypicalMCUs.There are many processors used in MCUs which exhibit extended/variable latency, e.g. dual Cortex A9s. I am not going to find and examine a data sheet to determine the exact flavour of processor plus memory subsystem - especially when the OP is interested in more than one processor.The Itanic is the extreme poster boy for the context-switch latency problem, to the extent that it was a significant factor in sinking a multi-billion dollar programme. It serves to illustrate that the problem is real and can be crippling.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 13, 2025, 06:05:43 pm
content: Quote from: tggzzz on August 13, 2025, 04:47:45 pmStop trolling, please. You have been corrected on this numerous times, yet you choose to ignore this. Cortex A9 is not an MCU.

author: tggzzz
author_rank: Super Contributor
timestamp: August 13, 2025, 06:39:28 pm
content: Quote from: Siwastaja on August 13, 2025, 06:05:43 pmThis is going to degenerate into "there's no such thing as a trueScotsmanMCU".Please explain why this isn't an MCU...AMD Zynq™ 7000S SoCsZynq 7000S SoC devices feature a single-core Arm® Cortex®-A9 processor mated with 28 nm AMD Artix™ 7 based programmable logic, representing a low cost entry point to the scalable Zynq 7000 platform. Available with 6.25 Gb/s transceivers and outfitted with commonly used hardened peripherals, the Zynq 7000S delivers cost-optimized system integration ideal for industrial IoT applications such as motor control and embedded vision.Multi-Axis Motor ControlI/O Modules and Smart SensorsSmart Gridhttps://www.amd.com/en/products/adaptive-socs-and-fpgas/soc/zynq-7000.html#tabs-bea253336e-item-66aaed9bf5-tabThe AMD Zynq™ 7000 SoCs are dual A9s

author: Siwastaja
author_rank: Super Contributor
timestamp: August 13, 2025, 06:42:46 pm
content: Quote from: tggzzz on August 13, 2025, 06:39:28 pmPlease explain why bananas are not apples?Really, the only fundamental reason "AMD Zynq SoC" is not a microcontroller is that because everyone else except you agree that it is not a microcontroller. That is how language works - by commonly agreed meaning of terms. E.g. Wikipedia agrees:"A microcontroller (MC, uC, or μC) or microcontroller unit (MCU) ... ""In modern terminology, a microcontroller is similar to, but less sophisticated than, a system on a chip (SoC). A SoC may include a microcontroller as one of its components ...SoC is not an MCU. A SoC cancontainan MCU. It is well possible to have Cortex-A application CPU and Cortex-M microcontroller in the same SoC.You can also Google up lists of microcontrollers (e.g.https://en.wikipedia.org/wiki/List_of_common_microcontrollers) and verify the absence of these application CPUs and SoCs from all of those lists. It's very telling.One of the most defining factors of what is a microcontroller and what is not is exactly the kind of mis-features you list as being problems for interrupt latency.Are we done this time?

author: tggzzz
author_rank: Super Contributor
timestamp: August 13, 2025, 06:48:36 pm
content: Quote from: Siwastaja on August 13, 2025, 06:42:46 pmAs I predicted, a "No such thing as a true Scotsman" response.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 14, 2025, 06:42:45 am
content: Quote from: tggzzz on August 13, 2025, 06:48:36 pmSo, we can expect you continue intentional lying and trolling. Unsurprising.

author: tggzzz
author_rank: Super Contributor
timestamp: August 14, 2025, 06:45:39 am
content: Quote from: Siwastaja on August 14, 2025, 06:42:45 amDon't be a twat. Clearly the definitions arenotcast in stone and thereisa grey area.I realise English probably isn't your native language, but do you really want to use those terms?

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2025, 01:41:37 pm
content: Quote from: tggzzz on August 14, 2025, 06:45:39 amLying = intentionally making false or misleading claims. The fact you have been corrected numerous times proves it is intentional and not accidental.Trolling = writing provocative messages (e.g., by utilizing lying) to attract replies. Note the difference between trolling and just disagreement; if you were trulyjustin disagreement of the definition of what a microcontroller is, you would preface your repeating comments with that, e.g. like this: "Cortex-A, which I consider a microcontroller as opposed to many others, has TLBs..." That would be honesty, which I appreciate, but it would not generate the replies you, as a troll, want.I think lying and trolling are both natural human traits we all sometimes use, in varying amounts.Everyone else has stopped replying to your trolls a long time ago; I continue.

author: tggzzz
author_rank: Super Contributor
timestamp: August 15, 2025, 01:48:10 pm
content: Quote from: Siwastaja on August 15, 2025, 01:41:37 pmFor the record, a difference of opinion != lying. Differences in definitions have long been an issue.Take your point up with AMD w.r.t. the classification of the processors in a Zynq, or have a look at other definitions (Wackypedia is not definitive) such ashttps://www.techtarget.com/iotagenda/definition/microcontroller

author: Siwastaja
author_rank: Super Contributor
timestamp: August 15, 2025, 02:58:15 pm
content: Quote from: tggzzz on August 15, 2025, 01:48:10 pmWell, even that source specifically says: "Arm microcontrollers are also known as Arm Cortex-M microcontrollers." - specifically excluding Arm Cortex-A application processors.Otherwise, it does not talk about typical CPU architecture differences between microcontrollers and non-microcontrollers. This is something you pick up by experience by looking at what manufacturers themselves call microcontrollers in their documentation (both marketing and engineering data). You are totally right that things that totally blow up interrupt latency are unacceptable in microcontrollers. This is exactly why parts susceptible to it are not called microcontrollers.Disagreement on terminology is fine; it's OK if you think Arm Cortex-A is a typical example of a modern-day microcontroller, even though ARM themselves do not consider them microcontrollers. Just make sure to be upfront about it in the future, because it's averysurprising opinion to have. I would hope others would chime in and confirm this but I guess no one wants to touch these discussions anymore, and especially not take sides, because they are completely tired to your lazy trolling, and probably even more tired to my snarky responses to it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 15, 2025, 04:38:34 pm
content: The ARM-A cores are definitely not considered "microcontrollers", and I don't know of any commercially advertised "microcontroller" using a Cortex-A core.The -A and -M mean what they mean.After that, we can argue until the cows come home. Can we build "microcontrollers" around Cortex-A cores? Sure. Does anyone do that? Not really - mainly for price and market reasons.But is a hybrid FPGA/CPU such as the Zynq and others similar a "microcontroller"? That wouldn't cross my mind to call it that. But words are just words. As long as we understand one another.

author: tggzzz
author_rank: Super Contributor
timestamp: August 15, 2025, 06:03:25 pm
content: Quote from: SiliconWizard on August 15, 2025, 04:38:34 pmAnd that is the - very reasonable - point!Fundamentally very few things are black-and-white; mostly things are various shades of grey. The shades of grey have shifted considerably during my professional life, and will continue to shift towards more complex processors and processing, and towards more parallel processing. Might as well plan for the future, and not be stuck thinking that tomorrow's technology will look like today's technology.For example, how would you classify a networked processor in a rack executing share trading business rules? Server? Computer? Microprocessor? Microcontroller?My definition of a microcontroller is single function, embedded, peripherals peeked/poked directly from user code, comms (e.g. USB/CANBUS/ethernet), possibly an RTOS. Some of those functions might involve a lot of processing. By that reckoning a Zync can be - and is - used as a high end microcontroller. It could also be a low-end general purpose computer, but an RPi is probably more suitable for that.Oh, yes... those business rules and the networking stack should be classified as hardware, since both were implementeddirectly as gatesinside an FPGA. No computer involved! The HFT mob regularly spendsbillionsto shave a few microseconds off the latency.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 16, 2025, 01:13:40 am
content: Past some point, those are mainly "marketing" terms, in that they target specific markets.The more or less definite characteristic of a "microcontroller" is that it's "easy" to integrate, being normally able to run without any external active component. That means, having embedded memory to run code and host data.Peripherals - "application processors" often do have a bunch of these, but "back in the days" (when the so-called "application processors" did not formally exist and there were only CPUs, requiring not just memory, but a bunch of support chips to be usable), embedded peripherals were also a marker for "microcontrollers".So, I'd say that it's mainly this ability to run without any external memory or other interface chip that clearly defines a typical microcontroller. Of course, they are also usually marketed for "small" embedded needs, so they are lower power and simpler than the so-called application processors.And some SoC can blur the lines - for instance, I've been using the CV1800B/SG200x as beefy "microcontrollers". They are what we would call "application SoCs", but they do embed RAM and only need external power supplies and a crystal to run. They were not really meant to be used as "microcontrollers", but you can certainly do this.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 16, 2025, 05:39:05 am
content: Quote from: SiliconWizard on August 16, 2025, 01:13:40 amI'd say two distinct characteristics, compared to what classically is thecentral processing unitof acomputer* Integration of CPU, memory, peripherals etc. as you mention as one-chip solution,but also:* The controller part in the name! As opposed to processor which processes stuff, microcontroller controls some process.And think about the fundamental difference of process vs. control. Like, looking at maps to decice a route is processing. Driving a car is controlling. Guess which requires fast input, output and reaction times.This "to control" leads to different design priorities, as e.g. tggzzz's source mentions, difference in processing power. Because controlling something needs to be reliable, with least amount of uncertainty, delays and jitter, microcontroller cores do not go to extremes in increasing "processing power", likeprocessors(nowadaysapplication processorsas we say) do.This means: Simpler cores. Shorter pipelines. No virtual memory; no TLBs. Either no caches at all, or if there are, they are optional and there are tightly coupled memory regions you place the critical logic in. Short and predictable interrupt latency. And of course, most importantly, rich set of peripherals for offloading things that are not suitable for bit-bangingevenwith the relatively low interrupt latency.

author: tggzzz
author_rank: Super Contributor
timestamp: August 16, 2025, 09:26:28 am
content: Overall I regard vague classifications like "MCU" as being equivalent to adjectives, and I want "numbers not adjectives". After all, your idea of high-speed/cool/small/etc is not going to be the same as mine.The simplicity you mention is, IMNSHO,highlydesirable for hard real time operation, i.e. your "controlling".Things begin to blur when low latency is not required and remote operation is required, e.g. IoT devices. There, depending on technical and economic constraints, it can be appropriate to have much more complex processors.Nowadays single chip devices can befarmore complex than that and still be called microcontrollers, based on technical and application domain characteristics. The term MCU has become far more widely applicable and less specific, and it does lead the unwary down a problematic path. Shame, but thatwasbound to happen andwillcontinue in the future.As I noted, the "reverse" is also happening - e.g. business rules and networking stacks are no longer always implemented in software with operating systems on servers. Sometimes they are implemented in gates, via VHDL/Verilog/SystemC etc.