You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by "David G. Simmons" <sa...@mac.com> on 2016/11/22 15:17:58 UTC
Halting Mynewt
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.
Re: Halting Mynewt
Posted by Kevin Townsend <ke...@adafruit.com>.
I generally put a factory reset pin in projects that I check very early
on, which has saved my butt more than once, though it isn't fool proof.
It's just nice to have an early stage option to go back to a known state
when devices are in the field or even during development (and you can
reformat the NFFS partition, etc., to kill any config settings).
Also ... if you have something like BOOT_SERIAL enabled in your
bootloader, this also always gives you a safe option to recover a device
since the bootloader should always be stable, and will execute before
your app. Just enter serial bootloader, and you should have JLink access
again.
On 22/11/16 18:18, David G. Simmons wrote:
> NRF52DK. I managed to get it reset. Timing is hard to get perfect. The 'Reset' button is ignored.
>
> I think this might point to the need for an os_suspend() or an os_stop() function.
>
> dg
>
>> On Nov 22, 2016, at 12:13 PM, marko kiiskila <ma...@runtime.io> wrote:
>>
>> Usually I have a button. But I have had to use jumper wires also :)
>> What board are you using?
> --
> David G. Simmons
> (919) 534-5099
> Web <https://davidgs.com/> \u2022 Blog <https://davidgs.com/davidgs_blog> \u2022 Linkedin <http://linkedin.com/in/davidgsimmons> \u2022 Twitter <http://twitter.com/TechEvangelist1> \u2022 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/>
> **/
> \u267a 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.
>
>
>
Re: Halting Mynewt
Posted by "David G. Simmons" <sa...@mac.com>.
NRF52DK. I managed to get it reset. Timing is hard to get perfect. The 'Reset' button is ignored.
I think this might point to the need for an os_suspend() or an os_stop() function.
dg
> On Nov 22, 2016, at 12:13 PM, marko kiiskila <ma...@runtime.io> wrote:
>
> Usually I have a button. But I have had to use jumper wires also :)
> What board are you using?
--
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.
Re: Halting Mynewt
Posted by marko kiiskila <ma...@runtime.io>.
Usually I have a button. But I have had to use jumper wires also :)
What board are you using?
> On Nov 22, 2016, at 9:07 AM, David G. Simmons <sa...@mac.com> wrote:
>
> How are you keeping the board in reset? The only method I've found is to power the board off, and so far, my timing has not paid off on that front.
>
> dg
>
>> On Nov 22, 2016, at 12:04 PM, marko kiiskila <ma...@runtime.io> wrote:
>>
>> 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.
>
> --
> 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.
>
>
Re: Halting Mynewt
Posted by Wayne Keenan <wa...@gmail.com>.
Another thing that helped was to reboot my dev box, play a bit of Cannon
Fodder and then resume development. USB, never been so much fun.
All the best
Wayne
On 22 November 2016 at 18:44, Vipul Rahane <vi...@runtime.io> wrote:
> I have had instances where openocd doesn’t disconnect and simple grep for
> opened and kill the process. It generally happens when I
> disconnect/poweroff the board while debugging. I am not sure whether that
> would be the case for you as it’s JLink.
>
> I think you should be able to find out using the following command after
> disconnecting the board:
>
> Vipuls-MacBook-Pro:apache-mynewt-core vipul$ ps -ef| grep JLink
> 501 39210 17249 0 10:35AM ttys000 0:00.01 grep JLink
> 501 39207 39206 0 10:35AM ttys003 0:00.25 JLinkGDBServer -device
> nRF52 -speed 4000 -if SWD -port 3333 -singlerun
>
> Regards,
> Vipul Rahane
>
> > On Nov 22, 2016, at 9:31 AM, Kevin Townsend <ke...@adafruit.com> wrote:
> >
> > The nRF51 also (strangely!) has a non standard SWD interface. It's the
> first time I've come across that, and I'm not sure what the thinking behind
> multiplexing RST with the SWD pins was (extremely low pin count devices?),
> but it breaks the normal behaviour of SWD on ARM Cortex M and you need to
> handle it as an edge case on the J-Link and other debuggers internally.
> Thankfully, the nRF52 doesn't have this same 'feature', and the peripherals
> are all around more pleasant to use. :)
> >
> >
> > On 22/11/16 18:23, Wayne Keenan wrote:
> >> Do you have any other devices connected to your nRF (electronically, not
> >> BLE) and are actively trying to send data to the nRF?
> >> If so, detach them and try again.
> >>
> >> In one repeatable case I've found it impossible to connect to an nRF51
> >> using SWD via the J-Link when another MCU was communicating using SPI to
> >> the nRF51.
> >> This happened even if the nRF was totally erased, the SPI chatter just
> got
> >> in the way of SWD working.
> >>
> >> ymmv
> >>
> >> All the best
> >> Wayne
> >>
> >> On 22 November 2016 at 17:07, David G. Simmons <sa...@mac.com>
> wrote:
> >>
> >>> How are you keeping the board in reset? The only method I've found is
> to
> >>> power the board off, and so far, my timing has not paid off on that
> front.
> >>>
> >>> dg
> >>>
> >>>> On Nov 22, 2016, at 12:04 PM, marko kiiskila <ma...@runtime.io>
> wrote:
> >>>>
> >>>> 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.
> >>> --
> >>> 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.
> >>>
> >>>
> >>>
> >
>
>
Re: Halting Mynewt
Posted by Vipul Rahane <vi...@runtime.io>.
I have had instances where openocd doesn’t disconnect and simple grep for opened and kill the process. It generally happens when I disconnect/poweroff the board while debugging. I am not sure whether that would be the case for you as it’s JLink.
I think you should be able to find out using the following command after disconnecting the board:
Vipuls-MacBook-Pro:apache-mynewt-core vipul$ ps -ef| grep JLink
501 39210 17249 0 10:35AM ttys000 0:00.01 grep JLink
501 39207 39206 0 10:35AM ttys003 0:00.25 JLinkGDBServer -device nRF52 -speed 4000 -if SWD -port 3333 -singlerun
Regards,
Vipul Rahane
> On Nov 22, 2016, at 9:31 AM, Kevin Townsend <ke...@adafruit.com> wrote:
>
> The nRF51 also (strangely!) has a non standard SWD interface. It's the first time I've come across that, and I'm not sure what the thinking behind multiplexing RST with the SWD pins was (extremely low pin count devices?), but it breaks the normal behaviour of SWD on ARM Cortex M and you need to handle it as an edge case on the J-Link and other debuggers internally. Thankfully, the nRF52 doesn't have this same 'feature', and the peripherals are all around more pleasant to use. :)
>
>
> On 22/11/16 18:23, Wayne Keenan wrote:
>> Do you have any other devices connected to your nRF (electronically, not
>> BLE) and are actively trying to send data to the nRF?
>> If so, detach them and try again.
>>
>> In one repeatable case I've found it impossible to connect to an nRF51
>> using SWD via the J-Link when another MCU was communicating using SPI to
>> the nRF51.
>> This happened even if the nRF was totally erased, the SPI chatter just got
>> in the way of SWD working.
>>
>> ymmv
>>
>> All the best
>> Wayne
>>
>> On 22 November 2016 at 17:07, David G. Simmons <sa...@mac.com> wrote:
>>
>>> How are you keeping the board in reset? The only method I've found is to
>>> power the board off, and so far, my timing has not paid off on that front.
>>>
>>> dg
>>>
>>>> On Nov 22, 2016, at 12:04 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>>
>>>> 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.
>>> --
>>> 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.
>>>
>>>
>>>
>
Re: Halting Mynewt
Posted by Kevin Townsend <ke...@adafruit.com>.
The nRF51 also (strangely!) has a non standard SWD interface. It's the
first time I've come across that, and I'm not sure what the thinking
behind multiplexing RST with the SWD pins was (extremely low pin count
devices?), but it breaks the normal behaviour of SWD on ARM Cortex M and
you need to handle it as an edge case on the J-Link and other debuggers
internally. Thankfully, the nRF52 doesn't have this same 'feature', and
the peripherals are all around more pleasant to use. :)
On 22/11/16 18:23, Wayne Keenan wrote:
> Do you have any other devices connected to your nRF (electronically, not
> BLE) and are actively trying to send data to the nRF?
> If so, detach them and try again.
>
> In one repeatable case I've found it impossible to connect to an nRF51
> using SWD via the J-Link when another MCU was communicating using SPI to
> the nRF51.
> This happened even if the nRF was totally erased, the SPI chatter just got
> in the way of SWD working.
>
> ymmv
>
> All the best
> Wayne
>
> On 22 November 2016 at 17:07, David G. Simmons <sa...@mac.com> wrote:
>
>> How are you keeping the board in reset? The only method I've found is to
>> power the board off, and so far, my timing has not paid off on that front.
>>
>> dg
>>
>>> On Nov 22, 2016, at 12:04 PM, marko kiiskila <ma...@runtime.io> wrote:
>>>
>>> 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.
>> --
>> David G. Simmons
>> (919) 534-5099
>> Web <https://davidgs.com/> \u2022 Blog <https://davidgs.com/davidgs_blog> \u2022
>> Linkedin <http://linkedin.com/in/davidgsimmons> \u2022 Twitter <
>> http://twitter.com/TechEvangelist1> \u2022 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/>
>> **/
>> \u267a 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.
>>
>>
>>
Re: Halting Mynewt
Posted by Wayne Keenan <wa...@gmail.com>.
Do you have any other devices connected to your nRF (electronically, not
BLE) and are actively trying to send data to the nRF?
If so, detach them and try again.
In one repeatable case I've found it impossible to connect to an nRF51
using SWD via the J-Link when another MCU was communicating using SPI to
the nRF51.
This happened even if the nRF was totally erased, the SPI chatter just got
in the way of SWD working.
ymmv
All the best
Wayne
On 22 November 2016 at 17:07, David G. Simmons <sa...@mac.com> wrote:
> How are you keeping the board in reset? The only method I've found is to
> power the board off, and so far, my timing has not paid off on that front.
>
> dg
>
> > On Nov 22, 2016, at 12:04 PM, marko kiiskila <ma...@runtime.io> wrote:
> >
> > 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.
>
> --
> 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.
>
>
>
Re: Halting Mynewt
Posted by "David G. Simmons" <sa...@mac.com>.
How are you keeping the board in reset? The only method I've found is to power the board off, and so far, my timing has not paid off on that front.
dg
> On Nov 22, 2016, at 12:04 PM, marko kiiskila <ma...@runtime.io> wrote:
>
> 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.
--
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.
Re: Halting Mynewt
Posted by marko kiiskila <ma...@runtime.io>.
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 <td...@gmail.com> 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" <sa...@mac.com> 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.
>>
>>
>>
Re: Halting Mynewt
Posted by Tim Hutt <td...@gmail.com>.
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" <sa...@mac.com> 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.
>
>
>