# PIC32MX Interrupt crashes system **URL:** \ **Category:** Microchip\ **Created:** [February 16, 2020, 4:33pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818 "2020-02-16T16:33:49Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 16, 2020, 4:33pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/1 "2020-02-16T16:33:49Z")
I started a new thread because since I am using Harmony 3, I believe this is a new issue, even if others have seen similar behavior before. With MLAB X 5.30, the XC Complier, and the latest Harmony 3 code configurator, I have written a small test project that sends “Hello” out UART2, and toggles a GPIO output pin, which is jumpered back to a CN (change modification) pin, IE an interrupt is generated on a change detected. So two sources of interrupt (UART TX and CN pin) are generated at a leisurely pace (about 1/sec). This sample project runs successfully, with no FreeRTOS in the mix. * * * Then using Harmony 3, I add FreeRTOS to the project, not changing any settings, and the program crashes with an exception type 7 “Data bus error”. This exception occurs as soon as the first interrupt occurs of either type. I have tried changing various parameters, but nothing I have tried has made any difference. From my reading, I know that FreeRTOS has some fancy tricks for context switching, using a separate ISR stack. Perhaps some recent change in Harmony has created an incompatibility. Any help would be appreciated, I have spent 2 weeks on this, my outside consultant, and the Microchip engineer working on this have yet to find a fix either. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [February 16, 2020, 5:31pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/2 "2020-02-16T17:31:43Z")
As you say you used Harmony to add FreeRTOS into the project you would imagine it should work - have you asked this question to Microchip also as it is all code generated by their tools? Please post the code for the two interrupt handlers so I can see what they are doing - no doubt have questions after that too. ---
**Author:** ![rashed](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rashed/32/14_2.png) [@rashed](https://forums.freertos.org/u/rashed)\ **Post date:** [February 16, 2020, 6:02pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/3 "2020-02-16T18:02:09Z")
Moving to Microchip category. [@Microchip](https://forums.freertos.org/groups/microchip) might have a quicker answer. ---
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 16, 2020, 6:04pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/4 "2020-02-16T18:04:36Z")
@rtel Thank you for your reply. I have asked Microchip and at least two of their people are looking at this issue. One of them encouraged me to ask for help at FreeRTOS, since they knew more about the integration than Microchip did! ## Interrupt handlers in Harmony 3, at least the part I am expected to code, look very different than those of the past. Most interrupt processing now takes place “under the hood” it seems. In fact the Interrupt handler for the UART is not my code at all, Harmony creates it. Anyway here they are: In the case of the CN pin, the only part I need to create is a read-back routine, and then register it. Here is the code for the callback: ```auto uintptr_t cn7_context; int cn_registration_success; void callback_fn( CN_PIN pin, uintptr_t cn7_context ) { GPIO_PinToggle(GPIO_PIN_RD0); // on-board RED led } ``` Here is the code to register and enable interrupts on the pin: ```auto cn7_context = 0; cn_registration_success = GPIO_PinInterruptCallbackRegister( CN7_PIN, callback_fn, cn7_context); GPIO_PinInterruptEnable(CN7_PIN); ``` This is the code (created by Harmony 3 I am guessing) that calls my read-back routine: ```auto /* Function: void CHANGE_NOTICE_InterruptHandler() Summary: Interrupt Handler for change notice interrupt. Remarks: It is an internal function called from ISR, user should not call it directly. */ void CHANGE_NOTICE_InterruptHandler() { uint8_t i, bitPosition; uint32_t latestPortValue, mask; bool currPinValue; /* Check which CN interrupt has occurred and call callback if registered */ for(i = 0; i < TOTAL_NUM_OF_INT_USED; i++) { latestPortValue = *(volatile uint32_t *)(&PORTA + ((cnPinObj[i].gpioPin >> 4) * 0x10)); bitPosition = cnPinObj[i].gpioPin % 16; mask = 1 << bitPosition; currPinValue = (bool)((latestPortValue & mask) >> bitPosition); if((cnPinObj[i].prevPinValue != currPinValue) && (cnPinObj[i].callback != NULL)) { cnPinObj[i].prevPinValue = currPinValue; cnPinObj[i].callback (cnPinObj[i].cnPin, cnPinObj[i].context); } } IFS1CLR = _IFS1_CNIF_MASK; } ``` * * * Here is the code (Harmony 3 created probably) for the UART interrupts: ```auto void UART_2_InterruptHandler (void) { /* Call RX handler if RX interrupt flag is set */ if ((IFS1 & _IFS1_U2RXIF_MASK) && (IEC1 & _IEC1_U2RXIE_MASK)) { UART2_RX_InterruptHandler(); } /* Call TX handler if TX interrupt flag is set */ else if ((IFS1 & _IFS1_U2TXIF_MASK) && (IEC1 & _IEC1_U2TXIE_MASK)) { UART2_TX_InterruptHandler(); } /* Call Error handler if Error interrupt flag is set */ else if ((IFS1 & _IFS1_U2EIF_MASK) && (IEC1 & _IEC1_U2EIE_MASK)) { UART2_FAULT_InterruptHandler(); } } ``` In the case of a TX interrupt (the only type I am using right now) is here (again this is not code I wrote myself. Like most above, it was created by Microchip tools. ```auto static void UART2_TX_InterruptHandler (void) { if(uart2Obj.txBusyStatus == true) { while((!(U2STA & _U2STA_UTXBF_MASK)) && (uart2Obj.txSize > uart2Obj.txProcessedSize) ) { U2TXREG = uart2Obj.txBuffer[uart2Obj.txProcessedSize++]; } /* Clear UART2TX Interrupt flag after writing to buffer */ IFS1CLR = _IFS1_U2TXIF_MASK; /* Check if the buffer is done */ if(uart2Obj.txProcessedSize >= uart2Obj.txSize) { uart2Obj.txBusyStatus = false; /* Disable the transmit interrupt, to avoid calling ISR continuously */ IEC1CLR = _IEC1_U2TXIE_MASK; if(uart2Obj.txCallback != NULL) { uart2Obj.txCallback(uart2Obj.txContext); } } } else { // Nothing to process ; } } ``` * * * There is a file called interrupts.c, which is of little help either: ```auto void CHANGE_NOTICE_InterruptHandler( void ); void UART_2_InterruptHandler( void ); /* All the handlers are defined here. Each will call its PLIB-specific function. */ void CHANGE_NOTICE_Handler (void) { CHANGE_NOTICE_InterruptHandler(); } void UART_2_Handler (void) { UART_2_InterruptHandler(); } --------------------------------------- and there is another, called interrupts_a.S shown here: #include #include "ISR_Support.h" .extern CHANGE_NOTICE_Handler .section .vector_26,code, keep .equ __vector_dispatch_26, IntVectorCHANGE_NOTICE_Handler .global __vector_dispatch_26 .set nomicromips .set noreorder .set nomips16 .set noat .ent IntVectorCHANGE_NOTICE_Handler IntVectorCHANGE_NOTICE_Handler: la $26, _CHANGE_NOTICE_Handler jr $26 nop .end IntVectorCHANGE_NOTICE_Handler .section .CHANGE_NOTICE_Handler_vector_text, code, keep .set nomicromips .set noreorder .set nomips16 .set noat .ent _CHANGE_NOTICE_Handler _CHANGE_NOTICE_Handler: portSAVE_CONTEXT la s6, CHANGE_NOTICE_Handler jalr s6 nop portRESTORE_CONTEXT .end _CHANGE_NOTICE_Handler .extern UART_2_Handler .section .vector_32,code, keep .equ __vector_dispatch_32, IntVectorUART_2_Handler .global __vector_dispatch_32 .set nomicromips .set noreorder .set nomips16 .set noat .ent IntVectorUART_2_Handler IntVectorUART_2_Handler: la $26, _UART_2_Handler jr $26 nop .end IntVectorUART_2_Handler .section .UART_2_Handler_vector_text, code, keep .set nomicromips .set noreorder .set nomips16 .set noat .ent _UART_2_Handler _UART_2_Handler: portSAVE_CONTEXT la s6, UART_2_Handler jalr s6 nop portRESTORE_CONTEXT .end _UART_2_Handler ``` ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [February 16, 2020, 6:41pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/5 "2020-02-16T18:41:17Z")
> [@robert-scott](#): > > uart2Obj.txCallback(uart2Obj.txContext); Is your callback making any calls to the FreeRTOS API? If so, are you using the interrupt safe API? (the functions will end “FromISR” is so). > [@robert-scott](#): > > \_UART\_2\_Handler: It appears this is installed on its on vector, so is branched to by the hardware directly rather than through a single interrupt entry point. Is that the case? ---
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 16, 2020, 7:00pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/6 "2020-02-16T19:00:42Z")
> Is your callback making any calls to the FreeRTOS API? If so, are you using the interrupt safe API? (the functions will end “FromISR” is so). In this example project, I am not using the FreeRTOS API at all. (But I am really looking for to doing so once this Interrupt issue is resolved.) * * * > It appears this is installed on its on vector, so is branched to by the hardware directly rather than through a single interrupt entry point. Is that the case? I do not know the answer to your question. While I have programmed embedded systems for over 20 years, this is my first try in using Microchip products or FreeRTOS. Up to this point, I was using Zilog processors and writing my own version of an RTOS. It is not clear to me how all this fits together. ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [February 16, 2020, 7:25pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/7 "2020-02-16T19:25:07Z")
If you are not using the FreeRTOS API in the interrupt handler it can only be the interrupt entry and exit changes that could be the source of the issue. Try increasing the configISR\_STACK\_SIZE value in FreeRTOSConfig.h. ---
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 16, 2020, 7:35pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/8 "2020-02-16T19:35:58Z")
The ISR stack size was set to 512, I changed it to 4096. No apparent difference, it seems to fail the same way. BTW, The call stack indicates the exception was line 114 in app.c. Ran it several times, 114 is consistent. ``` void APP_Tasks ( void ) ``` { ``` /* Check the application's current state. */ switch ( appData.state ) <------------------this is line 114 { /* Application's initial state. */ case APP_STATE_INIT: { bool appInitialized = true; if (appInitialized) { appData.state = APP_STATE_SERVICE_TASKS; } break; } ``` ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [February 17, 2020, 12:05am UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/9 "2020-02-17T00:05:38Z")
If that line is aborting my guess would be the value of appData is invalid at that point, so attempting to dereference it takes you into the weeds. ---
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 17, 2020, 12:08am UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/10 "2020-02-17T00:08:08Z")
If that is the issue, then I assume to context was not restored. ---
**Author:** ![saikumar.k](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@saikumar.k](https://forums.freertos.org/u/saikumar.k)\ **Post date:** [February 18, 2020, 9:49am UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/11 "2020-02-18T09:49:42Z")
Hi, To find the function in which issue is generating please go through the following steps: 1. In MPLAB X IDE , open Windows-\>Target Memory Views-\>Execution Memory in which you can refer to “label” where the specific function causing the problem will be detected. 2.Also, lets check if there would be any function calling in an ISR. In FreeRtos without using proper ThreadSafe API’s like portYieldFromISR, portEndswitchfromISR, API’s should not be called in ISR. If you did that, scheduler might be halted at “exception handler” and causes “Target halted due to bus instruction error”. ---
**Author:** ![saikumar.k](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@saikumar.k](https://forums.freertos.org/u/saikumar.k)\ **Post date:** [February 18, 2020, 10:16am UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/12 "2020-02-18T10:16:45Z")
> [@robert-scott](#): > > uintptr\_t cn7\_context; int cn\_registration\_success; void callback\_fn( CN\_PIN pin, uintptr\_t cn7\_context ) { GPIO\_PinToggle(GPIO\_PIN\_RD0); // on-board RED led } Lets check this once: **in callbackfn file.c** extern TaskHandle\_t xled; uintptr\_t cn7\_context; int cn\_registration\_success; void callback\_fn( CN\_PIN pin, uintptr\_t cn7\_context ) { ``` BaseType_t xYieldRequired; /* Resume the suspended task. */ xYieldRequired = xTaskResumeFromISR( xled); if( xYieldRequired == pdTRUE ) { portYIELD_FROM_ISR(); // [or portEND_SWITCHING_ISR()] } } ``` now in : **system\_tasks.c file** #include “system\_config.h” #include “system\_definitions.h” #include “app.h” TaskHandle\_t xled; void \_ToggleLed(){ ``` while( vTaskSuspend( NULL ); GPIO_PinToggle(GPIO_PIN_RD0); // on-board RED led SYS_CONSOLE_MESSAGE("\n Hello"); // To Uart2 vTaskDelay(1000 / portTICK_PERIOD_MS); ) ``` } Create a Task: xTaskCreate((TaskFunction\_t) \_ToggleLed, “led\_toggling”,200, NULL, 1, xled); ---
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 18, 2020, 12:03pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/13 "2020-02-18T12:03:07Z")
@saikumar.k Thank you for your suggestions. I tried inserting the additions to callback\_fn() but I must need some includes, as it no longer compiles, see below. Also I do not have a file called “system\_tasks.c” there is a file called “tasks.c” is that the one you are suggesting changing? This sample project came from a Microchip engineer, and the led toggle takes place inside main.c ``` make[2]: Entering directory 'C:/MTT/H3_UART2_RTOS_RSL/firmware/UART_RTOS.X' ``` …/src/main.c:31:1: error: unknown type name ‘TaskHandle\_t’ extern TaskHandle\_t xled; ^ …/src/main.c: In function ‘callback\_fn’: …/src/main.c:37:3: error: unknown type name ‘BaseType\_t’ BaseType\_t xYieldRequired; ^ …/src/main.c:39:5: error: implicit declaration of function ‘xTaskResumeFromISR’ [-Werror=implicit-function-declaration] xYieldRequired = xTaskResumeFromISR( xled); ^ …/src/main.c:40:27: error: ‘pdTRUE’ undeclared (first use in this function) if( xYieldRequired == pdTRUE ) ^ “C:\Program Files (x86)\Microchip\xc32\v2.30\bin\xc32-gcc.exe” -g -x c -c -mprocessor=32MX795F512L -ffunction-sections -O1 -I…/src -I…/src/config/default -I…/src/packs/PIC32MX795F512L\_DFP -I…/src/mips -Werror -Wall -MMD -MF build/default/production/\_ext/1360937237/main.o.d -o build/default/production/\_ext/1360937237/main.o …/src/main.c -DXPRJ\_default=default -no-legacy-libc “-mdfp=C:/Program Files (x86)/Microchip/MPLABX/v5.30/packs/Microchip/PIC32MX\_DFP/1.1.215” nbproject/Makefile-default.mk:208: recipe for target ‘build/default/production/\_ext/1360937237/main.o’ failed make[2]: Leaving directory ‘C:/MTT/H3\_UART2\_RTOS\_RSL/firmware/UART\_RTOS.X’ nbproject/Makefile-default.mk:91: recipe for target ‘.build-conf’ failed …/src/main.c:40:27: note: each undeclared identifier is reported only once for each function it appears in …/src/main.c:42:7: error: implicit declaration of function ‘portYIELD\_FROM\_ISR’ [-Werror=implicit-function-declaration] portYIELD\_FROM\_ISR(); // [or portEND\_SWITCHING\_ISR()] ^ cc1.exe: all warnings being treated as errors make[2]: \*\*\* [build/default/production/\_ext/1360937237/main.o] Error 1 make[1]: Leaving directory ‘C:/MTT/H3\_UART2\_RTOS\_RSL/firmware/UART\_RTOS.X’ make[1]: \*\*\* [.build-conf] Error 2 nbproject/Makefile-impl.mk:39: recipe for target ‘.build-impl’ failed make: \*\*\* [.build-impl] Error 2 BUILD FAILED (exit value 2, total time: 359ms) ---
**Author:** ![saikumar.k](https://avatars.discourse-cdn.com/v4/letter/s/7bcc69/32.png) [@saikumar.k](https://forums.freertos.org/u/saikumar.k)\ **Post date:** [February 18, 2020, 12:20pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/14 "2020-02-18T12:20:10Z")
Okay. I was given you just the pseudo code. Sorry for not providing full information. In microchip, MPLAB X IDE if you go to harmony configurator and generate the code with selecting Freertos in Thirdparty in Framework, You will get generated project file with system\_task.c. Whatever the file either it might be main.c or sytem\_task.c no problem. but if you want an application to run, a task must be created like the pseudo given above. also, please refer to Mplab harmony help and Freertos reference manuals demo projects in the folder : C:\microchip\harmony\v2\_06\apps\rtos\freertos\basic\firmware\basic\_freertos.X. Hope it helps you! ---
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 18, 2020, 1:24pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/15 "2020-02-18T13:24:12Z")
@saikumar C:\microchip\harmony\v2\_06\apps\rtos\freertos\basic\firmware\basic\_freertos.X. Based on the above link, I think your suggestions may apply to Harmony 2 rather than harmony 3? One of your suggestions involves adding code to, I assume, each interrupt handler. But in the case of a UART, the framework creates all the interrupt handlers without code like you suggest. So either the Framework makes a mistake in its creation of those interrupt handlers, or the interrupt process itself has a bug. * * * One of the issues with Harmony 3 is that it is rather new and very few demo projects are available. I have created so many different projects trying out my own or others ideas that I have trouble keeping them straight. The one thing, at least so far, is that no mater what I try, the system crashes in the same way. I think the problem exists in one of these files: **ISR\_Support.h** **interrupt\_a.S** The first was written by the FreeRTOS folks, and the second by Microchip. The first defines macros for saving and restoring the context of interrupted code, while the second looks to be the initial entry/exit point for all interrupts. Once FreeRTOS is added to a Harmony 3 project, even before adding any calls to the FreeRTOS API, processing of interrupts is altered by adding the above 2 files (and likely other changes). There does not seem to be any options to avoid this new interrupt processing. From what I have read, the new FreeRTOS interrupt processing does two things: 1. It uses a separate ISR stack, so that each task does not have to have room in it’s own stack, and, 2) code is added to allow higher priority interrupts to interrupt lower priority ones. Maybe this is true with Harmony 2 as well, not sure. Do these files exist in a Harmony 2 project? ---
**Author:** ![SergentSloGin](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/sergentslogin/32/48_2.png) [@SergentSloGin](https://forums.freertos.org/u/SergentSloGin)\ **Post date:** [February 18, 2020, 2:38pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/16 "2020-02-18T14:38:03Z")
Hi Robert, I found that the whole Harmony thing was a bit of a pain. 1. Make sure that in the configuration bits you have: #pragma config FSRSSEL = PRIORITY\_7 By default Harmony sets that as 0 which crashes the whole thing at the first interrupt. 1. For the external pin interrupt, to take an easy example, I have the following code Obviously you need to initialise the interrupt controller and the interrupt priority settings for it to fire. In the a name.c file ``` void vInitExternalInterrupt( void) { IPC1SET = ((2<<_IPC1_INT1IP_POSITION)&_IPC1_INT1IP_MASK)| 0x0; INTCONCLR = _INTCON_INT1EP_MASK; //External interrupt on falling edge IFS0CLR = _IFS0_INT1IF_MASK; // Clear the external interrupt flag IEC0SET = _IEC0_INT1IE_MASK; // Enable the external interrupt } void __attribute__ ( (interrupt(IPL0AUTO), vector(_EXTERNAL_1_VECTOR))) vExternalInterruptWrapper( void ); void vExternalInterruptHandler( void ) { BaseType_t bTaskWasWoken = pdFALSE; IFS0CLR = _IFS0_INT1IF_MASK; // Clear the interrupt // Post a message into a queue using the FromISR variant portYIELD_FROM_ISR(bTaskWasWoken); } ``` In a name\_isr.s file (assembly, yes ☹ ) ``` #include #include #include "ISR_Support.h" .set nomips16 .set noreorder .extern vExternalInterruptHandler .extern xISRStackTop .global vExternalInterruptWrapper .set noreorder .set noat .ent vExternalInterruptWrapper vExternalInterruptWrapper: portSAVE_CONTEXT jal vExternalInterruptHandler nop portRESTORE_CONTEXT .end vExternalInterruptWrapper ``` Hope this helps solve your problem. ---
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 19, 2020, 4:46am UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/17 "2020-02-19T04:46:43Z")
Hi SergentSloGin, Thank you for posting your code. It took a bit of time, but I was able to get a CN Interrupt to work by modifying your example. I wonder why Harmony 3 does not generate the needed code automatically (they already generate so much I would think these few lines would not be a big deal), or if not, at least make it easier to find details as to what is needed. As I see it, there is a complete disconnect between the Interrupt Hardware and the Interrupt routines they do provide, with no hints that something is missing. It would seem that the EVIC section would be the place for these “wrapper” routines. If not the code, at least some notes. If there are already docs about this, I did not find them even after I looked for several weeks, including other people pitching in, trying to solve this issue. BTW, I was not able to find the header containing the prototype for: **portYIELD\_FROM\_ISR(bTaskWasWoken);** So I commented out that line. I think to use that function, there is a call to make to set pdFalse first. I am not interested in making a task switch when processing an interrupt in any case. I remember reading about that in my research. It seems to run without it. I was also not able to find a Symbolic name for the vector 26, so I just put in the number instead. Come to think of it, I think I will create a file called evic\_a.S and put all the Internet (asm) wrappers in there. ---
**Author:** ![SergentSloGin](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/sergentslogin/32/48_2.png) [@SergentSloGin](https://forums.freertos.org/u/SergentSloGin)\ **Post date:** [February 19, 2020, 11:02am UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/18 "2020-02-19T11:02:50Z")
Hi Robert, portYIELD\_FROM\_ISR is defined in portmacro.h which resides under FreeRTOS\Source\include\portable\MPLAB\PIC32MX The same folder contains ISR\_Support.h which is included in the assembler files. I tend to keep the ISR wrappers in separate assembler files along with the “peripheral” C code. Putting all the interrupt wrappers in a single file also works, just makes it slightly less transferable between projects. My version of a change notification ISR: ``` void __attribute__ ( (interrupt(IPL0AUTO), vector(_CHANGE_NOTICE_VECTOR))) vChangeNotificationInterruptWrapper( void ); void vChangeNotificationInterruptHandler( void ) { BaseType_t bTaskWasWoken = pdFALSE; IFS1CLR = _IFS1_CNIF_MASK; // Clear the interrupt // post a message to a queue with bTaskWasWoken changed by the call portYIELD_FROM_ISR(bTaskWasWoken); } ``` Note that the interrupt priority (IPL0AUTO) is irrelevant here, the priorities are set in the IPCx registers. Jean ---
**Author:** ![robert-scott](https://avatars.discourse-cdn.com/v4/letter/r/d6d6ee/32.png) [@robert-scott](https://forums.freertos.org/u/robert-scott)\ **Post date:** [February 19, 2020, 1:10pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/19 "2020-02-19T13:10:53Z")
Hi Jean, You are right the AmazonFreeRTOS does define **portYIELD\_FROM\_ISR( x )** in portmacro.h but strangely the CMSIS version does not. Looking at the definition, it just becomes a conditional call to portYIELD. I am thinking that permitting a portYIELD while in an ISR is not necessary, perhaps not even desirable, for my application. I plan to put all my interrupts at the same priority, and to clear the interrupt flags at the end of processing rather than the beginning. That being the case, this is what I am doing, please comment. In interrupts.c, I added this line: ``` **void __attribute__ ( (interrupt(IPL0AUTO), vector(_CHANGE_NOTICE_VECTOR))) vChangeNotifierInterruptWrapper( void );** ``` This sets up the interrupt to call the assembler wrapper, which I have set to call **CHANGE\_NOTICE\_Handler** a function in plib\_gpio.c created by harmony 3. So I register my call back like this: ``` cn_registration_success = GPIO_PinInterruptCallbackRegister( CN6_PIN, callback_fn, cn6_context); ``` To enable the interrupts, I have these two lines. Not sure if both are needed. ``` EVIC_SourceEnable( INT_SOURCE_CHANGE_NOTICE ); GPIO_PinInterruptEnable(CN6_PIN); ``` Thanks, Robert ---
**Author:** ![SergentSloGin](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/sergentslogin/32/48_2.png) [@SergentSloGin](https://forums.freertos.org/u/SergentSloGin)\ **Post date:** [February 19, 2020, 4:33pm UTC](https://forums.freertos.org/t/pic32mx-interrupt-crashes-system/8818/20 "2020-02-19T16:33:26Z")
Hi Robert, I initially tried to use the Harmony generated code as well, but because of the issues that you are running into, I decided to scrap that and just use Harmony as a bare bones code generator which I then incorporated into my own source tree. It’s taken quite a bit of effort to figure out what was generated and what was in the sample programs and how they differed from each other. Now that I have a working “template” I will stick to this hybrid solution. I must admit that Harmony generated code is still some ways off to being usable in the more complex setups. It’s fine for simple programs but the integration with an RTOS is far from smooth sailing, unlike on other platforms (ST comes to mind). As for whether you need to call portYieldFromISR or not, that’s entirely application specific. If you place something into a queue or message buffer from the ISR it will eventually get picked up by the rest of your application code. The reason to try and yield from the ISR is so that any task that is waiting on the object that you just posted can be activated on return from the ISR rather than waiting for a forced context switch from the scheduler. It’s a trade-off between predictable task sequencing and system responsiveness. As the saying goes: horses for courses. Jean