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. > > >
