)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1001319,"name":"Liviu Ionescu","username":"ilg-ul"},"change_message_id":"6b34e549d266338cf9d66fe8bcd19cc5dba7009d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d7ed21a7_0d51afbe","updated":"2024-06-17 17:17:54.000000000","message":"\u003e Could you try your semihosting tests with this patch and a Cortex-M7 target?\n\nYes, but please allow me 1-2 days.","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"fdc0cc799303ca6f355cb84266f96958c92a48fc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"73974b3d_6f2fa570","updated":"2024-06-19 06:08:34.000000000","message":"Additional message explains what the workaround does on cortex_m target and tells there is no workaround on hla","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"e4b264298713858b48964fa7123337f21394b86a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"fe911b99_2b5a84d3","updated":"2024-06-18 12:21:59.000000000","message":"Here there was a small code from Tomas able to replicate the issue\nhttps://sourceforge.net/p/openocd/mailman/message/37870940/","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1001319,"name":"Liviu Ionescu","username":"ilg-ul"},"change_message_id":"f482eed771a5a02ec303b298d6355e01a73a8bd9","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"73366bc2_373cc50c","updated":"2024-06-18 21:20:48.000000000","message":"Hmmm... it seems the issue is not yet fixed:\n\n```\n1: Test command: /Users/ilg/MyProjects/micro-os-plus.github/micro-os-plus-iii/micro-os-plus-iii.git/tests/build/nucleo-f767zi-cmake-debug/xpacks/.bin/openocd \"-c\" \"gdb_port disabled\" \"-c\" \"tcl_port disabled\" \"-c\" \"telnet_port disabled\" \"-f\" \"interface/stlink.cfg\" \"-f\" \"target/stm32f7x.cfg\" \"-c\" \"program rtos-apis-test.elf verify\" \"-c\" \"arm semihosting enable\" \"-c\" \"arm semihosting_cmdline rtos-apis-test\" \"-c\" \"reset\"\n1: Working Directory: /Users/ilg/MyProjects/micro-os-plus.github/micro-os-plus-iii/micro-os-plus-iii.git/tests/build/nucleo-f767zi-cmake-debug/platform-bin\n1: Test timeout computed to be: 10000000\n1: xPack Open On-Chip Debugger 0.12.0+dev-01621-gd4607c225-dirty (2024-06-18-23:02)\n1: Licensed under GNU GPL v2\n1: For bug reports, read\n1: \thttp://openocd.org/doc/doxygen/bugs.html\n1: Info : auto-selecting first available session transport \"hla_swd\". To override use \u0027transport select \u003ctransport\u003e\u0027.\n1: Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD\n1: Info : clock speed 2000 kHz\n1: Info : STLINK V2J42M27 (API v2) VID:PID 0483:3752\n1: Info : Target voltage: 3.245850\n1: Info : [stm32f7x.cpu] Cortex-M7 r1p0 processor detected\n1: Warn : [stm32f7x.cpu] Erratum 3092511: Cortex-M7 can halt in an incorrect address when breakpoint and exception occurs simultaneously\n1: Info : [stm32f7x.cpu] target has 8 breakpoints, 4 watchpoints\n1: Info : [stm32f7x.cpu] Examination succeed\n1: Info : gdb port disabled\n1: Info : Unable to match requested speed 2000 kHz, using 1800 kHz\n1: Info : Unable to match requested speed 2000 kHz, using 1800 kHz\n1: [stm32f7x.cpu] halted due to debug-request, current mode: Thread \n1: xPSR: 0x01000000 pc: 0x080001f8 msp: 0x20080000\n1: Info : Unable to match requested speed 8000 kHz, using 4000 kHz\n1: Info : Unable to match requested speed 8000 kHz, using 4000 kHz\n1: ** Programming Started **\n1: Info : device id \u003d 0x10016451\n1: Info : flash size \u003d 2048 KiB\n1: Info : Single Bank 2048 kiB STM32F76x/77x found\n1: ** Programming Finished **\n1: ** Verify Started **\n1: ** Verified OK **\n1: semihosting is enabled\n1: semihosting command line is [rtos-apis-test]\n1: Info : Unable to match requested speed 2000 kHz, using 1800 kHz\n1: Info : Unable to match requested speed 2000 kHz, using 1800 kHz\n1: Info : tcl server disabled\n1: Info : telnet server disabled\n1: \n1: Hardware initialised\n1: Main stack 0x2007f400-0x20080000\n1: os_startup_initialize_free_store(0x20003818,506856)\n\n... (lots of tests)\n\n1: Test POSIX I/O - Block device locked - C++ API\n1: .lock() @0x20002d3c mx2 by 0x2007f378 main\n1: {C .internal_try_lock_() @0x20002d3c mx2 by 0x2007f378 main LCK\n1:  C}lock() @0x20002c98 mx1 by 0x2007f378 main\n1: .{C internal_try_lock_() @0x20002c98 mx1 by 0x2007f378 main LCK\n1:  C}.unlock() @0x20002c98 mx1 by 0x2007f378 main\n1: {C .internal_unlock_() @0x20002c98 mx1 ULCK\n1:  C}unlock() @0x20002d3c mx2 by 0x2007f378 main\n1: {C .internal_unlock_() @0x20002d3c mx2 ULCK\n1:  C}lock() @0x20002d3c mx2 by 0x2007f378 main\n1: {C .internal_try_lock_() @0x20002d3c mx2 by 0x2007f378 main LCK\n1:  C}.lock() @0x20002c98 mx1 by 0x2007f378 main\n1: {C .internal_try_lock_() @0x20002c98 mx1 by 0x2007f378 main LCK\n1:  C}unlock() @0x20002c98 mx1 by 0x2007f378 main\n1: {C .internal_unlock_() @0x20002c98 mx1 ULCK\n1:  C}unlock() @0x20002d3c mx2 by 0x2007f378 main\n1: {C .internal_unlock_() @0x20002d3c mx2 ULCK\n1:  C}lock() @0x20002d3c mx2 by 0x2007f378 main\n1: .{C internal_try_lock_() @0x20002d3c mx2 by 0x2007f378 main LCK\n1:  C}.lock() @0x20002c98 mx1 by 0x2007f378 main\n1: {C .internal_try_lock_() @0x20002c98 mx1 by 0x2007f378 main LCK\n1:  C}unlock() @0x20002c98 mx1 by 0x2007f378 main\n1: .{C internal_unlock_() @0x20002c98 mx1 ULCK\n1:  C}[stm32f7x.cpu] halted due to breakpoint, current mode: Handler SysTick\n1: xPSR: 0x210f000f pc: 0x0800067e msp: 0x20080000, semihosting\n\n```\n\nI used the latest commit and cherry picked the patch. The erratum is acknowledged by the initialisation code.\n\nHowever the execution still halts at the SysTick handler (the only interrupt enabled).\n\nTesting is extremely tedious, somehow the conditions changed since last year, and the issue is much harder to reproduce, I had to enable most tracing messages to increase the chance of a breakpoint and interrupt collision, and even so lots of tests pass (and take lots of time)...","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1001319,"name":"Liviu Ionescu","username":"ilg-ul"},"change_message_id":"89907a18f89f85846ceb7f3bada1d2b898424ca8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d52ee00d_7752e592","updated":"2024-06-17 15:24:23.000000000","message":"I took a quick look, but I\u0027m pretty rusty on openOCD internals (and Cortex-M...), and I don\u0027t fully understand how the patch determines if the halt address is a hardware breakpoint. I expected a loop of comparisons of the current address with an array of registers where breakpoint addresses are stored by the debugger (I don\u0027t remember how those registers are called, sorry). \n\nCan you point me where this happens?","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1001319,"name":"Liviu Ionescu","username":"ilg-ul"},"change_message_id":"40d22fdd1d20cbcde22988be008e0c2272096825","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"6a38864e_e08b41fb","updated":"2024-06-18 08:42:14.000000000","message":"I\u0027m a bit embarrassed, I can no longer reproduce the issue on my Mac with the Nucleo-F767ZI or Nucleo-H745ZI boards. I left it in a loop, perhaps it\u0027ll hang after a while; it looks like the test conditions changed, previously the issue was reproducible at each run. I\u0027m using an openocd from January 2023. I\u0027ll try on a Raspberry Pi to, but again the conditions are different, now I have a RPi5, not the RPi4 used initially.\n\nIn the evening I\u0027ll try with the latest sources and the patch, but I\u0027m skeptic I\u0027ll see the message about the ignored break.","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"d1edeb054d27b62cf890d79627a530108d800f0e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ac1cd621_39ee9e52","updated":"2024-06-17 20:57:43.000000000","message":"It looks ok to me, but let\u0027s wait for the test from Liviu.","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"bf5a263a8b3bc9fa01a1e4bbad3c0acb1305320f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4c10100e_ba7060d5","updated":"2024-06-17 14:10:52.000000000","message":"Tested just shortly on STM32H7A3 (Cortex-M7 r1p1). Works as expected.","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1001319,"name":"Liviu Ionescu","username":"ilg-ul"},"change_message_id":"e6320bb0346c9d34057bad12a810aea91fc4b98b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7b5f5577_4fdd8d5a","in_reply_to":"42a04b6d_e6b8596f","updated":"2024-06-19 07:46:47.000000000","message":"After updating to `stlink-dap.cfg`, without other updates, I got the resuming message:\n\n```\n1: .{C internal_unlock_() @0x20002c98 mx1 ULCK\n1:  C}Info : [stm32f7x.cpu] Resuming after incorrect halt @ PC 0x0800067e, ARM Cortex-M7 erratum 3092511\n1: .unlock() @0x20002d3c mx2 by 0x2007f378 main\n```","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"6eaca8a91a85362c545b8cb126bd8ce4ad30d9d1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"713c45f9_3ddc5160","in_reply_to":"50e63966_62d8cf57","updated":"2024-07-01 08:54:23.000000000","message":"Ack","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"ded585f797f599a9858322ec4c686f2affc6632e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"82a7a4eb_46f26ba4","in_reply_to":"50e63966_62d8cf57","updated":"2024-06-24 05:44:22.000000000","message":"Ack","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"c13e5927be8620c767d46265f089c9108b6d2509","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8c461f04_3f54ce13","in_reply_to":"6a38864e_e08b41fb","updated":"2024-06-18 09:13:21.000000000","message":"I remember we tried masking interrupts as a counter-measure a year ago. Please check if the config does not set `cortex_m maskisr on`","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"62018ceda45b328bb45597151f5579204cedf642","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"42a04b6d_e6b8596f","in_reply_to":"73366bc2_373cc50c","updated":"2024-06-19 05:48:23.000000000","message":"No wonder. The fix works for cortex_m target, no for hla (ST-Link high level protocol)!! Unfortunately the CPU detection part is common, so the initial warning\nis issued.\n```\n1: Test command: ... \"-f\" \"interface/stlink.cfg\" ...\n1: Info : auto-selecting first available session transport \"hla_swd\"\n```\nIt might be possible to add another fix and resume even on hla target but please please stop using `interface/stlink.cfg` in favour of `interface/stlink-dap.cfg`\nIt makes lot of differences...\n\nAntonio, we should add a very visible deprecation message to the old hla stuff!\n\nBefore I noticed `hla` in the test config I made a semihosting/SysTick based test which tries to find the sweet spot of the interrupt timing. Works pretty effective in replicating the issue and so far all incorrect halts were resumed:\n```\n$ ~/openocd/build/src/openocd -s ~/openocd/tcl/ -f interface/cmsis-dap.cfg -f target/stm32h7x.cfg -c \u0027program stm32\nh7a3.elf verify;reset;arm semihosting enable\u0027\nOpen On-Chip Debugger 0.12.0+dev-00607-g1d04860b7897-dirty (2024-06-10-11:48)\nLicensed under GNU GPL v2\nFor bug reports, read\n        http://openocd.org/doc/doxygen/bugs.html\nInfo : auto-selecting first available session transport \"swd\". To override use \u0027transport select \u003ctransport\u003e\u0027.\nInfo : Using CMSIS-DAPv2 interface with VID:PID\u003d0x15a2:0x007f, serial\u003d\nInfo : CMSIS-DAP: SWD supported\nInfo : CMSIS-DAP: Atomic commands supported\nInfo : CMSIS-DAP: FW Version \u003d 2.0.0\nInfo : CMSIS-DAP: Interface Initialised (SWD)\nInfo : SWCLK/TCK \u003d 0 SWDIO/TMS \u003d 1 TDI \u003d 0 TDO \u003d 0 nTRST \u003d 0 nRESET \u003d 1\nInfo : CMSIS-DAP: Interface ready\nInfo : clock speed 1800 kHz\nInfo : SWD DPIDR 0x6ba02477\nInfo : [stm32h7x.ap2] Examination succeed\nInfo : [stm32h7x.cpu0] Cortex-M7 r1p1 processor detected\nWarn : [stm32h7x.cpu0] Erratum 3092511: Cortex-M7 can halt in an incorrect address when breakpoint and exception occurs simultaneously\nInfo : [stm32h7x.cpu0] target has 8 breakpoints, 4 watchpoints\nInfo : [stm32h7x.cpu0] Examination succeed\nInfo : gdb port disabled\nInfo : starting gdb server for stm32h7x.cpu0 on 3333\nInfo : Listening on port 3333 for gdb connections\n[stm32h7x.cpu0] halted due to breakpoint, current mode: Thread\nxPSR: 0x01000000 pc: 0x080034d0 msp: 0x20020000\n** Programming Started **\nInfo : Device: STM32H7Ax/7Bx\nInfo : flash size probed value 2048k\nInfo : STM32H7 flash has dual banks\nInfo : Bank (0) size is 1024 kb, base address is 0x08000000\nInfo : Padding image section 1 at 0x0800aefc with 4 bytes (bank write end alignment)\nWarn : Adding extra erase range, 0x0800af00 .. 0x0800bfff\n** Programming Finished **\n** Verify Started **\n** Verified OK **\nsemihosting is enabled\nInfo : Listening on port 6666 for tcl connections\nInfo : Listening on port 4444 for telnet connections\nloops per ms 603, after delay 171\n3354\nmaximum 3354\n3353\nminimum 3353\n3354\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3355\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3356\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3357\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3358\n3359\n3360\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3361\n3362\n3363\nmaximum 3363\n3362\n3361\n3360\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3359\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3358\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3357\n3356\n3355\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3354\n3353\nminimum 3353\n3354\n3355\n3356\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3357\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3358\n3359\n3360\n3361\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3362\n3363\nmaximum 3363\n3362\n3361\n3360\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3359\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3358\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3357\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n3356\n3355\n3354\nInfo : [stm32h7x.cpu0] Resuming after incorrect halt @ PC 0x08000d54, ARM Cortex-M7 erratum 3092511\n```","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"7f7b47318e9d0411d61d2139a94c99e810f84fa8","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"50e63966_62d8cf57","in_reply_to":"7b5f5577_4fdd8d5a","updated":"2024-06-19 10:42:14.000000000","message":"\u003e Antonio, we should add a very visible deprecation message to the old hla stuff!\n\nFor some time I have investigated for some automatic way to detect the STLink version before switching to HLA for older versions, but OpenOCD requires setting HLA before ``init``, so before the very first communication with the adapter. I have not found a clean solution.\nTime has passed, we can assume that old STLink adapters have been updated to a FW newer than V2J24 (issued mid 2015), or user moved to STLink V3.\nOpenOCD already issues a warning for older STLink not supporting dapdirect.\nI think we could proceed to:\n- deprecate HLA with STLink;\n- replace HLA to dapdirect in all the STM32 config files;\n- improve the warning for older STLink informing the user on how to go back to HLA, if mandatory to keep the old STLink FW.\n\nOn top, I will think over about replacing the transport names ``dapdirect_swd`` and ``dapdirect_jtag`` as simply ``swd`` and ``jtag``. I don\u0027t see a real reason for having such complication.\nThere are instead \u0027DAP direct\u0027 adapters that do not rely on a wire transport (JTAG or SWD), like ``rshim`` and ``dmem``. These could be renamed as ``dapdirect``.","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"88e3e94c2474314bb6d89605efee81b95c877b65","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"83b8a659_d29dd7fa","in_reply_to":"d52ee00d_7752e592","updated":"2024-06-17 17:15:26.000000000","message":"breakpoint_find() looks for any breakpoint set by OpenOCD (either hard one handled in FPB or soft one, an inserted BKPT instruction).\nThe second part of cortex_m_erratum_check_breakpoint() tests if a breakpoint embedded in code was hit. It should handle e.g. semihosting BKPTs.\n\nCould you try your semihosting tests with this patch and a Cortex-M7 target?","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"3b3c552e6919ccd8be002d36d867ebc7d13335d5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0609ae6c_ad024162","in_reply_to":"fe911b99_2b5a84d3","updated":"2024-06-18 14:24:33.000000000","message":"I used the code similar to this for testing (with both embedded BKPT and FPB breakpoint set by gdb, not yet tested with a soft breakpoint in RAM resident code). The code replicated the issue and the workaround correctly resumed.\n\nI\u0027m curious how the patch copes with breakpoints in semihosting code.","commit_id":"d778a8c22c673e83e713046c14a732700bd87766"},{"author":{"_account_id":1001319,"name":"Liviu Ionescu","username":"ilg-ul"},"change_message_id":"dceee64257cc6d4becae262005f094b54aab897f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"95bdbd0e_d8ae5ad5","updated":"2024-06-19 07:50:01.000000000","message":"A small question: is the text \"Cortex-M7 can halt in an incorrect address when breakpoint and exception occurs simultaneously\" grammatically correct?\n\nEventually add Tommy Murphy as reviewer, he is a native English speaker.","commit_id":"e1dda54e84a8d4ed22267f8a782bfb6028715b6b"},{"author":{"_account_id":1001319,"name":"Liviu Ionescu","username":"ilg-ul"},"change_message_id":"fb11cd2f8e2bee1784aea97de3b0409756b3862b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"0f9014a6_4154990c","updated":"2024-06-19 11:00:13.000000000","message":"I concur, please add a deprecation message and the explicit suggestion to use `stlink-dap.cfg`; in my case there was no such message (as you can see in the code block I posted above); even worse, the errata message was present, as if everything was ok.","commit_id":"e1dda54e84a8d4ed22267f8a782bfb6028715b6b"},{"author":{"_account_id":1001319,"name":"Liviu Ionescu","username":"ilg-ul"},"change_message_id":"65b44cea78d5078cc76006b36def1be4dc25457e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"5913e139_06b8af22","updated":"2024-06-19 10:50:16.000000000","message":"I did some more runs and had no problems, so I would say that the main issue of resuming rogue breakpoints was solved.\n\nIt is interesting to note that even with insanely high verbosity, there is only one moment when the bug occurs, and the code correctly resumes it. If I revert to reasonable verbosity, the bug no longer shows.\n\nThis makes me think how lucky we were to identify this bug; if I\u0027d be to start testing today, normally I\u0027d not enable full verbosity, and the bug would remain hidden.","commit_id":"e1dda54e84a8d4ed22267f8a782bfb6028715b6b"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"0829f7d16abefcabc78039592e59df209dfa6b86","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"7e14c35a_4f61907b","in_reply_to":"0f9014a6_4154990c","updated":"2024-06-19 11:50:21.000000000","message":"Liviu,\nthe message added by Tomas about not using HLA is correct. In fact it\u0027s not only STLink that uses HLA but also the adapters TI-ICDI and NULink.\nFor STLink only, I will proceed to deprecate HLA since a more modern alternative exists in a separate patch series.\nFor the other adapters, there is nothing we can do more.\nTo proceed with this patch, please consider adding back your +1","commit_id":"e1dda54e84a8d4ed22267f8a782bfb6028715b6b"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"6eaca8a91a85362c545b8cb126bd8ce4ad30d9d1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"3ac5c8a0_18a73e1f","in_reply_to":"7e14c35a_4f61907b","updated":"2024-07-01 08:54:23.000000000","message":"Ack","commit_id":"e1dda54e84a8d4ed22267f8a782bfb6028715b6b"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"ded585f797f599a9858322ec4c686f2affc6632e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"9ad55f61_f286c024","in_reply_to":"7e14c35a_4f61907b","updated":"2024-06-24 05:44:22.000000000","message":"Thanks for backing, Antonio.\nLiviu was right that the warning issued in patch set 1 after Cotrex-M version detection could suggest the erratum is worked around. On the other hand it\u0027s worth to warn even in the case we have no workaround, just to make clear that there is no OpenOCD error - that\u0027s why the patch set 2 is more verbose.\n\nAlso the automatic resume workaround may be way too slow if servicing the interrupt is time critical (e.g. in USB driver), so an info message is emitted each time the resume takes place.","commit_id":"e1dda54e84a8d4ed22267f8a782bfb6028715b6b"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"cdff03e77f2a1b410e952fc73b787e7c326db605","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"59ef1693_4fd7eb99","in_reply_to":"95bdbd0e_d8ae5ad5","updated":"2024-06-19 10:15:08.000000000","message":"Just note that the text is copy\u0026pasted the erratum description from ARM notice. I intentionally kept the original wording.","commit_id":"e1dda54e84a8d4ed22267f8a782bfb6028715b6b"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"6eaca8a91a85362c545b8cb126bd8ce4ad30d9d1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0dcbafbd_878aa5a1","updated":"2024-07-01 08:54:23.000000000","message":"Tomas,\nthere is a new clang build error after this merge.\nhttps://build.openocd.org/job/openocd-clang/1230/","commit_id":"23c33e1d3a332a94ef080451d43c6dc004e34750"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"4a7a62ad17ef0c9929624ca86ddfdc8c378a0fdb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"5e975865_72b9153b","in_reply_to":"0dcbafbd_878aa5a1","updated":"2024-07-13 17:33:02.000000000","message":"It\u0027s a false positive, but I\u0027m surprised scan-build did not triggered it before this patch!\nAnyway, fixed with https://review.openocd.org/c/openocd/+/8391","commit_id":"23c33e1d3a332a94ef080451d43c6dc004e34750"}]}