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