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