• AVR Freaks

Hot!Possible PIC16LF18346 Silicon Bug

Author
iisnsr
New Member
  • Total Posts : 9
  • Reward points : 0
  • Joined: 2019/07/23 07:24:40
  • Location: 0
  • Status: offline
2019/10/24 06:17:11 (permalink)
0

Possible PIC16LF18346 Silicon Bug

I've been tracking down a bug over the past few days that has been somewhat elusive to say the least. I think I may have tracked it between a bulletin in an errata document and page 16 of the user manual. In developing my I2C assembly routine, I had used some of the pins to indicate when certain states were being called, including the entry to the ISR. One of the pins I'm using to do this is pin RC5, which according to the user manual has data functionality for MSSP2; yet I have configured this functionality to pin RB5, however.
 
The errata states that for MSSP2 (albeit silicon revision A1), that "when using the MSSP2 to perform I2C communication and the voltage for VDD is above 3.0 volts, the Acknowledge signal (ACK) does not always occur after the second address byte is received, as expected....." I've experienced this but from the perspective that MSSP2 had for some reason found upon itself generating two start conditions rather than specifically returning a NACK. Bizarrely, the start state function is in fact triggered and executed twice! Suspiciously, this occurs every 6.5 seconds or (2**16) / 10 milli-seconds; I am using Timer6 for 5ms ticks only. Now the interesting part is that if I stop bit-banging pin RC5 to provide the periodic updates showing as and when the flow reaches certain points (commenting out the Pin5On and Pin5Off macros), then I get error-free communication; I have used some other pins with error-free communications also. I can confirm that I am using a PIC16LF18346 powered at 3.3V but version 3 of the silicon as suggested by the following IDs received from the programmer:
Device ID: 0x30A7
Revision ID: 0x2003
 
I will seek to bring the voltage down to under 3V at some point soon, but is this behaviour related to the errata or perhaps something else? Unfortunately, I am unable to try MSSP1 at this time.
 
Attached is the output of the I2C channel (pins RB7, RB5) and debug pin RC5
 
Editing and fighting forbidden posts!
post edited by iisnsr - 2019/10/24 06:33:11

Attached Image(s)

#1

5 Replies Related Threads

    iisnsr
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2019/07/23 07:24:40
    • Location: 0
    • Status: offline
    Re: Possible PIC16LF18346 Silicon Bug 2019/10/24 06:39:37 (permalink)
    0
    Code relating to OP - sorry, using the code button renders post forbidden and unable to edit the OP any further!
     
    Pin5On macro
    banksel LATC
    bsf LATC, RC5
    endm
     
    Pin5Off macro
    banksel LATC
    bcf LATC, RC5
    endm
     
    ; MSSP channel definitions
    .
    .
    #define I2CCLKPPS SSP2CLKPPS
    #define RBSCLPPS RB7PPS
    #define TRISSCL TRISB7
    #define RBSCL RB7
    SCLPPS equ 00001111b
    SCLRB equ 0x1A
    #define I2CSDAPPS SSP2DATPPS
    #define RBSDAPPS RB5PPS
    #define TRISSDA TRISB5 ; 5
    #define RBSDA RB5 ; 5
    SDAPPS equ 00001101b
    SDARB equ 0x1B
    .
    .
     
    ; GPIO Config
    .
    .
    banksel PORTB
    clrf PORTB
    banksel LATB
    clrf LATB
    banksel TRISB
    movlw 0xF0 ; All input
    movwf TRISB
    banksel ANSELB
    clrf ANSELB
    banksel WPUB
    clrf WPUB
    banksel ODCONB
    clrf ODCONB
    .
    .
     
    ; MSSP Config
    .
    .
    banksel I2CCLKPPS
    movlw SCLPPS
    movwf I2CCLKPPS ; SCL1 is RB6/7
    movlw SDAPPS
    movwf I2CSDAPPS ; SDA1 is RB4/5
    banksel RBSCLPPS
    movlw SCLRB
    movwf RBSCLPPS ; Configure RB6 with SCL1 using 0x13
    movlw SDARB
    movwf RBSDAPPS ; Configure RB4 with SDA1 using 0x14
    banksel TRISB
    bsf TRISB, TRISSDA ; Set TRISB bit 4 // RB4/5 SDA1
    bsf TRISB, TRISSCL ; Set TRISB bit 6 // RB6/7 SCL1
    .
    .
     
    I2CBegin ; Initial I2C state and send START
    .
    .

    Pin5On
    Pin5Off
    .
    .
    post edited by iisnsr - 2019/10/24 06:50:11
    #2
    ric
    Super Member
    • Total Posts : 24638
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: Possible PIC16LF18346 Silicon Bug 2019/10/24 12:34:50 (permalink)
    +1 (1)
    Just a  sanity check. You DO have the Watchdog timer disabled, or appropriately managed do you?
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #3
    iisnsr
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2019/07/23 07:24:40
    • Location: 0
    • Status: offline
    Re: Possible PIC16LF18346 Silicon Bug 2019/10/24 16:39:36 (permalink)
    0
    Thanks for your response and that is a very good question.
     
    In the configuration that I've been using, which I've believed to be a fairly generic configuration, the CONFIG2 contains _WDTE_SWDTEN that according to the manual states that "WDT is controlled by the SWDTEN bit in the WDTCON register" As such, the SWDTEN bit is either on or off in the WDTCON register to determine whether the WDT is turned on or off. I have not used the WDTCON register or configured anything (else) with respect to the watchdog and will have to wait until I can access the hardware later today in order to inspect the register to verify the state.
     
    However, upon looking at the documentation for the WDTCON register, it also configures the interval for the watchdog; the value 01011b for 1:65536 states an interval of 2s as the reset value, with other values being based on powers of two. Now the interval I'm witnessing is around 6.5 seconds, which I don't know if there is any other way that this can be raised. Furthermore, I have an initialisation function at startup that would execute upon a reset that would also reset counters that I am monitoring, yet the counter values remain untouched.
     
    I'll update again when I've investigated the state of the WDTCON register and replace _WDTE_SWDTEN in CONFIG2 with _WDTE_OFF. In the meantime though, how would would simply changing the state of a pin that has not directly been configured to operate as part of the I2C have such a consequence and what is the relevance of the RC5 port with respect to SDA2?
     
    Thanks again
    #4
    iisnsr
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2019/07/23 07:24:40
    • Location: 0
    • Status: offline
    Re: Possible PIC16LF18346 Silicon Bug 2019/10/25 03:00:31 (permalink)
    0
    Ok, I've replaced _WDTE_SWDTEN in CONFIG2 with _WDTE_OFF and I'm still experiencing the glitches every 6.5 seconds. I've included the config registers in case there's something else that may be causing problems:
     __CONFIG _CONFIG1, _FCMEN_OFF & _CSWEN_ON & _CLKOUTEN_OFF & _FEXTOSC_OFF & _RSTOSC_HFINT1
     __CONFIG _CONFIG2, _BOREN_OFF & _WDTE_OFF & _MCLRE_ON & _PWRTE_OFF & _LPBOREN_OFF & _STVREN_OFF & _DEBUG_ON
     __CONFIG _CONFIG3, _WRT_OFF & _LVP_OFF
     __CONFIG _CONFIG4, _CP_OFF & _CPD_OFF
    I've also attached an image to show the state for verification.
     
    I've done a slightly deeper debug plot showing the following debug points....
    START: indicates that state dealing with the START condition is executing
    Nxt START: is tied to the I2C_ISR_END to indicate that the next state is a START
    Nxt nSTART: is tied to the I2C_ISR_END to indicate that the next state is NOT a START
    GLITCH: indicates that an error has occurred.
     
    There is no other place in my code that signals a START condition on the bus other than this function, which is shown to be called twice on occasion, yet when this happens, execution doesn't get to the I2C_ISR_END function after the first START signal to store the next state prior to returning.
     
    This is the code - apologies that it's not in a code box but I'm experiencing a lot of forbidden messages when I've previously tried:
    ; Trace shows the following code has run twice in succession after about 6.5 seconds....
     Dbg4ON
     Dbg4OFF
     banksel I2CCON2
     bsf I2CCON2, SEN
    ; but the flow is not getting to the following instructions after the first start in a double start situation!
     movlb BNK_I2C
     movlw S_MST_SEND_ADDR
     goto I2C_ISR_END

    In the main ISR at address 0x0004, I clear the GIE bit to prevent further interrupts from occurring....just in case. Interrupts are re-enabled by setting the GIE bit right before the RETFIE instruction.
     
    edit: including the I2C_ISR_END function
    I2C_ISR_END
     movwf I2cMstState
     movf I2cMstState, F ; just in case for sanity
     btfsc STATUS, Z
     goto NXT_ZERO
    ; Next state still requires the bus
     Dbg6ON
     Dbg6OFF
     return
    NXT_ZERO
    ; Bus clear and next state is ready for another START
     Dbg5ON
     Dbg5OFF
     return
    post edited by iisnsr - 2019/10/25 07:04:24

    Attached Image(s)

    #5
    iisnsr
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2019/07/23 07:24:40
    • Location: 0
    • Status: offline
    Re: Possible PIC16LF18346 Silicon Bug 2019/11/12 01:21:01 (permalink)
    0
    Managed to sort the problem, which was a paging fault that coincidentally caused addressing areas that appeared similar to the described silicon bug in the A1 variants - phew!
     
    While I'm now apparently using version A3 silicon, is there a way to obtain what the differences are between A2 and A3, similar to the errata that was published describing the differences between A1 and A2? Knowing when A3 was released would also be of help.
    post edited by iisnsr - 2019/11/12 01:22:22
    #6
    Jump to:
    © 2019 APG vNext Commercial Version 4.5