• AVR Freaks

Hot!PIC18F26K42 A1 silicon and interrupts

Author
MikaelNordman
Starting Member
  • Total Posts : 33
  • Reward points : 0
  • Joined: 2008/01/27 04:18:59
  • Location: 0
  • Status: offline
2019/02/15 11:04:00 (permalink)
0

PIC18F26K42 A1 silicon and interrupts

I have a pretty complex application called FlashForth that I am attempting to get to work on the K42 series.
Everything works just fine, but if I have the 1 millisecond timer 1 interrupt enabled the main program starts to crash.
It seems that some register gets corrupted. Don't know which one.
The code is coded using the old style high priority interrupts only.
The registers that the timer1 interrupt uses (BSR and WREG) should be automatically saved and restored by the hardware.
Has anyone noticed problems with the interrupt context saving and restoring on the K42 ?
#1

10 Replies Related Threads

    MikaelNordman
    Starting Member
    • Total Posts : 33
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/02/16 01:36:36 (permalink)
    0
    The main program crashes even if I just have a periodic timer 2 interrupt which only clears the interrupt flag.
    It is the only active interrupt source at the time.

            banksel PIR4
            bcf PIR4, TMR2IF, BANKED
            retfie 1

     
    This code is for the vectored interrupts, which I started using, since the traditional interrupts made the code crash.
    The main program is using heavily all the registers that are saved and restored by the interrupt hardware.
    It seems some of those registers get trashed by the interrupt controller.
    I can only conclude that the K42 interrupt context saving does not work at all.
    #2
    davekw7x
    Entropy++
    • Total Posts : 1827
    • Reward points : 0
    • Joined: 2012/01/16 12:01:07
    • Location: Second star on the right, straight on till morning
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/02/16 10:16:06 (permalink)
    +2 (2)
    MikaelNordman
    I can only conclude that the K42 interrupt context saving does not work at all.



    I have used a PIC18F27K42 and a PIC18F25K42 in several projects, all with vectored interrupts, and have had no problems related to ISRs and context saving.
     
    [/Begin Disclaimer]
    My programs are in C, not Assembler.  ISRs are consistent with what you showed, all with the "retfie f" that is equivalent to your "retfie 1"
    [/End Disclaimer]
     
    My questions are:
    Where is your ISR for Timer 2 located?  Is its address divisible by 4?  Do you have its address, divided by 4, in the correct location in the vector table?
     
    For example, suppose the ISR is in location 0x125C0 and IVTBASE is set to its default value 0x8.  Then location 0x004C (For vector 34) should contain 0x4970.  My C .lst file shows  "dw  _TMR2_ISR shr (0+2)" at location 0x4C.
     
    If this doesn't help, maybe you can post a small complete project so that some of this forum's assembly language experts might help you get to the bottom of things.
     
     
    Regards,

    Dave
    post edited by davekw7x - 2019/02/16 11:12:13

    Sometimes I just can't help myself...
    #3
    MikaelNordman
    Starting Member
    • Total Posts : 33
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/09/07 03:12:29 (permalink)
    0
    I am happy to report that I have found the reason for the interrupt problems.
    There are 2 sequences in my code of "pop return".
    If I change those to "pop nop return" the interrupt context saving starts to work again.
     
    So apparently there is a silicon fault on the K42 and the K83 chips.
    The "pop return" sequence is breaking the interrupt context saving.
     
    The extra nop is not needed on the older PIC18 chips.
     
    Regards Mikael
    post edited by MikaelNordman - 2019/09/07 03:28:16
    #4
    MikaelNordman
    Starting Member
    • Total Posts : 33
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/09/07 07:34:14 (permalink)
    0
    That was not the whole truth.
    In order to operate the K42 and K83 PIC18s with interrupts, any pop instruction needs a following nop instruction.
    I quess this has not been a problem for C programmers. Probably the C compiler never emits any pop instructions.
    BR Mikael
    #5
    mbrowning
    USNA79
    • Total Posts : 1535
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/09/07 08:42:49 (permalink)
    0
    As this is a user forum and seldom to never visited by chip designers, I suggest you submit a support ticket on this so that it gets official notice.
     
    I know little of Forth, except that it's postfix and stack based which makes it clear why you need extensive stack manipulation and thus the push and pop instructions. I think even if reentrant mode is used in XC8, the software stack is purely for data not PC.
     
     

    Go Navy! Beat Army!
    #6
    MikaelNordman
    Starting Member
    • Total Posts : 33
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/09/07 08:53:20 (permalink)
    0
    I have a Microchip support ticket open in this issue since February 2019.
    I have asked them to investigate this problem, but no success.
     
    Maybe now I can get a confirmation from the chip designers, after figuring out the workaround myself.
     
    Forth is mixing data inline with code, and it requires some program counter juggling in order to read the data and jump to the instruction following the data.
    Another case is returning from a subroutine two levels up.
     
    #7
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3290
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/09/07 15:01:14 (permalink)
    0
    Forth is a bit old, replaced by better things Years ago.
    I think you are flogging a dead Horse on this.
     
    "Another case is returning from a subroutine two levels up."
    Maintain a separate stack, the PC stack is temporary, the Forth stack is not.
     
    Why do you need a Forth interpreter?  What is it's use?
     
     

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #8
    MikaelNordman
    Starting Member
    • Total Posts : 33
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/09/08 10:41:34 (permalink)
    0
    Gort2015
    Forth is a bit old, replaced by better things Years ago.
    I think you are flogging a dead Horse on this.

    Oh well. I happen to like this horse.
    I've done a lot of RTOS/C/C++/Java/Plex/ASM/XXX in my 35 year career.
     
    Gort2015
    "Another case is returning from a subroutine two levels up."
    Maintain a separate stack, the PC stack is temporary, the Forth stack is not.

    Forth has two stacks. One for data, one for return values.
    There are some double indirection cases where the return from a subroutine
    needs to skip one level and return two levels up.
    Also Forth uses the return stack for re-entrant temporary data storage.
     
    Gort2015
    Why do you need a Forth interpreter?  What is it's use?

    Having an interpreter and a compiler on board I can modify the program and memories
    from a command line. I can also control the I/O from the command line.
    I like that. Very practical for exploring the chip and the I/O hanging around it.
    With multitasking I can put the main loop in a background process and observe/change variables from the command process.
    Adapting Forth to a chip is a great way of learning the chip itself. And it's bugs.
    FlashForth can read/write flash, eeprom and ram memory in a unified 64 Kb memory space.
     
    #9
    Gort2015
    Klaatu Barada Nikto
    • Total Posts : 3290
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/09/08 14:09:51 (permalink)
    0
    The bugs are published in erata pdf files.
     
    My current project is a Regular Expression Engine library.

    MPLab X playing up, bug in your code? Nevermind, Star Trek:Discovery will be with us soon.
    https://www.youtube.com/watch?v=Iu1qa8N2ID0
    + ST:Continues, "What Ships are Made for", Q's back.
    #10
    MikaelNordman
    Starting Member
    • Total Posts : 33
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2019/09/14 04:28:36 (permalink)
    +1 (1)
    This particular bug is not yet in any errata document. It is a new one.
     
    If I use POP in my assembler program the interrupt context save does not work.
     
    One workaround is to follow the POP with a NOP.
     
    Another workaround is to use DECF STKPTR, F, A instead of POP.
    That also works.
     
    So clearly this is a bug in the POP instruction and interrupt context saving.
     
    This applies for the 18FxxK42 and 18FxxK83 chips, regardless of clock speed.
    post edited by MikaelNordman - 2019/09/14 04:47:30
    #11
    Jump to:
    © 2019 APG vNext Commercial Version 4.5