)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"a06e67ff86665c47e411b70bb1791fe2eb1d2dfd","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"38a5d1be_dcc6fd40","updated":"2022-06-19 17:08:03.000000000","message":"I know nothing about esp32.\nWhat is the sequence here?\nAt reset the memory protection is disabled and the firmware can enable it? So you need a reset-halt before programming the flash?\nIf this is the case, adding \"reset halt\" in event gdb-attach will work for flashing, but it will also make impossible to connect to a running target and debug a running firmware.\nThis is a usual case for flashing, that will require reset halt (or even better \"reset init\" in case some initialization is specifically needed before flashing).\nThe reset is also required to guarantee that the flash controller is not left in a strange state by the firmware and to have a fixed clock setup.\nThe \"proc program\" in src/flash/startup.tcl already runs \"reset init\". It is used for\"manual\" programming.\nIDE should send through GDB \"monitor reset init\" before flashing.\n\nSaid that, I have nothing against the patch, just this concern on unusual forced reset inside gdb-attach.","commit_id":"01331e09b67e10b7530addd6996d1daed9aa8b17"},{"author":{"_account_id":1001964,"name":"Erhan Kurubas","display_name":"Erhan Kurubas","email":"erhan.kurubas@espressif.com","username":"erhankur"},"change_message_id":"725d263a797abdde772bb433c911fb3797519e22","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"dc395317_ec938b54","in_reply_to":"38a5d1be_dcc6fd40","updated":"2022-06-20 08:47:52.000000000","message":"Your understanding is correct. It is disabled after reset and can only be enabled by the 2nd stage bootloader under 2 conditions;\n1- There is a config variable controlled by the users. This must be enabled from the device menuconfig\n2- OpenOCD must be disconnected. \n\nTo address your point, if OpenOCD is connected during target reset, memory protection will be disabled and the user can debug running firmware. \n\nThis patch will cover some use cases e.g; \n1- target reset\n2- openocd connect\n3- gdb connect","commit_id":"01331e09b67e10b7530addd6996d1daed9aa8b17"},{"author":{"_account_id":1001964,"name":"Erhan Kurubas","display_name":"Erhan Kurubas","email":"erhan.kurubas@espressif.com","username":"erhankur"},"change_message_id":"5c5bdd09ad8a535c9238f4c45e396cf350d60e96","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f65b7330_ab3210e5","in_reply_to":"8bd63077_bd604758","updated":"2022-06-20 10:05:05.000000000","message":"But, not all debugging activities requires flasher interaction. In that case manual reset halt might be better option. Created an improvement task to cover your scenario in one of the future patches.","commit_id":"01331e09b67e10b7530addd6996d1daed9aa8b17"},{"author":{"_account_id":1001964,"name":"Erhan Kurubas","display_name":"Erhan Kurubas","email":"erhan.kurubas@espressif.com","username":"erhankur"},"change_message_id":"a068928a320054723610bcd86668a3c361b4e016","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"8bd63077_bd604758","in_reply_to":"d382e2ae_99164704","updated":"2022-06-20 09:37:13.000000000","message":"If this is the case, users can disable the memory protection from the config and re-run the firmware to investigate the unusual behaviors. We also have users who don\u0027t use IDE. So, there is only one way to get rid of the protection and we are automatizing it. I think it is acceptable. \nAlso we can disable stub flasher if 2 hw breakpoints are sufficient to debug the target. (xtensa supports only 2 hw bp) This is another way to disable mem-prot (indirectly) without reset-halt. ","commit_id":"01331e09b67e10b7530addd6996d1daed9aa8b17"},{"author":{"_account_id":1000021,"name":"Antonio Borneo","email":"borneo.antonio@gmail.com","username":"borneoa"},"change_message_id":"5b71cd146eddae10ad720baec494b1af0b586506","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"d382e2ae_99164704","in_reply_to":"dc395317_ec938b54","updated":"2022-06-20 09:04:51.000000000","message":"For me there is one use case that this patch makes impossible:\n- you run the board without openocd/gdb connected\n- the firmware crashes or miss-behaves\n- you start openocd and gdb to read current program counter, memory content to identify the bug.\nThis patch causes a reset when gdb attaches, the firmware reboots and you loose the information of previous crash.\nThat\u0027s why for me the \"reset halt\" should be sent by IDE only if it needs it, not enforced at gdb attach.","commit_id":"01331e09b67e10b7530addd6996d1daed9aa8b17"}]}