Hi, my trick with this is by keeping the board in reset just until I start the JTAG software. This might take few attempts, but I eventually get lucky with timing, and MCU stops before system boots.
> On Nov 22, 2016, at 7:41 AM, Tim Hutt <[email protected]> wrote: > > Well, it sort of avoids your question but when I had an nRF board that > ignored my recovery attempts this worked: > > https://devzone.nordicsemi.com/blogs/16/recover-the-nrf51-when-nrjprog-and-nrfgo-studio-co/ > > Although it looks like you can't even connect which seems bad. > > On 22 Nov 2016 15:18, "David G. Simmons" <[email protected]> wrote: > >> Is there a way to halt Mynewt OS? I seem to have gotten myself into a >> tight corner that I can't seem to get out of. Basically it appears that >> Mynewt is in a tight loop and will not respond to newt attempting to >> re-flash a new app. >> >> Loading app image into slot 1 >> Error: Downloading >> /Users/dsimmons/dev/myproj/bin/targets/myble/app/apps/bletiny/bletiny.img >> to 0x8000 >> GNU gdb (GNU Tools for ARM Embedded Processors) 7.8.0.20150604-cvs >> Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL >> version 3 or later <http://gnu.org/licenses/gpl.html> This is free >> software: you are free to change and redistribute it. There is NO WARRANTY, >> to the extent permitted by law. Type "show copying" and "show warranty" for >> details. This GDB was configured as "--host=x86_64-apple-darwin10 >> --target=arm-none-eabi". Type "show configuration" for configuration >> details. For bug reporting instructions, please see: < >> http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other >> documentation resources online at: <http://www.gnu.org/software/ >> gdb/documentation/>. For help, type "help". Type "apropos word" to search >> for commands related to "word". SEGGER J-Link GDB Server V5.12g Command >> Line Version JLinkARM.dll V5.12g (DLL compiled May 27 2016 16:55:08) >> -----GDB Server start settings----- GDBInit file: none GDB Server Listening >> port: 3333 SWO raw output listening port: 2332 Terminal I/O port: 2333 >> Accept remote connection: yes Generate logfile: off Verify download: off >> Init regs on start: off Silent mode: off Single run mode: on Target >> connection timeout: 0 ms ------J-Link related settings------ J-Link Host >> interface: USB J-Link script: none J-Link settings file: none ------Target >> related settings------ Target device: nRF52 Target interface: SWD Target >> interface speed: 4000kHz Target endian: little Connecting to J-Link... >> Connecting to J-Link failed. Connected correctly? GDBServer will be >> closed... Shutting down... Could not connect to J-Link. Please check power, >> connection and settings..gdb_cmds:2: Error in sourced command file: >> localhost:3333: Operation timed out. (gdb) Exception condition detected on >> fd 0 error detected on stdin >> >> Ok, so I'l try to wipe it all out and re-program from scratch: >> >> DSimmons-Pro:myproj dsimmons$ JLinkExe -device nRF52 -speed 4000 -if SWD >> SEGGER J-Link Commander V5.12g (Compiled May 27 2016 16:55:14) >> DLL version V5.12g, compiled May 27 2016 16:55:08 >> >> Connecting to J-Link via USB...FAILED: Can not connect to J-Link via USB. >> J-Link> >> >> That's bad, right? I do have a console connection: >> >> 98074: > mempools >> 31730:Mempools: >> 31730: msys_1 (blksize: 292, nblocks: 12, nfree: 11) >> 31732: ble_hci_ram_evt_hi_pool (blksize: 72, nblocks: 2, nfree: 2) >> 31734: ble_hci_ram_evt_lo_pool (blksize: 72, nblocks: 8, nfree: 8) >> 31736: g_ble_ll_hci_ev_pool (blksize: 16, nblocks: 16, nfree: 16) >> 31737: ble_hs_hci_ev_pool (blksize: 16, nblocks: 10, nfree: 10) >> 31739: ble_hs_conn_pool (blksize: 80, nblocks: 1, nfree: 1) >> 31741: ble_l2cap_chan_pool (blksize: 28, nblocks: 3, nfree: 3) >> 31742: ble_l2cap_sig_proc_pool (blksize: 20, nblocks: 1, nfree: 1) >> 31744: ble_att_svr_prep_entry_pool (blksize: 12, nblocks: 64, nfree: 64) >> 31746: ble_gap_update (blksize: 24, nblocks: 1, nfree: 1) >> 31747: ble_gattc_proc_pool (blksize: 56, nblocks: 4, nfree: 4) >> 31749: bletiny_svc_pool (blksize: 28, nblocks: 32, nfree: 32) >> 31751: bletiny_chr_pool (blksize: 32, nblocks: 64, nfree: 64) >> 31752: bletiny_dsc_pool (blksize: 24, nblocks: 64, nfree: 64) >> 31754: ble_att_svr_entry_pool (blksize: 32, nblocks: 33, nfree: 0) >> 31756: ble_gatts_clt_cfg_pool (blksize: 12, nblocks: 2, nfree: 1) >> 31757: > tasks >> Tasks: >> 32906: task pri tid runtime csw stksz stkuse lcheck >> ncheck flg >> 32908: idle 255 0 32908 33 64 34 0 >> 0 20 >> 32910: ble_ll 0 1 0 11 80 56 0 >> 0 20 >> 32912: bletiny 1 2 0 50 512 138 0 >> 0 20 >> 32914: > >> >> So I can talk to it, but no way to stop it. Powering off/on the board has >> zero effect. >> >> What might be a handy thing to have is a way to halt a task, or the entire >> OS, to convince it to listen to incoming re-flash requests. >> >> There is an os_init(), of course, and an os_start() and an os_started(), >> but an os_halt() and/or an os_suspend() might be handy things to have. >> >> Alternatively, we have os_task_count() and os_task_info_get_next() and >> os_task_init() but maybe an os_task_destroy() or os_task_stop() might be >> handy. >> >> Basically, a mechanism to stop a runaway mynewt and bring it back to >> sanity would be pretty handy. >> >> Thoughts? >> >> dg >> -- >> David G. Simmons >> (919) 534-5099 >> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • >> Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter < >> http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs> >> /** Message digitally signed for security and authenticity. >> * If you cannot read the PGP.sig attachment, please go to >> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!! >> * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/> >> **/ >> ♺ This email uses 100% recycled electrons. Don't blow it by printing! >> >> There are only 2 hard things in computer science: Cache invalidation, >> naming things, and off-by-one errors. >> >> >>
