> On Jun 27, 2016, at 1:30 PM, will sanfilippo <[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
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)
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/ 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
