From: Rob M. <Rob...@u-...> - 2024-04-23 16:33:57
|
Thanks for the swift response: verbose OpenOCD output attached. The odd thing is that this worked fine when OpenOCD was driven only by Zephyr's west tool, the failure mode has only begun happening when we use OpenOCD directly ourselves, no HW changes. Once the problem occurs Zephyr's west tool is equally unable to download to the board, so it seems like something is becoming "stuck" on the board itself. I've looked at OpenOCD versions and there are no functional changes in v0.12.0-3 so I think that the version we are using, v0.12.0-2, should be the latest, and it is also the same binary we used by Zephyr. The Zephyr world has its own per-board OpenOCD config file, of course, and the command-line used by Zephyr's west tool is a little more complex: openocd -s /home/rob/zephyr/boards/arm/nucleo_u575zi_q/support '-c set _ZEPHYR_BOARD_SERIAL 003E004C3532510F31333430' -f /home/rob/zephyr/boards/arm/nucleo_u575zi_q/support/openocd.cfg -c 'gdb_report_data_abort enable' '-c init' '-c targets' -c 'reset init' -c 'flash write_image erase /home/rob/stm32u5.hex' -c 'reset run' -c shutdown Rob From: Tommy Murphy <tom...@ho...> Sent: Tuesday, April 23, 2024 4:50 PM To: Rob Meades <Rob...@u-...>; ope...@li... Subject: Re: Anyone using STM32U5 with OpenOCD? **** This is an EXTERNAL email. It was sent from outside of u-blox. **** Sporadic connection/instability issues can often be caused by things like poor (or too long) wiring between the host PC/probe/target, unreliable power to the probe/target, clocking/timing issues etc. So these are all things that might be worth eliminating as relevant factors. Also - if you can capture and post a verbose (openocd -d3) log for a failure case it may help to identify problems. And if you're not already doing so you might want to build and use the very latest OpenOCD from the repo rather than using some older version from an OS software repository or other download source. |