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