• AVR Freaks

AnsweredHot!PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR

Author
hamster
New Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2019/08/23 06:16:37
  • Location: 0
  • Status: offline
2020/02/13 05:35:54 (permalink)
0

PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR

I am experiencing a strange bug. I have the current Interrupt Priorities set:
USART1-3: Level2
_FLASH_CONTROL_VECTOR: level3
_USB_VECTOR level4
_USB_DMA_VECTOR: level4
When I define the USART ISR routine as follows:
void  __attribute__((interrupt(ipl2AUTO),vector(_UART_1_RX_VECTOR), no_fpu)) _ReceiveIsrUsart1 (void) {
// USART ISR goes here
}
 
The program will crashes with a Run-Time exception at the entrance of
void __ISR(_USB_VECTOR, ipl4AUTO) _IntHandlerUSBInstance0(void). Since I am sending alot of data on the USART ports there is probably a nested interrupt. I.e. the _USB_VECTOR is interrupting the USART.

However, if I change the ISR definition to ipl4AUTO. I.e. to a higher priority than it actual has and as high as the USB_IPL, then my program works. How can that be? If I try to increase the actual interrupt priority to a value higher than _USB_VECTOR and _USB_DMA_VECTOR my program also crashes.

Thanks for your time.
#1
jdeguire
Super Member
  • Total Posts : 555
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: online
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/13 11:51:23 (permalink)
0
Check the value of the PRISS register.  You want it to be 0x76543210.
#2
hamster
New Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2019/08/23 06:16:37
  • Location: 0
  • Status: offline
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/20 02:02:30 (permalink)
0
Hi and thanks for your reply, I am replying a bit late as I am only working on this project  1 day a week.

The value of the PRISS register is 0x300. I.e. bit 8 and 9 are set. This seems correct to me. I am allocating Shadow Set 3 for Interrupt Level 2. UART is configured with Interrupt level 2.

When I annotate the UART ISR with ipl2SRS the program crashes at a USB interrupt handler. When I annotate it with ipl4SRS it runs fine.

Anyone have any idea how that can be? How does the IPL annotation change the ISR?


#3
al_bin
Super Member
  • Total Posts : 196
  • Reward points : 0
  • Joined: 2011/02/11 06:28:47
  • Location: 0
  • Status: offline
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/20 13:36:19 (permalink)
0
hamster
Anyone have any idea how that can be? How does the IPL annotation change the ISR?



If IPL for USB and UART are equal you have no nested interrupts.
If not,  all functions in irq handlers must be reentrant.
 
Albert
#4
jdeguire
Super Member
  • Total Posts : 555
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: online
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/21 09:51:20 (permalink) ☄ Helpfulby hamster 2020/02/27 08:54:22
5 (1)
Does removing the "no_fpu" argument from your UART1 receive interrupt declaration have any effect?
 
What you may want to do is implement your own _general_exception_handler() and _simple_tlb_refill_exception_handler() so you can determine what the exception code (Cause register) and program counter (EPC register) are.  The XC32 Users Guide will provide more info on those functions.
#5
Mysil
Super Member
  • Total Posts : 3670
  • Reward points : 0
  • Joined: 2012/07/01 04:19:50
  • Location: Norway
  • Status: offline
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/21 11:29:25 (permalink)
5 (1)
Hi,
I think PRISS register setting  in message #3 is Wrong:
PRISS register is 0x300

PRISS register is Not single bit flags, it is 4 bit fields, with register set assignment for each priority level.
With register value 0x300, there is only Priority level 2 interrupts that have Shadow set registers.
Priority level 3 and priority level 4 Interrupts use Register Set 0 == same as main program code,
Are you absolutely sure that there is No interrupt code anywhere in the program calling for  IPL3SRS  or IPL4SRS ?
 
IPLxSRS change ISR prolog and epilog code to assume that hardware shadow set registers are in use,
thus Saving and Restore of GPR registers is not needed.
Instead, when SRS registers are used, the Stack Pointer must be fetched from the register set that was previously used.
 
Why not try as jdeguire suggest in message #2, and assign a separate Shadow register set to each priority level?
 
    Mysil
 
#6
hamster
New Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2019/08/23 06:16:37
  • Location: 0
  • Status: offline
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/27 08:54:09 (permalink)
0
Hi guys. Thanks alot for your suggestions.
 
- I tried your suggestion of allocating a SRS for each IPL. It does not solve the issue, but it seems like a good idea to have it as default. It does also raise another question. If the SRS are allocated to a IPL, what happenes if a IRQ interrupts one that is running, on the same IPL but different sub priority level? Then the SRS has to be stored, but how would the CPU know?
- Then I tried removing the _no_fpu_ annotation, and that seems to have solved the problem. Now I have UART Interrupt configured at IPL2 and I also annotate the ISR with IPL2SRS. No Runtime exception in the USB IRS. But why is that happening? The USB IRS has a higher priority than the UART so it will interrupt it from time to time. I would really like to keep  the _no_fpu as it saves considerable time and we are processing alot of data through UART.

The _excep_code that I can read in the general exception handler is 0x03010401
_excep_code = (_CP0_GET_CAUSE() & 0x0000007C) >> 2;
#7
hamster
New Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2019/08/23 06:16:37
  • Location: 0
  • Status: offline
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/27 09:02:35 (permalink)
0
Additional piece of information. If I instead of removing _no_fpu from USART, add it to _IntHandlerUSBInstance0 and _IntHandlerUSBInstance0_USBDMA then also there is no problem. Can someone shed some light on this?
 
#8
andersm
Super Member
  • Total Posts : 2800
  • Reward points : 0
  • Joined: 2012/10/07 14:57:44
  • Location: 0
  • Status: offline
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/27 10:42:02 (permalink) ☄ Helpfulby hamster 2020/02/28 08:35:50
5 (2)
hamsterIf the SRS are allocated to a IPL, what happenes if a IRQ interrupts one that is running, on the same IPL but different sub priority level?

The sub-priority determines which interrupt is serviced first, but an interrupt can never pre-empt another interrupt with the same priority level.
 
The _excep_code that I can read in the general exception handler is 0x03010401
_excep_code = (_CP0_GET_CAUSE() & 0x0000007C) >> 2;

Do you mean cause register value, because that is not a possible exception code? Are you using the auto-prologue, or other MCU ASE features?
 
If you're having trouble figuring out what's accessing the FPU, you could try disabling access to coprocessor 1 at the start of each ISR, and wait for a coprocessor unusable exception.
post edited by andersm - 2020/02/27 10:57:22
#9
jdeguire
Super Member
  • Total Posts : 555
  • Reward points : 0
  • Joined: 2012/01/13 07:48:44
  • Location: United States
  • Status: online
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/27 11:52:57 (permalink) ☼ Best Answerby hamster 2020/02/28 08:31:46
5 (2)
What is probably happening is that using "no_fpu" disables the FPU entirely such that trying to use FPU instructions will cause an exception (I don't remember which, but andersm is probably correct that it's a Coprocessor Unusable exception).  Then you get interrupted by another higher-level interrupt that does not have "no_fpu" set.  This means that it will try to save off FPU state because the interrupt isn't aware that the FPU has been disabled and thus the context-saving code will trigger the exception.  The FPU is Coprocessor 1 and uses the mtc1 and mfc1 instructions to move stuff to and from the FPU registers.  Disabling the FPU presumably makes these instruction invalid as they're being used to access a coprocessor that isn't enabled.
 
Therefore, you would either have the mark all higher-level interrupts as also having "no_fpu" or remove it entirely.
 
An interrupt will never be interrupted by one of the same priority, even if the pending interrupt has a higher sub-priority.  The sub-priority is used to determine who goes first if both interrupt flags are set at the same time.
#10
hamster
New Member
  • Total Posts : 29
  • Reward points : 0
  • Joined: 2019/08/23 06:16:37
  • Location: 0
  • Status: offline
Re: PIC32MZ2048EFH114 Mismatch between IPC and IPL definition in ISR 2020/02/28 08:35:41 (permalink)
0
andersm:
Thanks for clearifying how pre-emption works! The value I reported is what I see by setting a watchpoint on the variable _exec_code in the general execption handler and using PicKit4 to read it. I agree that it seems to be garbage. Do you have another suggestion for how to get the actual value?

jdeguire:
Thanks alot for your explanation. That totally makes sense. I will have to analyze all ISRs to see if i can add the no_fpu attribute.

- Thank you to everyone helping me out here. Really great.


 
#11
Jump to:
© 2020 APG vNext Commercial Version 4.5