Since Blinky can be run on a variety of boards, like the STM32FDiscovery, while BLE can’t be run on that board, switching boards mid-stream on the tutorials is going to be a common thread, unless you only have the one board.
I’ll add some more to the ‘prerequisites’ section of the main Tutorials page to clarify a few things as well. dg > On Jun 27, 2016, at 5:21 PM, aditi hilbert <[email protected]> wrote: > > Indeed the documentation is missing that step. The mindset initially was that > the bootloader would be in there if you are progressing from blinky to > bletiny on a board - but that is never guaranteed, of course :) So it should > be highlighted that the bootloader step is needed if it is a fresh project > and target. > > Thanks, David for catching these gaps - this is immensely helpful! Thank for > the pull request. > > aditi > > >> On Jun 27, 2016, at 1:15 PM, David G. Simmons <[email protected]> wrote: >> >> >>> On Jun 27, 2016, at 3:52 PM, marko kiiskila <[email protected]> wrote: >>> >>> >>>> On Jun 27, 2016, at 12:19 PM, David G. Simmons <[email protected]> wrote: >>>> >>>>> >>>>> On Jun 27, 2016, at 1:30 PM, will sanfilippo <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> By default we do not enable flow control so those lines shouldnt do >>>>> anything. >>>>> >>>>> As Kevin states, you hook up RTS to CTS, CTS to RTS, TXD to RXD and RXD >>>>> to TXD (if that makes sense). Hopefully the cabling you are using is >>>>> labeled so it is easy to determine which wires are what (txd from >>>>> computer goes to rxd on board, etc, etc). >>>> >>>> Right, all that’s hooked up correctly. >>>> >>>>> >>>>> When you do newt debug, is the code running? Do you see the variable >>>>> g_os_time being incremented? That will tell you if the os is running and >>>>> if it is I suspect the rest is working as well. You should see characters >>>>> being spit out the TXD line (TXD from the nrf52) when bletiny boots up as >>>>> we dump information to the console on startup of bletiny. The serial port >>>>> should be set for 115200 baud, 1 stop bit, 8 data bits and no parity (if >>>>> I remember all that terminology correctly). >>>>> >>>>> I presume you have built and downloaded a bootloader to this board. While >>>>> some folks use newt run, I generally dont (dont ask me why; just my own >>>>> thing). The commands to use would be (assuming your target is named >>>>> ‘tgt’): >>>>> newt build tgt >>>>> newt create-image tgt 0.0.0 >>>>> newt load tgt >>>>> newt debug tgt >>>>> >>>>> After you do the newt debug tgt you should see the gdb prompt. At this >>>>> point you do this: >>>>> monitor reset >>>>> c >>>>> >>>>> Let it run for a bit them stop it in the debugger and do this: p/d >>>>> g_os_time. That should return some non-zero value. If you continue on and >>>>> then stop again and do p/d g_os_time, it should have incremented. Each os >>>>> time tick is 1 millisecond. >>>>> >>>>> Another possible issue here is the log level that is being used although >>>>> I suspect you have not messed with that. >>>>> >>>>> Let me know if things are still not working after all this. >>>> >>>> So just to be completely sure I did the following: >>>> >>>> 1) newt clean nrf52_boot >>>> 2) newt clean myble >>>> 3) newt build nrf52_boot >>>> 4) newt build myble >>>> 5) newt create-image myble 1.0.1 (I even incremented the version!) >>>> 6) newt load myble >>>> 7) newt debug myble >>>> >>> >>> newt load nrf52_boot? >> >> Well, that righ there was the ticket, and it seems to be a missed step in >> the tutorial. As soon as I added that, it all began to work. Serial over the >> FT232H is live, etc. So I guess I’ll add that to the Tutorial page as well. >> and maybe some of the debug information as that was also a helpful >> diagnostic. >> >> dg >> >>> >>> And in the debugger, right after attaching, try ‘mon reset’ before letting >>> target >>> continue. NRF52 target is not reset when debugger is attached (we could do >>> that, >>> just haven’t done the scripts like that for this platform). >>> >>>> All the output is as expected until: >>>> >>>> (gdb) p g_os_time >>>> $1 = 1143079104 >>>> (gdb) c >>>> Continuing. >>>> … >>>> (gdb) p g_os_time >>>> $2 = 1143079104 >>>> (gdb) c >>>> >>>> So the g_os_time is not incrementing, which indicates, I believe, that the >>>> actual program is not running, even though it seems to claim it is. >>>> Indeed, that value never changes, even across builds/loads/debugs. Always >>>> the same. (Variables won’t, constants aren’t and all that) >>>> >>> >>> What do system registers look like? I.e. is it executing bootloader or the >>> app? >>> >>>> If the problem is that it never actually starts then that would explain >>>> the flatline on the scope on TX, and hence no output to the serial line. >>>> >>>> dg >>>> >>>>> >>>>> >>>>>> On Jun 27, 2016, at 10:16 AM, David G. Simmons <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On Jun 27, 2016, at 1:08 PM, Kevin Townsend <[email protected]> wrote: >>>>>>> >>>>>>> >>>>>>> On 27/06/16 19:05, David G. Simmons wrote: >>>>>>>> Will, >>>>>>>> >>>>>>>> Thanks! One issue was certainly that I was using the PDK instead of >>>>>>>> the DK, I’ll add that to the documentation as there was no mention of >>>>>>>> this. And while I have been known, in the past, to get TX and RX >>>>>>>> backwards, that is not the case here. >>>>>>>> >>>>>>>> That being said, I’m still getting nothing, even on the scope where, >>>>>>>> no matter what was hooked to what, I would still expect to see the Tx >>>>>>>> pin toggling as data is written to it. Still flat-lined. I did try >>>>>>>> hooking up DTS and CTS — even though they’re not mentioned in the >>>>>>>> tutorial — in hopes that I might get some signs of life out of it that >>>>>>>> way, but still no joy. >>>>>>> >>>>>>> CTS on one side goes to RTS on the other side, and similar for RTS >>>>>>> which goes to CTS. Try switching the two lines? You may also need to >>>>>>> enable HW flow control in your terminal emulator depending on what you >>>>>>> are using. >>>>>>> >>>>>> >>>>>> Yup, got that too. The interesting bit is that both the Tx and Rx pins >>>>>> coming off of the NRF52 are flat-lined on the scope, which indicates >>>>>> that the board is unable to, or unwilling to, properly use those pins >>>>>> for some reason. >>>>>> >>>>>> dg >>>>>> -- >>>>>> David G. Simmons >>>>>> (919) 534-5099 >>>>>> Web • Blog • Linkedin • Twitter • GitHub >>>>>> /** Message digitally signed for security and authenticity. >>>>>> * If you cannot read the PGP.sig attachment, please go to >>>>>> * http://www.gnupg.com/ Secure your email!!! >>>>>> * Public key available at 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. >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> David G. Simmons >>>> (919) 534-5099 >>>> Web • Blog • Linkedin • Twitter • GitHub >>>> /** 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. >>> >> >> -- >> David G. Simmons >> (919) 534-5099 >> Web • Blog • Linkedin • Twitter • GitHub >> /** Message digitally signed for security and authenticity. >> * If you cannot read the PGP.sig attachment, please go to >> * http://www.gnupg.com/ Secure your email!!! >> * Public key available at 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. >> >> > -- David G. Simmons (919) 534-5099 Web • Blog • Linkedin • Twitter • GitHub /** Message digitally signed for security and authenticity. * If you cannot read the PGP.sig attachment, please go to * http://www.gnupg.com/ Secure your email!!! * Public key available at 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
