• AVR Freaks

Hot!Program memory is not blank

Author
quijote
Starting Member
  • Total Posts : 89
  • Reward points : 0
  • Joined: 2005/01/27 04:06:37
  • Location: Spain
  • Status: offline
2019/04/03 08:17:08 (permalink)
0

Program memory is not blank

Hi
 
I am experiencing an error when trying to program a PIC32-based custom board, which I was previously able to program no problem. The app writes to NVM extensively and runs on a copy of the WiFi-G demo board.
 
What I know so far:-
 
a) I can program another (identical) board with the same combination of {IDE, compiler, software build, ICD3 + cable + adaptor, etc}. I can also program the original WiFi-G Demo board fine.
 
b) On the faulty board I am seeing a stable 3.3V on the ICSP power pin; I attach the ICSP circuit showing no caps on the PGC / PGD lines and 10k pull-up on the MCLR power line
 
c)  The fact that the (i) target voltage is detected (see below) and (ii) the device ID is found, leads me to think the ICSP circuit is fine but the PIC is faulty.
 
MPLAB-X output:
*****************************************************
Connecting to MPLAB ICD 3...
Currently loaded firmware on ICD 3
Firmware Suite Version.....01.51.12
Firmware type..............PIC32MX
Target voltage detected
Target device PIC32MX695F512H found.
Device ID Revision = A5
Device Erased...
Programming...
The following memory area(s) will be programmed:
program memory: start address = 0x1d000000, end address = 0x1d0627ff
boot config memory
configuration memory
Program memory is not blank.
Failed to program device
 
What I have tried so far:-
A) Checked all connections from ICSP connector to PIC32 (all correct).
B) No need to self-test the ICD3 since it programs another (identical) board fine.
C) Tried filling Flash memory with 0xff constant values throughout the whole program memory range to see if the program memory has become corrupted on the PIC (no difference).
D) Tried manually setting the ICD3 Program Memory Range (no difference).
 
E) My last resort is to replace the PIC but I am afraid the heat damage may destroy the IC pads so I want to investigate all other options first.
 
Any other ideas I should try ?
 
Quijote

Attached Image(s)

#1

17 Replies Related Threads

    Jim Nickerson
    User 452
    • Total Posts : 6186
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: online
    Re: Program memory is not blank 2019/04/03 08:48:56 (permalink)
    0
    Maybe you could try erasing the Pic using IPE.
    #2
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/04 01:04:58 (permalink)
    0
    Thanks for your reply, Jim
     
    Unfortunately, I get the same error in IPE.
     
    *****************************************************
    Connecting to MPLAB ICD 3...
    Currently loaded firmware on ICD 3
    Firmware Suite Version.....01.51.12
    Firmware type..............PIC32MX
    Target voltage detected
    Target device PIC32MX695F512H found.
    Device ID Revision = A5
    Erasing...
    Erase successful
    Blank Checking...
    Blank check complete, device is blank.
    2019-04-04 09:53:00 +0200 - Programming...
    Device Erased...
    Programming...
    The following memory area(s) will be programmed:
    program memory: start address = 0x1d000000, end address = 0x1d0627ff
    boot config memory
    configuration memory
    Program memory is not blank.
    Failed to program device
    Verifying...
    The following memory areas(s) will be verified:
    program memory: start address = 0x1d000000, end address = 0x1d07ffff
    boot config memory
    configuration memory
    program memory
    Address: 1d002e0c Expected Value: 3c20200a Received Value: 3c20204a
    configuration memory
    Address: 1fc02ff0 Expected Value: 70000 Received Value: c3070000
    Verify failed
     
    Could the PIC program or config memory be corrupted?
     
     
    Any ideas really welcome right now.
     
    Quijote
    #3
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/04 01:45:00 (permalink)
    0
    Looking through the memory map file, I cannot locate those two addresses in program and config memory with (supposedly) corrupted values, even after translating them from 0x10... to 0x90...
     
    Why would I not be able to find these memory locations in the .map file?
    #4
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/04 02:27:33 (permalink)
    0
    Furthermore, running the same IPE sequence of {Erase, Blank Check, Program, Verify} produces the exact same error, every time:
     
    program memory
    Address: 1d002e0c Expected Value: 3c20200a Received Value: 3c20204a
    configuration memory
    Address: 1fc02ff0 Expected Value: 70000 Received Value: c3070000
    Verify failed
     
    And yet this same code, same ICD and same cables program another identical custom board, as well as the WiFi G Demo board without problem.
     
    Hope this is helping someone else out there...
    #5
    rodims
    Super Member
    • Total Posts : 1515
    • Reward points : 0
    • Joined: 2009/02/10 11:08:59
    • Location: 51.9627, 7.6262
    • Status: online
    Re: Program memory is not blank 2019/04/04 02:35:00 (permalink)
    5 (1)
    The app writes to NVM extensively and runs on a copy of the WiFi-G demo board

    This means you are using the program memory flash for saving some data ?
    Check the erase/write cycle endurance for your PIC32MX695F512H  in the datasheet.
     
    I cannot find it myself without extensive search, but just assume that it might be e.g. 10.000 or even 100.000.
    From your description I would assume a physical damage of these two locations.
     
    In the first place I would not worry about this prototype, but use the other (still working) one to determine, how often you write to the NVM.  Due to a bug or improper design, or exceptional condition, you might write too frequently into your NVM memory.
    Have a look at your code first, but to be sure I would then do some measures with the real application.
     
    [edit: of course it might help to know, whether these two memory locations are somewhat part of your write area]
     
     
    post edited by rodims - 2019/04/04 02:37:32
    #6
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/04 02:53:29 (permalink)
    0
    Thanks for your feedback. 
     
    To answer your question: yes, I am saving and restoring data to Flash but only when values change (up to an absolute maximum of once per second, but never more). Having said that, the PIC Datasheet states no maximum Flash endurance, only a minimum of 1000.
     
    I attach the relevant table showing the PIC32 Flash endurance:-
     

    Attached Image(s)

    #7
    crosland
    Super Member
    • Total Posts : 1603
    • Reward points : 0
    • Joined: 2005/05/10 10:55:05
    • Location: Bucks, UK
    • Status: offline
    Re: Program memory is not blank 2019/04/04 03:03:27 (permalink)
    4 (1)
    You will never see a maximum endurance, only a guaranteed minimum. Different devices will behave differently.
     
    You WILL destroy the chip saving at once per second. An endurance of 1000 cycles gives you less than 17 minutes guaranteed runtime.
     
    Have you really thought your application through?
     
    At the very least you should be using multiple locations to spread the wear (e.g. see Microchip app note for EEPROM emulation in FLASH). Even then, you are going to struggle with such a high potential update rate.
    #8
    rodims
    Super Member
    • Total Posts : 1515
    • Reward points : 0
    • Joined: 2009/02/10 11:08:59
    • Location: 51.9627, 7.6262
    • Status: online
    Re: Program memory is not blank 2019/04/04 03:12:48 (permalink)
    4 (1)
    The DS60001156J-page 363  looks a bit different, possibly you have an older version.
    However the parameter D130 (cell endurance) is pretty small ( 1000 ).
    They cannot do more than specifying a minimum. It does not mean a cell will fail after 1000 erase cycles, its just the number which they grant to work.  It may be statistically different for any device or cell.  You should interprete it as maximum for your application, while it IS defined as minimum. 
    You can only calculate with your worst conditions. Obviously 1000 seconds would be reached soon.
     
    If that is the source of your problem, you need to think about wear levelling, or a different method to save your data.
    E.g. only save it, when system is shut down, but that's another story. Or external hardware
     
    Remember, it's only my idea that this is the reason for your problem. Checking the memory addresses might give more indication. If you design a real product, you certainly should invest enough time to verify that flash endurance is NOT the cause of your problem.
     
     
    #9
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/04 03:28:05 (permalink)
    0
    Thanks to all for your input, that really helps.
     
    In my naivety, I misinterpreted the minimum as meaning minimum. I should have known better.
     
    Most of the data is only saved when it changes (e.g. user config settings, maybe once per month) but some data maintains the state of the app in Flash over time, at a max of once per second (again only if it changes). Worst cae would be NVM write operation every second.
     
    It does look like the program memory is corrupted, so frequent NVM writes could be one cause but it is difficult to pinpoint without knowing in the .map file exactly what those memory locations correspond to.
     
    I will assume that could be the root cause and rethink how to make better use of Flash with a few simple tweaks to avoid so many writes.
     
    Thanks again!
    #10
    Mysil
    Super Member
    • Total Posts : 3330
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: offline
    Re: Program memory is not blank 2019/04/04 04:07:50 (permalink)
    0
    Hi,
    Worn-out Flash memory?
    The app writes to NVM extensively ... 

    According to datasheet for PIC32MX5xx, 6xx and 7xx devices:
    Flash memory Endurance is 1000 E/W cycles,
    see datasheet section 32, table 32-11, parameter D130
     
    Also check Power supply and decoupling, on the chip, during programming, see datasheet parameter D132.
     
    If program do NVM writing in addresses programmed in software, but not allocated by linker, then addresses will not show up in mapfile.
    Also note, that if a large array is allocated by linker, then mapfile will not show every address, only start address and length.
     
    I do not know about the verification failure in Boot Flash Configuration memory.
    The failing address  0x1FC02FF0  is  DEVCFG3 register that store the USERID value.
    Do the program repeatedly try t write to the register holding the  USERID field ?
    If a certain value have already been written to the flash memory location, then there is no point in repeatedly writing the same value.
    Since Configuration memory cannot be Erased, without crashing the program,
    if USERID field already have value 0x0000, then there is no point trying to write there.
     
    I suggest you investigate the NVM writing code in the application, and study 'wear leveling'.
     
        Mysil
    #11
    NorthGuy
    Super Member
    • Total Posts : 5578
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: online
    Re: Program memory is not blank 2019/04/04 06:52:14 (permalink)
    0
    You may consider an external EEPROM, which usually have 1000000 cycles endurance, or a PIC with internal EEPROM.
    #12
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/05 02:16:13 (permalink)
    0
    Thanks to all for your suggestions.
     
    Good idea to consider external / internal EEPROM. 
     
    Will also investigate 'Wear Levelling' in Flash devices.
     
    I have now replaced the PIC and the board now works fine but realise that my NVM strategy needs a serious rethink.
    #13
    rodims
    Super Member
    • Total Posts : 1515
    • Reward points : 0
    • Joined: 2009/02/10 11:08:59
    • Location: 51.9627, 7.6262
    • Status: online
    Re: Program memory is not blank 2019/04/05 02:37:13 (permalink)
    0
    In category "external memory":
    It will be overkill for your application, but maybe worth to mention: FRAM memory
    https://www.mikroe.com/click/storage   provides a board to use with Microchip Explorer board(s).
    post edited by rodims - 2019/04/05 02:55:08
    #14
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/05 06:43:27 (permalink)
    0
    Good to know, but I will stick with tried-and-tested Flash / EEPROM until the FRAM thermal instability issue has been fixed in future revisions. Thanks for the heads-up, though !
    #15
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/21 03:42:33 (permalink)
    0
    Without having to change the hardware (only Flash, no EEPROM), I was reviewing alternative NVM strategies.
     
    Q. Does it makes sense to save application state to Flash when a system exception has been triggered?
     
    This would allow me to minimise Flash erase/write cycles to only when most needed (i.e. when the app has suffered a system-wide reset).
     
    Any thoughts out there on this approach? I know it sounds a little crazy...
    #16
    Mysil
    Super Member
    • Total Posts : 3330
    • Reward points : 0
    • Joined: 2012/07/01 04:19:50
    • Location: Norway
    • Status: offline
    Re: Program memory is not blank 2019/04/21 06:04:12 (permalink)
    0
    Hi,
    Q. Does it makes sense to save application state to Flash when a system exception has been triggered?

    NO!
    When an exception have been triggered, then something Wrong have happened,
    and you cannot assume anything about what will work, or what will not work.
     
    So you will have to analyze the reason for the exception before doing anything else.
    If code is not available to resolve the exception,
    and determine that the program is still in a safe state,
    then the only safe action is to Reset the MCU.
    Anything else may cause a corrupt record, or may even destroy good data.
     
    Writing to NVM require sufficient time to complete the write operation,
    so depend on power supply and Capacitors in power supply.
    It will be better to use ADC or Analog Comparators to monitor Battery voltage,
    or power supply voltage before eventual regulator, to detect power failure or shutdown,
    before exception or failure reach the MCU. 
     
    It is possible to arrange power failure to trigger a interrupt,
    even as a NMI aka. Non-Maskable power failure Interrupt Exception, on some devices.
    Then it is a deliberate response to a planned contingency,
    and may perform NVM writing as part of that procedure.
     
        Mysil
     
    #17
    quijote
    Starting Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2005/01/27 04:06:37
    • Location: Spain
    • Status: offline
    Re: Program memory is not blank 2019/04/21 06:20:08 (permalink)
    0
    Thanks for the detailed explanation!
     
    Your comments confirm my initial thoughts (i.e. it WAS a crazy idea). :)
    #18
    Jump to:
    © 2019 APG vNext Commercial Version 4.5