[ABANDONED] Strange JTrace behavior - Identified core does not match configuration. (Found: Cortex-M0, Configured: Cortex-M4)

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

  • [ABANDONED] Strange JTrace behavior - Identified core does not match configuration. (Found: Cortex-M0, Configured: Cortex-M4)

    This misidentification of CPU - Identified core does not match configuration. (Found: Cortex-M0, Configured: Cortex-M4) - started happening recently to me, after I've been using the device with JTrace for about half a year. It seems random, it seems to appear when device is powered on for a while.

    However the same device works fine with STLink.

    Device: STM32F427VI

    Once the misidentification happens, the device cannot be debugged or flashed via JTrace, Ozone won't work. Power cycling JTrace and device does not seem to change anything, but it will still be debuggable with STLink.

    Output from the JLink commander when it happens:

    Source Code

    1. % JLinkGDBServerCLExe -select USB -device STM32F427VI -endian little -if SWD -speed 2000 -ir -LocalhostOnly
    2. SEGGER J-Link GDB Server V6.62b Command Line Version
    3. JLinkARM.dll V6.62b (DLL compiled Feb 17 2020 18:42:57)
    4. Command line: -select USB -device STM32F427VI -endian little -if SWD -speed 2000 -ir -LocalhostOnly
    5. -----GDB Server start settings-----
    6. GDBInit file: none
    7. GDB Server Listening port: 2331
    8. SWO raw output listening port: 2332
    9. Terminal I/O port: 2333
    10. Accept remote connection: localhost only
    11. Generate logfile: off
    12. Verify download: off
    13. Init regs on start: on
    14. Silent mode: off
    15. Single run mode: off
    16. Target connection timeout: 0 ms
    17. ------J-Link related settings------
    18. J-Link Host interface: USB
    19. J-Link script: none
    20. J-Link settings file: none
    21. ------Target related settings------
    22. Target device: STM32F427VI
    23. Target interface: SWD
    24. Target interface speed: 2000kHz
    25. Target endian: little
    26. Connecting to J-Link...
    27. J-Link is connected.
    28. Firmware: J-Trace PRO V2 Cortex-M compiled Jan 7 2020 16:54:03
    29. Hardware: V2.00
    30. S/N: 752001121
    31. Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
    32. Checking target voltage...
    33. Target voltage: 3.31 V
    34. Listening on TCP/IP port 2331
    35. Connecting to target...
    36. WARNING: Identified core does not match configuration. (Found: Cortex-M0, Configured: Cortex-M4)
    37. WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1.
    38. Connected to target
    39. Waiting for GDB connection...
    40. WARNING: Target connection lost. Resetting server.
    41. ERROR: Failed to open remote socket. GDBServer will be closed.
    42. Restoring target state and closing J-Link connection...
    43. Shutting down...
    44. Remote connection failed.
    Display All


    This is the output from a while before when it worked fine:



    Source Code

    1. % JLinkGDBServerCLExe -select USB -device STM32F427VI -endian little -if SWD -speed 2000 -ir -LocalhostOnly
    2. SEGGER J-Link GDB Server V6.62b Command Line Version
    3. JLinkARM.dll V6.62b (DLL compiled Feb 17 2020 18:42:57)
    4. Command line: -select USB -device STM32F427VI -endian little -if SWD -speed 2000 -ir -LocalhostOnly
    5. -----GDB Server start settings-----
    6. GDBInit file: none
    7. GDB Server Listening port: 2331
    8. SWO raw output listening port: 2332
    9. Terminal I/O port: 2333
    10. Accept remote connection: localhost only
    11. Generate logfile: off
    12. Verify download: off
    13. Init regs on start: on
    14. Silent mode: off
    15. Single run mode: off
    16. Target connection timeout: 0 ms
    17. ------J-Link related settings------
    18. J-Link Host interface: USB
    19. J-Link script: none
    20. J-Link settings file: none
    21. ------Target related settings------
    22. Target device: STM32F427VI
    23. Target interface: SWD
    24. Target interface speed: 2000kHz
    25. Target endian: little
    26. Connecting to J-Link...
    27. J-Link is connected.
    28. Firmware: J-Trace PRO V2 Cortex-M compiled Jan 7 2020 16:54:03
    29. Hardware: V2.00
    30. S/N: 752001121
    31. Feature(s): RDI, FlashBP, FlashDL, JFlash, GDB
    32. Checking target voltage...
    33. Target voltage: 3.31 V
    34. Listening on TCP/IP port 2331
    35. Connecting to target...
    36. Connected to target
    37. Waiting for GDB connection...Connected to 127.0.0.1
    38. Reading all registers
    39. Read 4 bytes @ address 0x00000000 (Data = 0x10010000)
    40. Read 2 bytes @ address 0x00000000 (Data = 0x0000)
    41. Read 4 bytes @ address 0x00000000 (Data = 0x10010000)
    42. Read 4 bytes @ address 0x00000000 (Data = 0x10010000)
    43. Reading 64 bytes @ address 0x00000000
    44. Reading register (MSP = 0x 0)
    45. Reading register (PSP = 0x 0)
    46. Reading register (PRIMASK = 0x 0)
    47. Reading register (BASEPRI = 0x 0)
    48. Reading register (FAULTMASK = 0x 0)
    49. Reading register (CONTROL = 0x 0)
    50. Reading register (FPSCR = 0x6765723C)
    51. Starting target CPU...
    52. Reading all registers
    53. Read 4 bytes @ address 0x00000000 (Data = 0x10010000)
    54. Read 2 bytes @ address 0x00000000 (Data = 0x0000)
    55. Read 4 bytes @ address 0x00000000 (Data = 0x10010000)
    56. Read 4 bytes @ address 0x00000000 (Data = 0x10010000)
    57. Reading register (MSP = 0x 0)
    58. Reading register (PSP = 0x 0)
    59. Reading register (PRIMASK = 0x 0)
    60. Reading register (BASEPRI = 0x 0)
    61. Reading register (FAULTMASK = 0x 0)
    62. Reading register (CONTROL = 0x 0)
    63. Reading register (FPSCR = 0x6765723C)
    64. Starting target CPU...
    65. Debugger requested to halt target...
    66. ...Target halted (PC = 0x08032530)
    67. [...]
    Display All


    This show the device works fine when debugged via STLink+openocd:


    Source Code

    1. % ~/local/openocd-git/bin/openocd -f interface/stlink-v2.cfg -f target/stm32f4x.cfg
    2. Open On-Chip Debugger 0.10.0+dev-00957-g9de7d9c (2019-11-16-23:13)
    3. Licensed under GNU GPL v2
    4. For bug reports, read
    5. http://openocd.org/doc/doxygen/bugs.html
    6. WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg
    7. Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
    8. Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
    9. Info : Listening on port 6666 for tcl connections
    10. Info : Listening on port 4444 for telnet connections
    11. Info : clock speed 2000 kHz
    12. Info : STLINK V2J36S7 (API v2) VID:PID 0483:3748
    13. Info : Target voltage: 3.227261
    14. Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
    15. Info : Listening on port 3333 for gdb connections
    16. Info : accepting 'gdb' connection on tcp/3333
    17. target halted due to debug-request, current mode: Thread
    18. xPSR: 0x01000000 pc: 0x0802c94a msp: 0x1000fc88
    19. Info : device id = 0x20016419
    20. Info : flash size = 2048 kbytes
    21. Info : Dual Bank 2048 kiB STM32F42x/43x/469/479 found
    22. Info : flash size = 512 bytes
    23. Info : halted: PC: 0x0802c94c
    24. Info : halted: PC: 0x0802c94e
    25. Info : halted: PC: 0x0802c950
    26. Info : dropped 'gdb' connection
    Display All
  • After some experimenting is seems that JTrace does not like if target CPU is powercycled. That's when the weird behavior starts.

    Letting the CPU run for a whole day and resetting via JLink commander does not trigger this behavior.
  • Hi,
    Thank you for your inquiry.
    Such an issue is not known to us.
    A lot of people are using the J-Link/J-Trace in combination with STM32F4 devices, and we have not yet received any reports regarding this.

    Could you please update the J-Link Software you are using and try again?
    segger.com/downloads/jlink#J-L…twareAndDocumentationPack

    If the issue still persists after the update:
    1) Could you please send us a J-Link log file? How to enable:
    wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File
    2) Are you working on an evaluation board or on custom hardware?
    If evaluation board: Which one?
    If custom hardware: Does the issue also appear on an evaluation board?

    Best regards,
    Fabian
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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.
  • I've tried 3 of my devices - github.com/trezor/trezor-firmw…s/hardware/model-t/assets (there is schematics as well) and they randomly exhibit this behavior.

    Just 6 months ago I didn't have this issue.

    Also tried dev boards (STM32F407 and STM32F429 disco), the 429 version also hiccups ocassionally with thing like "WARNING: T-bit of XPSR is 0 but should be 1. Changed to 1."

    Tried the old drivers, JLinkARM.dll V6.62b and also new drivers, JLinkARM.dll V6.82f. The newer drivers don't complain about Cortex-M0/M4 mismatch, but debugging is not possible with them either - once connected via gdb I can see the instructions pointer is at wrong places.

    At the moment, one of my Trezor boards right now work correctly, but it's often hit and miss (and powercycling the device seems to make these issues appear, so for now I reset via JLink commander)

    I updated some weeks ago to Ozone v30.2c which uses newer JLink libraries than the command line ones (however I checked in process' maps that they do not cross - old utilities use old libs, new Ozone uses new libs). Though I remember all this started once I upgraded Ozone from I think 3.10. Could be a coincidence though.
  • Hi,
    Just to make sure that I understand you correctly:
    The issue does not appear on the eval boards "STM32F407 and STM32F429 disco", but only on your custom hardware?
    When power-cycling the device I assume you end the debug session beforehand and start a new debug session afterwards?

    As already requested:
    Could you please send us a J-Link log file? How to enable:
    wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File

    Best regards,
    Fabian
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    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.