nRF5340 Audio accessing debug messages

[pradeep2481]

Hi,

I am trying to evaluate the BLE audio using  nRF5340 Audio EVK. I have total 3 evks, one of them works as an audio gateway and the other 2 as headset.

My development environment (build + firmware flashing) is based on Linux and I am able to check the CIS mode and it works perfectly. 

But I am not able to see any console logs (system logs and application specific logs).

When I connect the usb-c cable to the Linux host and turn the EVK on  I could see total 4 ports 2 FTDI devices (ttyUSB0,  ttyUSB1) and 2 modem devices (ttyACM0, ttyACM1).

With minicom utility tried to see the output on all these devices and the output of all of them were empty.  So how can I access the console/logs in nRF5340 Audion evk?

Thanks in advance.

Best regards,

Pradeep

[Karl Ylvisaker]

Hello Pradeep,

What UART settings are you using in your terminal, and have you made any changes to the prj.conf of the nrf5340_audio reference application? If so, could you detail these changes?
I personally usually just use the Visual Studio Code nRF Terminal to monitor the device output - could that be an option for you to try as well?

Best regards,
Karl

[pradeep2481]

Hi Karl,

Thank you so much for your quick response.

My terminal settings are like below.

115200 8N1 (Baud rate 115200, 8 data bits, no parity, 1 stop bit)
Hardware Flow Control : No 
Software Flow Control : No

In the prj.conf I have the added the following settings.

CONFIG_UART_CONSOLE_LOG_LEVEL_DBG=y
CONFIG_LOG_MAIN_LEVEL=4

Currently I am building from command line and I did not install the Visual Studio Code. I appreciate your suggestion to use the Visual Studio Code nRF Terminal, but currently I would prefer to do it from the command line.

Best regards,

Pradeep

[Karl Ylvisaker]

Hello again, Pradeep

Thank you for your patience with this.

pradeep2481 said:

Currently I am building from command line and I did not install the Visual Studio Code. I appreciate your suggestion to use the Visual Studio Code nRF Terminal, but currently I would prefer to do it from the command line.

Thank you for clarifying! :) 

pradeep2481 said:

115200 8N1 (Baud rate 115200, 8 data bits, no parity, 1 stop bit)
Hardware Flow Control : No 
Software Flow Control : No

These parameters are correct.
I just tested this with the default nRF5340_audio application (no modifications made) in the gateway configuration, and I am able to see logs immediately in my non-VSC terminal (I used Termite for this test) just fine.
Have you checked through all the COM ports for output? Could you try resetting the Audio DK after you have opened to COM port, to see if it could have been an issue with opening it?

Best regards,
Karl

[pradeep2481]

Hi karl,

Thanks for your input.

When I tried resetting the GW I have seen some debug messages in the serial console. But it is unreadable, like below. I have increased the volume, then I could see only those logs readable.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

����JJ*Z���������M舘�����￨��ZGW [00:00:20.39,8bblent_remote_ client p rmevice[0] 0x2000a1����H�JJή!���JJJ�H�L�;挌H�ۈ���s�H�罟����M�������迿����JJΦ����JJJ��L�;挌H�ۈ���s���爽�GW [000:20.329,895] <wrn> ble_audio_services: Failed tovolume up f channel-16 �����H硽������O��辿
GW [00:0:20.329, <dbg> ble_audio_services: ble_vcs_client_remote_set: VCS clto remote device[1] 0x2000a298�;�JȈ�y���������

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Same observed for the headset too. I have to press some keys to get the logs.

Best regards,

Pradeep

[Karl Ylvisaker]

Hello Pradeep,

pradeep2481 said:

Thanks for your input.

No problem at all, I am happy to help! :) 

pradeep2481 said:

When I tried resetting the GW I have seen some debug messages in the serial console. But it is unreadable, like below. I have increased the volume, then I could see only those logs readable.

Hmm.. that does not seem right at all. It seems like your serial terminal might be decoding this wrong, either because it is trying to use a different unicode version, or that it is attempting to decode some control characters, maybe?

It seems to me that the output from the device is correct, but the issue is with the terminal's decoding of the incoming characters.

Could you try this again with another serial terminal, like Termite, or could you check which standard the terminal is using to decode the characters?

Best regards,
Karl