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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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. > >>> > >>> > >>> > > > >
