> 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
