[ABANDONED] J-Link fails with error E0790010...

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [ABANDONED] J-Link fails with error E0790010...

    Hi,

    We are using Segger J-Link to gebug our firmware on NXP LPC4078 microcontroller. IDE: VisualStudio 2015; VisualGDB 5.4 preview 3 build 2193 (latest at this moment).
    JLinkARM.dll V6.32d (DLL compiled May 25 2018 17:03:12)

    Sometimes gebugging process fails with error:

    Source Code

    1. Remote failure reply: E0790010BC790010010000001400000032340000C8E70010107A0010A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A59B780010B8790010C99002006691020000000021
    2. Remote failure reply: E0790010BC790010010000001400000032340000C8E70010107A0010A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A59B780010B8790010C99002006691020000000021
    3. Remote failure reply: E0790010BC790010010000001400000032340000C8E70010107A0010A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A59B780010B8790010C99002006691020000000021
    4. Remote failure reply: E0790010BC790010010000001400000032340000C8E70010107A0010A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A59B780010B8790010C99002006691020000000021
    5. Remote failure reply: E0790010BC790010010000001400000032340000C8E70010107A0010A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A59B780010B8790010C99002006691020000000021

    This error repeates infinitely, if we try to stop debugging, read registers, set breakpoints, etc (after any command to gdb server).

    We can't determine cause ot this bug, but usually it occurs when we set many breakpoints, when we debug firmware step-by-step, when we jump between breakpoints many times.

    In previous version of JLink driver (V6.12j) we got another kind of error - crashing of JLinkGDBServerCL.exe without any possibility of reading debugger logs.

    How can we determine cause of this bug? What means code in "remote failure reply"?
  • Hello,

    Thank you for your inquiry.
    Such an issue is not known to us.
    The error message does not come from J-Link software. So it comes most likely from Visual Studio.
    Which J-Link software version are you currently using?
    Is debugging working reliably when using Ozone? segger.com/products/development-tools/ozone-j-link-debugger/
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi,

    We got same error again. Records in VisualGDB log right before failure:

    Source Code

    1. ...
    2. -var-list-children --simple-values "var15" 15 18
    3. ^done,numchild="3",children=[child={name="var15.EditCheque",exp="EditCheque",numchild="4",type="uint16_t [4]"},child={name="var15.MEditCheque",exp="MEditCheque",numchild="4",type="TInt64 [4]"},child={name="var15.reserved",exp="reserved",numchild="12",type="uint8_t [12]"}],has_more="0"
    4. -var-list-children --simple-values "var15" 0 5
    5. ^done,numchild="5",children=[child={name="var15.Head",exp="Head",numchild="5",type="TStructHead"},child={name="var15.CurrentStatus",exp="CurrentStatus",numchild="0",value="38",type="uint32_t"},child={name="var15.DocStatus",exp="DocStatus",numchild="0",value="0",type="uint16_t"},child={name="var15.DocFlags",exp="DocFlags",numchild="0",value="0",type="uint16_t"},child={name="var15.ShiftNumber",exp="ShiftNumber",numchild="0",value="92",type="uint16_t"}],has_more="1"
    6. -var-evaluate-expression "var15\.Head"
    7. ^done,value="{...}"
    8. -stack-select-frame 0
    9. ^done
    10. -var-create - * "s_StackMinSizeTreshold"
    11. ^done,name="var16",numchild="0",value="64",type="uint16_t",has_more="0"
    12. ptype/mt uint16_t
    13. &"ptype/mt uint16_t\n"
    14. ~"type = unsigned short\n"
    15. ^done
    16. -stack-select-frame 0
    17. ^done
    18. 1001-interpreter-exec console flushregs
    19. ~"Register cache flushed.\n"
    20. 1001^done
    21. -exec-next
    22. ^running
    23. *running,thread-id="all"
    24. &"Remote failure reply: E67700106CA10400030000006FA1040002000000400000006CA10400A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5D877001003F603000EF6030000000001\n"
    Display All

    We can repeat this failure:

    C Source Code

    1. bool osCheckTaskStack(char * ThName)
    2. {
    3. char Buf[20];
    4. uint16_t Len;
    5. uint16_t Tmp = uxTaskGetStackHighWaterMark(NULL)* sizeof(StackType_t);
    6. if ((int)Tmp <= s_StackMinSizeTreshold) {
    7. memcpy(&Buf, &Tmp, 2);
    8. Len = strlen(ThName) + 1;
    9. memcpy(Buf + 2, ThName, Len);
    10. Len += sizeof(Tmp);
    11. if (s_StackMinSizeTreshold == configMINIMAL_STACK_SIZE / 2) {
    12. if (LOG_OUTDATA_CRITICAL(LOG_EVENT_STACK_INFO, (uint8_t*)Buf, Len)) {
    13. s_StackMinSizeTreshold = 0;
    14. }
    15. }
    16. else {
    17. if (LOG_OUTDATA_CRITICAL(LOG_EVENT_STACK_CRITICAL, (uint8_t*)Buf, Len)) {
    18. s_StackMinSizeTreshold = -1;
    19. }
    20. return false;
    21. }
    22. }
    23. return true;
    24. }
    Display All
    If we set breakpoint on line #9 (memcpy), and then do "Step over", we will get described failure.

    We reproduced this fault many times in different conditions, so we can provide more information.

    Our environment:
    • Visual Studio Community 2015 Version 14.0.25431.01 Update 3
    • VisualGDB Custom Edition version 5.4 (Preview 3, build 2193)
    • SEGGER J-Link GDB Server V6.32
    Debugging is working reliably when using Ozone. Ozone works fine, but we can't integrate Ozone into our developement processes.


    If we change source code (for example, in line #9: memcpy(Buf, ThName, Len);) and then recompile project, everything works fine. Fail will not reproduce.

    If we do not set breakpoint at line #9, everything works fine, firmware continues working. Debugger also works fine in such case.

    Even if debugger failed, firmware still working. We can attach to running firmware and debug it again (without reset MCU).


    VisualGDB support said that gdb is unable to parse some data from gdb server (the Segger gdb stub).
    So, we need your help to locate and fix this error.