Scrambled output via serial port (bypass encoded trace output)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
user_2112781
Level 4
Level 4
10 likes received 10 likes given 5 likes given

Hello,

I'm getting strange output when I try to display the trace of a BLE application over the serial USB cable.

I'm using the right settings (115200n8) and I tried with different tools (miniterm.py, screen, gtkterm) under Mac, Windows and Linux.

I get some output that makes sense and some that is completely hazardous (non ASCII characters)

Here is the output of hello_sensor:


Broadcom Debug Port: BLEAPP CFA d�hello_senso����02 16 00 00 2a �48 65 6c 6c 6f 00 00 00 00 00 00 00 00 00 00 00 �02 18 00 01 2a ����23 20 56 7c 05 cf 6e b4 c3 41 77 28 51 82 7e 1b �32 2f2 9b 5e ���0a 18 �02 4f 00 29 2a �42 72 6f 61 64 63 6f 6d �02 51 00 24 2a �31 32 33 34 00 00 00 00 �02 53 00 23 2a �93 b8 63 80 5f 9f 91 71 �0f 18 �02 63 00 19 2a �64 02 01 06 03 19 00  permission check retCode = 00 23 20 56 7c 05 cf 6e b4 c3 41 77 28 51 82 7e 1b �02 01 05 11 0blecm evt handl01 0a 20 00 @$*#04FFF6F70092011E0300C1E804640000008003BA1A002800008003BE1A000000008003AE1A620000008003B21A020000008003B61A050005008003BA1A032800008003BE1A000000008003AE1A630000008003B21A020000008003B61A010001008003BA1A192A00008003BE1A000000008003DA1A0000000000074A05177A732000074E0531690000000782061100010000078206040100000007820603100E000007820620000F000007820601201C000007A207000001000007A607000000000007D2070000000000071A080100000000078A08010000000007EE07000000000007A2080000000000E5490B000000000007362A0100@$*#04FF1EF7009201030000073A2A500000000007522A500001000007021F0100hello_sensor_timeout:hello_sensor_timeout:1

                                                                            hello_sensor_timeout:2

     hello_sensor_timeout:hello_sensor_timeout:4

                                                hello_sensor_timeout:5

                                                                      hello_sensor_timeout:6

                                                                                            hello_sensor_timeout:hello_sensor_timeouthello_sensor_timeout:9

                                                              hello_sensor_timeout:10

                                                                                     hello_sensor_timeout:11

               hello_sensor_timeout:1hello_sensor_timeout:13

                                                            hello_sensor_timeout:1hello_sensor_timeout:15

            hello_sensor_timeout:16hello_sensor_timeout:17

                                                          hello_sensor_timeout:18hello_sensor_timeout:hello_sensor_timeout:20hello_sensor_timeout:21

                                                       hello_sensor_timeout:hello_sensor_timeout:23

      hello_sensor_timeout:24

Does anybody has an idea of what could be wrong ?

0 Likes
1 Solution
StBa_721356
Level 5
Level 5
50 likes received 25 likes received 10 likes received

Have you tried the following:

bleapp_set_cfg((UINT8 *)gatt_database,

                       sizeof(gatt_database),

                       (void *)&app_cfg,

                       NULL,                           // Don't configure the puart.

                       (void *)&gpio_cfg,

                       app_create);

This might solve the problem because PUART is not used anymore by the app.How to Disable PUART

View solution in original post

8 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

Note that if you are using SDK 2.X with the BCM20737 and A1 firmware, then the traces are encoded and standard terminal emulators will not work.

There is more on this topic here: Re: How do I interpret the extra tracing data ?

0 Likes

Are you sure that this applies to the second UART as well?

Reading the post about the new SDK 2.0.1 tracing feature I had the impression that this would only affect the first UART (the one which is used to download the application).

Is there documentation available about how the tracing data is encoded inside the UART stream? It should not be hard to decode the tracing data if documentation would be available...

0 Likes

The traces are encoded in ROM, so I'm pretty sure the resulant trace is encoded whether destined for the HCI or PUART.

I will check with the development team to see if we will release the encoding technique.

The funny thing is that I managed to get a "correct" output by using the first UART.

By correct I mean only ASCII characters and not scrambled (see log).

Since I can't read the first UART and upload an application at the same time, I had to play with the DIP switch 2 of SW4 so that the board loads directly after a reset. Here are my steps:

- I connect the board to the host (USB)

- I upload an application

- I turn off the DIP Switch 2

- I connect a terminal to the first UART

- I press the reset button

- I get a correct output

It appears that there is something wrong with the UART number 2 but it is really not convenient to have to switch all the time when I want to make a change.

Output:

hello_sensor_create()
1.00
0118
0018
021600002a
48656c6c6f0000000000000000000000
021800012a
0002
2320567c05cf6eb4c341772851827e1b
322a0026f6699168eec2be444db95c3f
2dc38a
48656c6c6f2030
0000
0a2d001a89074a2f3b7ea681443ff9a8
f29b5e
00
0a18
024f00292a
42726f6164636f6d
025100242a
3132333400000000
025300232a
93b863805f9f9171
0f18
026300192a
64
02010603190002060948656c6c6f
020a04

 permission check retCode = 00 
00
0000
2320567c05cf6eb4c341772851827e1b
02010511072320567c05cf6eb4c34177
2851827e1b060948656c6c6f

blecm evt handler: 
0e0401082000

blecm evt handler: 
0e0401092000

blecm evt handler: 
0e0401082000

blecm evt handler: 
0e04010a200c

blecm evt handler: 
0e0401062000

blecm evt handler: 
0e04010a2000
@$*#04FFF6F70092011E0300C1E804640000008003BA1A002800008003BE1A000000008003AE1A620000008003B21A020000008003B61A050005008003BA1A032800008003BE1A000000008003AE1A630000008003B21A020000008003B61A010001008003BA1A192A00008003BE1A000000008003DA1A0000000000074A05177A732000074E0531690000000782061100010000078206040100000007820603100E000007820620000F000007820601201C000007A207000001000007A607000000000007D2070000000000071A080100000000078A08010000000007EE07000000000007A2080000000000E5490B000000000007362A0100E803@$*#04FF1EF7009201030000073A2A500000000007522A500001000007021F01000000hello_sensor_timeout:0

hello_sensor_timeout:1

hello_sensor_timeout:2

hello_sensor_timeout:3

0 Likes

I will ask the development team to comment on this one.  The traces are scrambled in ROM, so i'm not sure how reconfiguring the switches unscrambles.

StBa_721356
Level 5
Level 5
50 likes received 25 likes received 10 likes received

Have you tried the following:

bleapp_set_cfg((UINT8 *)gatt_database,

                       sizeof(gatt_database),

                       (void *)&app_cfg,

                       NULL,                           // Don't configure the puart.

                       (void *)&gpio_cfg,

                       app_create);

This might solve the problem because PUART is not used anymore by the app.How to Disable PUART

Oh great it works ! So that was it, I set it to NULL and now the output is perfectly normal as with the first UART but without switching on and off every time.

So this means the trace output on PUART is not encoded but the pure characters printed with ble_tracex()? Would be good to know