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.
