• AVR Freaks

Hot!16F876 to 16F876A migration issue

Author
Daithi
New Member
  • Total Posts : 4
  • Reward points : 0
  • Joined: 2019/09/30 03:26:57
  • Location: 0
  • Status: offline
2019/12/11 01:42:46 (permalink)
0

16F876 to 16F876A migration issue

I have inherited the responsibility of migrating some old assembler code to the new chips. Due to a checksum change and program memory write to change the initial boot goto I needed to change the assembler to account for the fact the 16F876A can only write program memory in 4 word blocks. I have made this change in several pieces of code using the same assembler copied into each. This has worked on all but one of the programs. The failing program runs incorrectly on the A chip but the same hex file programmed into a non A version of the chip operates correctly. I have read the hex from both chips after the checksum calculation and both read identically. This leads me to believe there's some kind of minor electrical or timing issues only reflected on the A chip. I have check the migration document, the clock settings, the errata sheets and nothing I can find should cause this different behavior. I'm looking for suggestions of other things to check or that I may have missed?
#1

8 Replies Related Threads

    ric
    Super Member
    • Total Posts : 27966
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: 16F876 to 16F876A migration issue 2019/12/11 12:50:02 (permalink)
    0
    Sorry, can't help.
    We did a similar migration many years ago, but as our firmware didn't do any self programming, it didn't require any source changes and all went smoothly.

    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!
    #2
    Daithi
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2019/09/30 03:26:57
    • Location: 0
    • Status: offline
    Re: 16F876 to 16F876A migration issue 2019/12/16 02:33:05 (permalink)
    0
    I'm wondering if I've posted this to the wrong forum section and maybe I'd have been better off posting it to the 8 bit microcontollers section?
    #3
    ric
    Super Member
    • Total Posts : 27966
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: 16F876 to 16F876A migration issue 2019/12/16 02:46:15 (permalink)
    0
    Yes, that would have been the better forum to post in, but in reality most of the same people will have seen it here.
    I think you're simply not getting any more responses as no-one else has seen the same problem.
    (Also, most of the experienced people will have moved on from 16F87x(A) parts many, many years ago.)
     
    One thought that crossed my mind is, have you disabled LVP mode in your CONFIG settings?
    If it is enabled, and also if the RB3/PGM pin is floating, you could be getting random resets...
     
     
     

    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!
    #4
    Daithi
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2019/09/30 03:26:57
    • Location: 0
    • Status: offline
    Re: 16F876 to 16F876A migration issue 2019/12/16 03:12:13 (permalink)
    0
    I also did the migration years ago at another company and everything just worked. It has just worked on several other pieces of code which is what's so frustrating. I read about the LVP setting on another thread but LVP is off and RB3 isn't floating. Oh well I guess It'll have to be one bit oscilloscope debugging until I can pin down the instructions where the problem occurs.
    #5
    NKurzman
    A Guy on the Net
    • Total Posts : 18850
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: 16F876 to 16F876A migration issue 2019/12/16 08:06:21 (permalink)
    #6
    1and0
    Access is Denied
    • Total Posts : 10986
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: 16F876 to 16F876A migration issue 2019/12/16 08:41:25 (permalink)
    0
    Daithi
    This leads me to believe there's some kind of minor electrical or timing issues only reflected on the A chip. ... I'm looking for suggestions of other things to check or that I may have missed?

    You did not mention what kind of problem with the A chip. I suggest combing thru the code for possible read-modify-write issues.
     
    post edited by 1and0 - 2019/12/16 08:42:43
    #7
    du00000001
    Just Some Member
    • Total Posts : 3835
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: 16F876 to 16F876A migration issue 2019/12/16 09:14:31 (permalink)
    0
    The migration guide shows 2 (i.w. TWO) differences related to ICSP (aka "Flash Programming"):
    • "Write to Flash in 4-word blocks, instead of 1-word blocks."
    • "Programming specifications are different."
    The latter is followed by a footnote to dig up the details in the datasheet(s). Although I wouldn't expect the 876A to perform worse than the non-A, I'd thoroughly check the datasheet!
    (Might be your software is waiting for some flag that's already gone at the point in time you're expecting it on the 'A due to its faster erase/program cycle.)
     

    PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
    #8
    Daithi
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2019/09/30 03:26:57
    • Location: 0
    • Status: offline
    Re: 16F876 to 16F876A migration issue 2019/12/17 10:31:57 (permalink)
    0
    Ideally I'd chop the assembler down to example but it's 5700 lines long and I don't entirely understand how this system works yet. The change I've made to the program memory writes to account for the 4 dwords is only done on the first boot to create a checksum of the program memory and then change the initial start vector. The problem is operational after this stage when the device immediately recalls the control panel after a clear on the 16F876A chip but not on the 16F876. I know that information is meaningless here because you know less about the system than I do. I've just rechecked the comparators are off and the register isn't being written accidentally. I've rechecked the PIC16F87XA Rev. B6 Silicon Errata and we don't fall within conditions of program memory write failures  and I have read the chips back to check the writes are happening correctly. I'm just out of ideas. I've even tried putting some delays after changes to the port b pulls to make sure they've got extra time to operate. I'll add more information as I go through it.
    #9
    Jump to:
    © 2020 APG vNext Commercial Version 4.5