Hi Jacob,
On Tue, Feb 21, 2017 at 09:10:08PM -0700, Jacob Rosenthal wrote:
[...]
> I get two distinct hangs to make things more weird.
>
> Jacobs-MacBook-Air:~ jacobrosenthal$ newtmgr image list -cserial1 -t -ldebug
> 2017/02/21 20:36:03 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0
> Group:1 Seq:0 Id:0 Data:[]}
> 2017/02/21 20:36:03 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0
> Group:1 Seq:0 Id:0 Data:[]} into buffer [0 0 0 0 0 1 0 0]
> 2017/02/21 20:36:03 [DEBUG] Tx packet dump:
> 00000000 00 00 00 00 00 01 00 00 |........|
>
> 2017/02/21 20:36:03 [INFO] Outgoing:
> 00000000 06 09 |..|
>
> 2017/02/21 20:36:03 [DEBUG] Writing [6 9] to data channel
> 2017/02/21 20:36:03 [INFO] Outgoing:
> 00000000 41 41 6f 41 41 41 41 41 41 41 45 41 41 44 63 77
> |AAoAAAAAAAEAADcw|
>
> 2017/02/21 20:36:03 [DEBUG] Writing [65 65 111 65 65 65 65 65 65 65 69 65
> 65 68 99 119] to data channel
> 2017/02/21 20:36:03 [INFO] Outgoing:
> 00000000 0a |.|
>
> 2017/02/21 20:36:03 [DEBUG] Writing [10] to data channel
It looks like the board isn't responding at all. There are a few things
I would check:
* UART is properly configured in your app with the expected settings
(115200, no flow control).
* The mgmt/newtmgr package gets included in your target.
* An appropriate newtmgr transport gets included in your target (either
mgmt/newtmgr/transport/nmgr_shell or mgmr/newtmgr/transport/nmgr_uart)
The following newtmgr commands would be useful for verifying the above:
newt target dep <target-name>
newt target revdep <target-name>
newt target config show <target-name>
My suspicion is that your target doesn't include a newtmgr transport.
> Jacobs-MacBook-Air:~ jacobrosenthal$ newtmgr image list -cserial1 -t -ldebug
> 2017/02/21 21:07:18 [DEBUG] Writing newtmgr request &{Op:0 Flags:0 Len:0
> Group:1 Seq:0 Id:0 Data:[]}
> 2017/02/21 21:07:18 [DEBUG] Serializing request &{Op:0 Flags:0 Len:0
> Group:1 Seq:0 Id:0 Data:[]} into buffer [0 0 0 0 0 1 0 0]
> 2017/02/21 21:07:18 [DEBUG] Tx packet dump:
> 00000000 00 00 00 00 00 01 00 00 |........|
>
> 2017/02/21 21:07:18 [INFO] Outgoing:
> 00000000 06 09 |..|
>
> 2017/02/21 21:07:18 [DEBUG] Writing [6 9] to data channel
> 2017/02/21 21:07:18 [INFO] Outgoing:
> 00000000 41 41 6f 41 41 41 41 41 41 41 45 41 41 44 63 77
> |AAoAAAAAAAEAADcw|
>
> 2017/02/21 21:07:18 [DEBUG] Writing [65 65 111 65 65 65 65 65 65 65 69 65
> 65 68 99 119] to data channel
> 2017/02/21 21:07:18 [INFO] Outgoing:
> 00000000 0a |.|
>
> 2017/02/21 21:07:18 [DEBUG] Writing [10] to data channel
> 2017/02/21 21:07:18 [INFO] Incoming:
> 00000000 31 3a 5b 74 73 3d 37 38 31 32 73 73 62 2c 20 6d |1:[ts=7812ssb,
> m|
> 00000010 6f 64 3d 34 20 6c 65 76 65 6c 3d 31 5d 20 47 41 |od=4 level=1]
> GA|
> 00000020 50 20 70 72 6f 63 65 64 75 72 65 20 69 6e 69 74 |P procedure
> init|
> 00000030 69 61 74 65 64 3a 20 61 64 76 65 72 74 69 73 65 |iated:
> advertise|
> 00000040 3b 20 64 69 73 63 5f 6d 6f 64 65 3d 30 20 61 64 |; disc_mode=0
> ad|
> 00000050 76 5f 63 68 61 6e 6e 65 6c 5f 6d 61 70 3d 30 20
> |v_channel_map=0 |
> 00000060 6f 77 6e 5f 61 64 64 72 5f 74 79 70 65 3d 30 20
> |own_addr_type=0 |
> 00000070 61 64 76 5f 66 69 6c 74 65 72 5f 70 6f 6c 69 63
> |adv_filter_polic|
> 00000080 79 3d 30 20 61 64 76 5f 69 74 76 6c 5f 6d 69 6e |y=0
> adv_itvl_min|
> 00000090 3d 30 20 61 64 76 5f 69 74 76 6c 5f 6d 61 78 3d |=0
> adv_itvl_max=|
> 000000a0 30 20 61 64 76 5f 64 61 74 61 5f 6c 65 6e 3d 30 |0
> adv_data_len=0|
It appears the log output is being sent over the newtmgr transport. In
other words, text is getting logged to the console, and the newtmgr and
the cnosole are using the same uart (or a newtmgr transport isn't
enabled at all). To solve this one, I would disable logging entirely
for the moment - Add the following to your target's syscfg.yml file:
syscfg.vals:
LOG_LEVEL: 255
And then send the above three newt commands.
Thanks,
Chris
