Redirecting to the General Exception Handler - defaults at a loop instead of jumping to the handler in Exception.c.

[nyh-workshop]

Hello there, I'm working with a custom Chipkit platform and I could not get the exception handler to jump into the handler function in "exceptions.c". Instead, it just stays at the loop in the cpp-startup.S:

        ##################################################################
        # General Exception Vector Handler
        # Jumps to _general_exception_handler
        ##################################################################

#if defined(USE_OLD_DOTSECTION)
        .section .gen_handler,"ax",@progbits
#else
        .section .gen_handler,code
#endif

        .set noreorder
        .ent _gen_exception
_gen_exception:
        la      k0,_gen_exception
        jr      k0
        nop

It loops around the _gen_exception, and there is no way to retarget this to the _general_exception_context like in the MPLAB XC32. I have to modify the cpp-startup.S to make it to jump into that area, but risking the other packages compile with errors.

Where does the _gen_exception located? Is there a way to override the startup's _gen_exception? Manually including another startup *.S file in the respective variant folder doesn't overwrite this part, but appended into the code as a new one, while the loop is still there.

Please advise if I have missed out on something here. Thanks for the help.

[majenkotech]

I thought I had already fixed this, as it's something I use sometimes as well. Maybe I never committed the changes...

[nyh-workshop]

Hello majenko, the code snippet is from that current chipKIT-core github - perhaps for the next update?

Also, some of us like to override the exception handler from the exception.C. Is it okay if you can make that declaration in the exception.C "weak"?

[majenkotech]

Yup. That's what I thought I'd already done anyway...

[nyh-workshop]

I see... Can it be done on the remaining exception handlers like the TLB refill and the cache error? Also, I'm thinking of harnessing it directly to the serial to display the offending address and the cause.

However, a look at the debugger reveals that the interrupts are shut off during the exception. I'm not even sure if adding extra codes in the exception handler is okay on that situation.

[majenkotech]

Ok, I have added the exception handler - though slightly differently. We have our own stub now which gets the exception code and address for you from the C0 and passes that to your custom weak function.

• PR #409

You are quite correct that you can't use anything that needs interrupts in the exception handler. That means delay, etc, are out. As is Serial, since that is interrupt driven. Nothing to stop you directly manipulating the peripheral registers directly to output text messages though.

[nyh-workshop]

Thanks, majenko. Also, how about the TLB refill exception and the cache error? It seems that all these can be easily hit by a misaligned addressing and accidentally writing/reading at wrong/invalid address.

All of us can easily make these mistakes during programming, and bringing out these handlers will be also convenient as many of us don't have pickit3 for debugging. (And also some of us never preferred Harmony too)

[majenkotech]

Those seem to be handled slightly differently and call some internal library function for the exception. I guess we could change that, but I don't know at the moment what those library functions actually do.

[majenkotech]

Digging through the pic32-part-support source it looks like it just calls a weak handler anyway, which we don't define. So just defining that in your sketch with a C context should do the job anyway.

extern "C" {
    void _simple_tlb_refill_exception_handler() {
    }

    void _cache_err_exception_handler() {
    }
}

[nyh-workshop]

Hello Majenko, Apologies for the late reply. Thanks for the tips - it helps in isolating the problems before I try using my Pickit3. I'm closing this issue as resolved. 👍