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.

    • 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.