• AVR Freaks

Hot!PIC32MX795F512L Exception

Author
andrewshivers
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2019/02/15 08:08:03
  • Location: 0
  • Status: offline
2019/10/11 07:27:53 (permalink)
0

PIC32MX795F512L Exception

Hello,
 
I have a collection of legacy code using a PIC32 that has an issue with an exception being thrown at random times. Unfortunately their are no unit tests for this codebase, and its kind of a mess in general. However when we run an automated test against the board in general, the board will reset at random times. Sometimes 10 minutes into the test, sometimes 4 hours in. In the exception handler it catches error code IS1, which i gathered means "Implementation Specific 1" but, I cant seem to find any more information about what that means. It also catches at the same PC address everytime: 0xa0003F96, but MPLAB can't resolve that to a file of line number. I was wondering if anyone has any advice on how to debug such an issue?
 
Thanks!
#1

4 Replies Related Threads

    Larry.Standage
    Super Member
    • Total Posts : 926
    • Reward points : 0
    • Joined: 2011/12/30 09:50:47
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512L Exception 2019/10/11 09:20:53 (permalink)
    0
    The IS1 exception shouldn't happen, because it is tied to having Coprocessor 2 attached to the core, which isn't possible with the 795. Are you sure that the exception code isn't 0x04? Keep in mind that the EXCCODE field is shifted to the left by 2 bits, so reading the CAUSE register directly won't read the same as the actual code.
     
    The reason I ask that is because the 0x04 code is an Address Error Exception (Load or Instruction Fetch), which makes sense with the address value. Any instruction fetch or 32-bit data fetch has to be 32-bit aligned, and that address is off by 2 bytes.
     
    Because the address is in SRAM, unless you know that code is executing in SRAM, it would have to be a data/stack pointer misalignment.
     
    #2
    andrewshivers
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2019/02/15 08:08:03
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512L Exception 2019/10/23 13:20:07 (permalink)
    0
    Larry.Standage
    The IS1 exception shouldn't happen, because it is tied to having Coprocessor 2 attached to the core, which isn't possible with the 795. Are you sure that the exception code isn't 0x04? Keep in mind that the EXCCODE field is shifted to the left by 2 bits, so reading the CAUSE register directly won't read the same as the actual code.
     
    The reason I ask that is because the 0x04 code is an Address Error Exception (Load or Instruction Fetch), which makes sense with the address value. Any instruction fetch or 32-bit data fetch has to be 32-bit aligned, and that address is off by 2 bytes.
     
    Because the address is in SRAM, unless you know that code is executing in SRAM, it would have to be a data/stack pointer misalignment.
     


    Hi Larry,
     
    Thanks for your response, I double checked my exception handler code, and it is shifting the code to the right to compensate it being shifted to the left.
    _excep_code=_CP0_GET_CAUSE() & 0x0000007C >> 2;

    And it is definitely returning 0x10. 
    I checked the MAP file and that address is for a buffer that is not utilized in the mode that I am seeing the reset in.
    #3
    andersm
    Super Member
    • Total Posts : 2667
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512L Exception 2019/10/23 13:40:38 (permalink)
    0
    The shift operators have higher precedence than the bitwise and operator.
    _excep_code = (_CP0_GET_CAUSE() & 0x0000007C) >> 2;

    #4
    andrewshivers
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2019/02/15 08:08:03
    • Location: 0
    • Status: offline
    Re: PIC32MX795F512L Exception 2019/10/23 13:52:49 (permalink)
    0
    Ah of course,
     
    I'll fix it and try to catch the exception again.
    #5
    Jump to:
    © 2019 APG vNext Commercial Version 4.5