Replacing existing interrupt handler

OSCPUDEV
Posts: 22
Joined: Fri Jun 23, 2023 7:02 pm

Replacing existing interrupt handler

Postby OSCPUDEV » Tue Feb 04, 2025 7:40 pm

I have a level 5 interrupt handler that replaces the weak casting of the xt_highint5 interrupt handler That works perfectly, but now I need to be able to change this handler on the fly, not just at compile time. From looking at the low level includes, it seems that there is a function in the ROM that you can call to change the interrupt handler:

xt_set interrupt handler

I have not been able to get this to compile:

Code: Select all

xt_set_interrupt_handler(INTR_NUM, &new_xt_highint5, NULL);
No matter how I format this (using & or * or nothing with the handler name), I get the same compiler error:

Code: Select all

Compilation error: invalid conversion from 'void (*)()' to 'xt_handler' {aka 'void (*)(void*)'} [-fpermissive]
The interrupt code is located in a .S (assembly) file. I have tried every version of 'extern' that I can think of to make sure there is an association.

Does anyone know how to make this compile? I am using the Arduino v2.0.17 core (because v3.x core breaks many things I have to use).

Thanks!

MicroController
Posts: 1992
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: Replacing existing interrupt handler

Postby MicroController » Tue Feb 04, 2025 7:48 pm

Code: Select all

invalid conversion from 'void (*)()' to 'xt_handler' {aka 'void (*)(void*)'}
Seems that your handler function is declared as new_xt_highint5() while it should be new_xt_highint5(void* arg).

OSCPUDEV
Posts: 22
Joined: Fri Jun 23, 2023 7:02 pm

Re: Replacing existing interrupt handler

Postby OSCPUDEV » Wed Feb 05, 2025 1:44 am

Can you give me an example of how this should be done? I have the extern defined as:

extern "C" void new_xt_highint5();


There is a routine (assembly code) called new_xt_highint5, and it is a copy of the interrupt routine that I have been using successfully for the xt_highint5 replacement, but with a different pin to toggle and LED (so I know it is the correct routine being used). I am not even getting that far because of the compile error mentioned above.

MicroController
Posts: 1992
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: Replacing existing interrupt handler

Postby MicroController » Wed Feb 05, 2025 9:25 am

Code: Select all

extern "C" void new_xt_highint5(void* arg);

User avatar
ok-home
Posts: 113
Joined: Sun May 02, 2021 7:23 pm
Location: Russia Novosibirsk
Contact:

Re: Replacing existing interrupt handler

Postby ok-home » Wed Feb 05, 2025 1:00 pm

in any case, this function will not work
https://github.com/espressif/esp-idf/bl ... ntr.c#L131
it's for interrupts less than level 3

xt_highint5 is not a function but a label in asm code
there is a reference to _Level5Vector in the table of vectors
https://github.com/espressif/esp-idf/bl ... rs.S#L1846

I think the easiest way is to write xt_highint5 with conditional transition to your handlers in one code depending on some variable.

MicroController
Posts: 1992
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: Replacing existing interrupt handler

Postby MicroController » Wed Feb 05, 2025 8:27 pm

In addition to what @ok-home said, chances are you don't need to use a high-level interrupt in the first place. Most of the time when people want to use high-level interrupts it doesn't actually solve their problem.

JimDrew
Posts: 13
Joined: Sun Jun 14, 2020 10:28 pm

Re: Replacing existing interrupt handler

Postby JimDrew » Thu Feb 06, 2025 8:10 am

MicroController wrote:
Wed Feb 05, 2025 9:25 am

Code: Select all

extern "C" void new_xt_highint5(void* arg);
I will try this.

::edit::
OK, this routine seems that this is just testing and installing the interrupt handler into a vector table? Espressif told me that the vector table was ROM based (created at compile time). I guess this is not true afterall? Are the highlevelint5 and NMI interrupt handler pointers in this same table?

I do need the high level interrupts. I am currently using Int5 and NMI, and know these inside out. I program nearly everything in assembly code, converting any C code wherever possible. I realize that most people here are probably C coders and don't care about latency. That is not the case for me and the applications that I create. I am not sure how the interrupt setup works (tables and such), and Espressif has been less than forthcoming about this. I have a NDA with Cadence, but they can't discuss any of the Espressif stuff. I would prefer to just replace the entire vector table and use only assembly code with direct vector access. Using a branch method with a single Int5 or NMI interrupt, even with something quick like bit testing and branching, is adding several more instruction cycles that I actually need for successfully using the ESP32-S3 in a current project. Most CPUs have individual vectors for each peripheral or hardware function. I would like to confirm my suspicions that the ESP32-S3 (which is what I am using), might have just a single vector pointing to a main ISR that then filters and handles all interrupts. I think this because the time it takes from firing an interrupt until you are inside of the highlevelInt5 handler is about 220ns. That is an eternity for a CPU with an instruction time of 4.1667ns... so I am guessing that the interrupt fires and has to traverse a list or something before arriving at the handler that is installed I looked at my code and everything associated with the matrix and interrupts is called from ROM and not available in the elf file (which can be used for making a disassembly). Anyone know how to dump the entire from from so you can look at the low flash memory?

MicroController
Posts: 1992
Joined: Mon Oct 17, 2022 7:38 pm
Location: Europe, Germany

Re: Replacing existing interrupt handler

Postby MicroController » Thu Feb 06, 2025 9:21 am

Check xtensa_vectors.S to see what interrupt handlers do on Xtensa-FreeRTOS.
JimDrew wrote:
Thu Feb 06, 2025 8:10 am
I program nearly everything in assembly code, converting any C code wherever possible. I realize that most people here are probably C coders and don't care about latency.
I disagree with the premise that compiled C code has lower performance than assembly code. Especially because the compiler does a lot of optimization you can hardly do manually (register allocation/re-use, pipelining, constant propagation, context-dependent inlining,...).

JimDrew
Posts: 13
Joined: Sun Jun 14, 2020 10:28 pm

Re: Replacing existing interrupt handler

Postby JimDrew » Thu Feb 06, 2025 10:35 am

MicroController wrote:
Thu Feb 06, 2025 9:21 am
Check xtensa_vectors.S to see what interrupt handlers do on Xtensa-FreeRTOS.

Thanks. I am aware of this. What I want to know is what the ROM code is doing though, as that is what calls these high level routines. Application code only generates elf files containing the main code and other than the address, there is no info about the function calls for anything (like interrupt setup) in the ROM code. I guess I need to look into dumping the ROMs so that I can look at what these routines actually do.

MicroController wrote:
Thu Feb 06, 2025 9:21 am
I disagree with the premise that compiled C code has lower performance than assembly code. Especially because the compiler does a lot of optimization you can hardly do manually (register allocation/re-use, pipelining, constant propagation, context-dependent inlining,...).

:) Spoken like someone who does not have more than four decades of experience writing assembly language on literally dozens of processors as a normal part of their day job!

The ESP32 is a capable processor, but the lack of documentation for low level system functionality is a bit annoying. I was hoping that someone had already figured out how to replace ALL of the default interrupt handlers to save myself some time.

User avatar
ok-home
Posts: 113
Joined: Sun May 02, 2021 7:23 pm
Location: Russia Novosibirsk
Contact:

Re: Replacing existing interrupt handler

Postby ok-home » Thu Feb 06, 2025 12:14 pm

Thanks. I am aware of this. What I want to know is what the ROM code is doing though, as that is what calls these high level routines. Application code only generates elf files containing the main code and other than the address, there is no info about the function calls for anything (like interrupt setup) in the ROM code. I guess I need to look into dumping the ROMs so that I can look at what these routines actually do.
https://github.com/espressif/esp-idf/bl ... rs.S#L1672
Each vector goes at a predetermined location according to the Xtensa
hardware configuration, which is ensured by its placement in a special
section known to the Xtensa linker support package (LSP). It performs
the minimum necessary before jumping to the handler in the .text section.
https://github.com/espressif/esp-idf/bl ... m.ld#L1406

Who is online

Users browsing this forum: Bing [Bot] and 48 guests