• AVR Freaks

Hot!PIC18F26K42 A1 silicon and interrupts

Page: 12 > Showing page 1 of 2
Author
MikaelNordman
Starting Member
  • Total Posts : 48
  • 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

24 Replies Related Threads

    MikaelNordman
    Starting Member
    • Total Posts : 48
    • 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 : 1880
    • 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 : 48
    • 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 : 48
    • 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 : 1775
    • 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.
     
     
    #6
    MikaelNordman
    Starting Member
    • Total Posts : 48
    • 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 : 3956
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: online
    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 : 48
    • 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 : 3956
    • Reward points : 0
    • Joined: 2015/04/30 10:49:57
    • Location: 0
    • Status: online
    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 : 48
    • 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
    MikaelNordman
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/12 01:38:50 (permalink)
    +2 (2)
    I actually found the root cause of the problem.
     
    If an interrupt occurs simultaneously with a POP instruction, the following instruction after the POP is not executed.
    Probably the following pipelined instruction is discarded.
     
    This problem exists only in the new PIC18 K42 and and K83 cores. There is no such problem with older PIC18 cores.
    DECF STKPTR does not have this problem, even on K42 and K83.
     
    Microchip support refuses to accept this as a silicon bug because the datasheet states that interrupts must be disabled when implementing a software stack by accessing TOSx registers.
    But that is not exactly the same as using the POP instruction.
     
    Anyway, I gave up arguing with microchip support, it was like trying to run in a swamp.
     
    post edited by MikaelNordman - 2020/02/12 23:49:13
    #12
    jack@kksound
    code tags!
    • Total Posts : 3227
    • Reward points : 0
    • Joined: 2014/05/14 10:03:19
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/12 17:13:17 (permalink)
    +1 (1)
    Mikael: I have used your FlashForth in a number of projects over the last few years and really appreciate the effort you have put into it. I have always liked the simplicity and completeness of the Forth language and find your adaptation to the PIC processor line very creative. I have found that many people who bad mouth the language have never really tried to understand it (it is a bit "different"). Some of my projects added SD Card operations and similar complex functions, all written in Forth. Keep up the great work!
    #13
    MikaelNordman
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/12 23:43:26 (permalink)
    0
    @jack. Thanks Jack, appreciate it !
    #14
    1and0
    Access is Denied
    • Total Posts : 10913
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/13 03:39:22 (permalink)
    0
    MikaelNordman
    I actually found the root cause of the problem.
     
    If an interrupt occurs simultaneously with a POP instruction, the following instruction after the POP is not executed.
    Probably the following pipelined instruction is discarded.
     
    ...
     
    Microchip support refuses to accept this as a silicon bug because the datasheet states that interrupts must be disabled when implementing a software stack by accessing TOSx registers. 
    But that is not exactly the same as using the POP instruction.

    I haven't given this much thought yet, but accessing (popping) the hardware stack without disabling the global interrupt enable bits can result in stack corruption.
    #15
    MikaelNordman
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/13 04:05:25 (permalink)
    0
    1and0
    I haven't given this much thought yet, but accessing (popping) the hardware stack without disabling the global interrupt enable bits can result in stack corruption.

    Why would it happen ? It has never happened for me during 16 years of PIC18 usage with heavy use of PUSH and POP.
     
    Here is the test program that actually proves that the K42,K83 problem has to do with skipping the instruction after the POP instruction.

     
    ;The program prints 'I' when the RESET routine is executed.
    ;In the main loop the program prints 1 or 2 to the UART
    ;So the output in the working case is I22222222222222...
    ;The output in the not working case is I1111111111111...
    ;Working case uses DECF STKPTR, F on label WORKS
    ;The not working cases uses POP on label CRASHES
    ;There you can see that ADDLW is not executed,
    ; presumably because an interrupt has occured
    ; at the same time as the POP.
    ;T2PR=8 has a timing that causes the problem

    #include p18f26k42.inc
            constant clock=d'64000000'  ; Hz

    ;;; Specify RS-232 the baud rate for UART1 (TX1, RX1)
            constant baud=d'9600'
    ;;; Calculate the baud rate control value
            constant spbrgval   = ((clock/baud)/d'16') - 1
            constant spbrgvalx4 = ((clock/baud)/d'4') - 1

            ;CONFIG  FEXTOSC = XT ; OFF         
            CONFIG  RSTOSC = HFINTOSC_64MHZ
            CONFIG  CLKOUTEN = OFF        
            CONFIG  PR1WAY = OFF          
            CONFIG  CSWEN = OFF            
            CONFIG  FCMEN = OFF           
            ;CONFIG  MCLRE = EXTMCLR       
            CONFIG  PWRTS = PWRT_64       
            CONFIG  MVECEN = OFF
            CONFIG  IVT1WAY = OFF         
            CONFIG  LPBOREN = OFF         
            CONFIG  BOREN = OFF          
            CONFIG  BORV = VBOR_2P45      
            CONFIG  ZCD = OFF             
            CONFIG  PPS1WAY = OFF         
            CONFIG  STVREN = ON           
            CONFIG  DEBUG = OFF           
            CONFIG  XINST = OFF           
            CONFIG  WDTCPS = WDTCPS_31    
            CONFIG  WDTE = OFF           
            CONFIG  WDTCWS = WDTCWS_7     
            CONFIG  WDTCCS = SC           
            CONFIG  BBSIZE = BBSIZE_512   
            CONFIG  BBEN = OFF            
            CONFIG  SAFEN = OFF           
            CONFIG  WRTAPP = OFF          
            CONFIG  WRTB = OFF            
            CONFIG  WRTC = OFF            
            CONFIG  WRTD = OFF            
            CONFIG  WRTSAF = OFF          
            CONFIG  LVP = OFF              
            CONFIG  CP = OFF              

    ;;; Define UART pins for PPS
    ; Choose UART TX pin
    #define TX_TRIS  TRISC
    #define TX_ANSEL ANSELC
    #define TX_BIT   6
    #define TX_PPS   RC6PPS
    #define TX_LAT   LATC

    ; Choose UART RX pin
    #define RX_TRIS  TRISC
    #define RX_ANSEL ANSELC
    #define RX_BIT   7
    #define RX_PPS   b'00010111' ; from datasheet

    start code 0x0000
            goto main
    int_hi code 0x0008
            banksel PIR4
            btfsc   PIR4, TMR2IF, BANKED
            bcf     PIR4, TMR2IF, BANKED
            retfie 1


    pushpop:
            movlw '1'
            call print
            return

    print:
            banksel PIR3
            btfss   PIR3, U1TXIF, BANKED
            bra     print
            banksel U1TXB

            push
            nop
    ;*******************************************************************************
    WORKS:
            ;decf    STKPTR, F          ; THIS WORKS
    CRASHES:
            pop                       ; POP DOES NOT WORK
            ;nop                       ; EXCEPT TOGETHER WITH NOP
    ;*******************************************************************************
            addlw   1              ; The instruction following the POP is not excuted
                                   ; in case an an interrupt occurs during the POP
            movwf   U1TXB, BANKED  ;
            return
    ;*******************************************************************************


    init:
            nop
            movlw   h'3f'           ; Clearing the flags in PCON0
            movwf   PCON0
            movlw   h'01'
            movwf   T2CLK
    ;*******************************************************************************
            movlw   8    ; THE VALUE 8 HAS A TIMING THAT SHOWS THE PROBLEM WITH POP
            movwf   T2PR
    ;*******************************************************************************
            movlw   h'80'       ; Prescale = 1, Postscale = 1
            movwf   T2CON
            banksel PIE4
            bsf     PIE4, TMR2IE, BANKED

    ; PPS configure pins for RX and TX
            banksel RX_ANSEL
            bcf     RX_ANSEL, RX_BIT, BANKED    ; disable analogue on PORTx so RX can function
            bcf     TX_ANSEL, TX_BIT, BANKED    ; disable analogue on PORTx so TX can function
            bcf     TX_TRIS, TX_BIT
            bsf     TX_LAT, TX_BIT
    ; Unlock the PPS
            banksel PPSLOCK         ; required sequence
            movlw   h'55'
            movwf   PPSLOCK, BANKED
            movlw   h'AA'
            movwf   PPSLOCK, BANKED
            bcf     PPSLOCK, PPSLOCKED, BANKED  ; disable the pps lock
    ; Set the pins
            movlw   RX_PPS
            movwf   U1RXPPS, BANKED
            
            movlw   b'00000000'
            movwf   U1CTSPPS, BANKED
            
            movlw   b'00010011'     ; TX1
            movwf   TX_PPS, BANKED

    ; Re-lock the PPS
            movlw   h'55'
            movwf   PPSLOCK, BANKED
            movlw   h'AA'
            movwf   PPSLOCK, BANKED
            bsf     PPSLOCK, PPSLOCKED, BANKED  ; enable the pps lock

    ; Set the Baud Rate
            movlw   low(spbrgvalx4)        ; ((clock/baud)/d'4') - 1
            banksel U1BRGL
            movwf   U1BRGL, BANKED
            movlw   high(spbrgvalx4)
            movwf   U1BRGH, BANKED

    ; TX enable
            movlw   b'10110000'     ; HIGH SPEED BAUD RATE / NO AUTO DETECT BOARD /
                                    ; ENABLE TX / ENABLE RX / ASYNC 8 BIT MODE
            movwf   U1CON0, BANKED
            bsf     U1CON2, RUNOVF, BANKED
            bsf     U1CON1, ON_U1CON1, BANKED   ; turn on TX

    ; RX enable
            banksel PIE3
            bsf     PIE3, U1RXIE, BANKED    ; enable RX interupt
            bsf     RX_TRIS, RX_BIT         ; configure XY as an input
     
            movlw 'I'
            call print
     
            bsf     INTCON0, GIE

            return

    main:
            call init
    loop:
            call pushpop
            
            goto loop
            END
     

    post edited by MikaelNordman - 2020/02/13 04:07:40
    #16
    1and0
    Access is Denied
    • Total Posts : 10913
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/13 04:19:37 (permalink)
    +1 (1)
    MikaelNordman
    Why would it happen ? It has never happened for me during 16 years of PIC18 usage with heavy use of PUSH and POP.

    You were lucky? ;)
     
     
    I will look at your code later when I have time, but in the meantime how about trying this and see:
    ;*******************************************************************************
    WORKS:
            ;decf    STKPTR, F          ; THIS WORKS
    CRASHES:
            bcf     INTCON0,GIE
            pop                       ; POP DOES NOT WORK
            ;nop                       ; EXCEPT TOGETHER WITH NOP
    ;*******************************************************************************
            addlw   1              ; The instruction following the POP is not excuted
                                   ; in case an an interrupt occurs during the POP
            bsf     INTCON0,GIE
            movwf   U1TXB, BANKED  ;
            return
    ;*******************************************************************************

    post edited by 1and0 - 2020/02/13 04:22:29
    #17
    MikaelNordman
    Starting Member
    • Total Posts : 48
    • Reward points : 0
    • Joined: 2008/01/27 04:18:59
    • Location: 0
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/13 06:46:17 (permalink)
    0
    Dear 1and0,
    Of course the problem goes away if the interrupts are disabled :-)
    The point is that the POP instruction has a problem on K42,K83 but not on any other PIC18 cores.
     
    #18
    1and0
    Access is Denied
    • Total Posts : 10913
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/13 07:36:01 (permalink)
    +1 (1)
    MikaelNordman
    Of course the problem goes away if the interrupts are disabled :-)
    The point is that the POP instruction has a problem on K42,K83 but not on any other PIC18 cores.

    Quoted from the PIC18F2520 series datasheet http://ww1.microchip.com/downloads/en/DeviceDoc/39631E.pdf

    5.1.2.1 Top-of-Stack Access

    Only the top of the return address stack (TOS) is readable and writable. A set of three registers, TOSU:TOSH:TOSL, hold the contents of the stack location pointed to by the STKPTR register (Figure 5-2). This allows users to implement a software stack if necessary. After a CALL, RCALL or interrupt, the software can read the pushed value by reading the TOSU:TOSH:TOSL registers. These values can be placed on a user-defined software stack. At return time, the software can return these values to TOSU:TOSH:TOSL and do a return.

    The user must disable the global interrupt enable bits while accessing the stack to prevent inadvertent stack corruption.

    #19
    1and0
    Access is Denied
    • Total Posts : 10913
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: PIC18F26K42 A1 silicon and interrupts 2020/02/13 07:39:09 (permalink)
    +2 (2)
    ... and from the same section of the PIC18F45K42 series datasheet:

    The user must disable the Global Interrupt Enable (GIE) bits while accessing the stack to prevent inadvertent stack corruption.

    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2020 APG vNext Commercial Version 4.5