Hot!Hard crash when trying to program User ID Memory

Author
RDS Cliff
New Member
  • Total Posts : 13
  • Reward points : 0
  • Joined: 2016/09/23 11:50:05
  • Location: 0
  • Status: offline
2017/09/13 19:52:42 (permalink)
3 (1)

Hard crash when trying to program User ID Memory

Was trying to characterize User ID Memory programming with the ICD 4.  Looks like it doesn't work at all.  Mailed in a separate bug report. Tried programming the User ID separately, then loading my C program in a separate step.  I left some IDLOC lines in the C program.  Loading threw up a program verify error, read one byte value, expecting something else in the User ID memory.  Minor, I thought I could still debug.  But when I tried to Launch Debugger, I got a total crash with the following messages:
 
Script GetPC failed with status Type = runScript, Script name = GetPC, Status = 0xa00
.
Reception on endpoint 129 failed (err = -10121)
A communication error with the debug tool has occurred. The tool will attempt to recover momentarily.
Unable to run the target device.
Script GetPC failed with status Type = runScript, Script name = GetPC, Status = 0xa00
.
The tool was disconnected while it was busy.
Reception on endpoint 129 failed (err = -121)
A communication error with the debug tool has occurred. The tool will attempt to recover momentarily.
Reception on endpoint 129 failed (err = -10995)
 
The Finish Debugger Session button did not work.  IDE locked up.  Had to close and unplug everything to get out.  Not good.  Hope Microchip can figure this one out.
 
MPLAB X v4.01
PIC18F66K22
XC 8 v1.40
 
#1

4 Replies Related Threads

    RISC
    Super Member
    • Total Posts : 4480
    • Reward points : 0
    • Status: offline
    Re: Hard crash when trying to program User ID Memory 2017/09/16 07:08:09 (permalink)
    3 (1)
    Hi,
    You should probably report this to the dedicated ICD4 mail address :
    http://www.microchip.com/forums/m1014644.aspx
    Regards
    #2
    RDS Cliff
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2016/09/23 11:50:05
    • Location: 0
    • Status: offline
    Re: Hard crash when trying to program User ID Memory 2017/09/23 15:13:36 (permalink)
    0
    Yep, already done (sort of).  I reported the User ID functions not working.  Was trying to find a work around when I ran into the crash.
    #3
    Jerry Messina
    Super Member
    • Total Posts : 223
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: Hard crash when trying to program User ID Memory 2017/09/24 04:47:54 (permalink)
    4.75 (4)
    Just fyi - I don't know about the ICD4, but you have to be careful trying to debug code that writes to IDLOC memory since that space is typically shared with the debugger memory.

    In the 18F66K22 the IDLOC are located from 0x200000 to 0x200007, and it has an erase block size of 64 bytes (0x40). The debugger uses 0x200028-0x200037 for it's bkbgvectmem settings (actual locations vary depending on the tool/device). Erasing the IDLOC bytes also erases bkbgvectmem, so the debugger will lose control and no longer function.

    Typically what I do for debugging IDLOC operations with those devices is:
    1) reserve a buffer the size of the erase block
    2) to modify the IDLOC copy the current bytes at 0x200000 to the buffer, reading a full erase block
        this will capture the current bkbgvectmem settings
    3) modify the buffer contents with the new IDLOC data, being careful not to modify anything outside
        the IDLOC space
    4) erase the block at 0x200000
    5) write the full buffer back to 0x200000
    6) wait for write complete

    You can't single step through this or set a breakpoint in between steps 2-6.

    It doesn't surprise me that MPLABX/ICD4 has a problem and completely wigs out. I'd expect nothing less these days.




    #4
    RDS Cliff
    New Member
    • Total Posts : 13
    • Reward points : 0
    • Joined: 2016/09/23 11:50:05
    • Location: 0
    • Status: offline
    Re: Hard crash when trying to program User ID Memory 2017/10/06 12:52:31 (permalink)
    3 (1)
    As a famous Vulcan would say, "Fascinating".
    Didn't know the debug registers were there. But that explains something new I discovered:  Up till recently, I was just building debug builds for use with the ICD4.  I recently built a normal build to run stand-alone.  Lo and behold, the ID locations were programmed!
    So the problem is the ICD4 not programming the ID locations for a debug build. Now that I know the debug vectors are in the same erase block, "wigging out" is not entirely a surprise.
     
    BTW, I was not trying to do any runtime programming of the ID locations.  I just wanted the debugger to put a serial number in there.  My code reads the number using some MCC supplied functions.
    #5
    Jump to:
    © 2017 APG vNext Commercial Version 4.5