)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"0e18af1cdbda3cf6f923ab7024645d944ca3794f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"85b70104_0b2e48e1","updated":"2022-09-30 07:43:24.000000000","message":"Antonio,\nthis change affects all targets so we should be very careful deciding if it should go to 0.12.\n\nIt prevents very funny behaviour observed on hla target but generally it can happen on any target.\n\nST-Link, STM32F413 with zephyr blinky app, the first connect after power on:\nDebug AP is found but the target examination fails as CPU is sleeping and DBGMCU_CR has not been set.\n reset halt\n\nhl_assert_reset() works regardless not examined state - CPU is halted after reset.\nocd_process_reset_inner continues with \"pass 1 - wait for any halt\" and calls arp_waitstate halted.\narp_waitstate calls target_poll() which unfortunately fails because the target is not examined!!\n\nMy colophone: I would strongly prefer to remove dust from the reset framework and finally use it over non-systematic patching the old code here and there.","commit_id":"3eeb5a433d7cbef112186cb5dc4a6dbdfff02336"},{"author":{"_account_id":1002049,"name":"Erwan Gouriou","email":"erwan.gouriou@st.com","username":"erwango"},"change_message_id":"12b915f90ce95163e46fc082706b46f00c043cc2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e6545872_4ecb4481","updated":"2022-09-29 13:45:04.000000000","message":"Tested, in a single branch, this fix with related fixes:\n6745: target/cortex_m: make reset robust again | https://review.openocd.org/c/openocd/+/6745\n7228: target/cortex_m: try to re-examine under reset in cortex_m_assert_reset() | https://review.openocd.org/c/openocd/+/7228\n7229: target/hla_target: try to re-examine under reset in hl_assert_reset() | https://review.openocd.org/c/openocd/+/7229\n7230: target: re-examine before arp_waitstate in ocd_process_reset_inner | https://review.openocd.org/c/openocd/+/7230\n\nI confirm this works on most STM32 boards I\u0027ve been able to test (stm32f3_disco, nucleo_f429zi, nucleo_wl55jc, disco_l475_iot1, nucleo_l073rz, nucleo_f030r8) w/o reverting \"target: reset target examined flag if target::examine() fails\".\nI\u0027m able to flash and debug without changing existing board configurations.\n\nOnly board where this patch series is not successful is nucleo_f103rb. For this board, https://github.com/zephyrproject-rtos/zephyr/pull/50806 is still required.","commit_id":"3eeb5a433d7cbef112186cb5dc4a6dbdfff02336"},{"author":{"_account_id":1000687,"name":"Tomas Vanek","display_name":"Tomas Vanek","email":"vanekt@fbl.cz","username":"vanekt"},"change_message_id":"51f243c7167431c84fd45f18ab28adbf72ac9d92","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8183802c_3a082ec6","in_reply_to":"e6545872_4ecb4481","updated":"2022-09-30 07:07:38.000000000","message":"Welcome and thanks for testing!\nI think that closer cooperation between OpenOCD and zephyr will be beneficial for both projects.\n\nJust to be sure the nucleo_f103rb issue doesn\u0027t mean another bug in OpenOCD, could you please capture a debug log of failing session with stm32f103?\n\n openocd -d -l my.log ...\n\nI\u0027m not sure if west can pass these parameters. If it cannot, insert\n debug_level 3\n log_output my.log\n\nat the beginning of openocd.cfg\n\nUpload the log to a pastebin like service.","commit_id":"3eeb5a433d7cbef112186cb5dc4a6dbdfff02336"}]}