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

AIROC™ Bluetooth Forum Discussions

jbruneaux
Level 3
Level 3
10 replies posted 10 questions asked First like given

Hi,

We are experiencing unexpected reboot of a CYBT-483056-02 module used on a CYBT-403056-EVAL board under some circumstance (two connection created). We have no clue of what is happening, and during the research for debugging options, I came accross this topic (https://community.infineon.com/t5/Resource-Library/CYW20719-and-CYW20735-Clocks-RTC-WatchDog-Timer-A...) where it's stated that when the device crash, there's a core dump output on the HCI Uart.

Indeed, looking at the data output on HCI Uart, I can see strings that belong to the firmware (version string and also some libraries strings). The HCI format seems to start with a pattern (0x04 0xFF 0xF4 0x1B 0x03), followed by what seems to be a memory address. Unfortunately I couldn't find any document that describe the HCI vendor command for this, and BT-Spy do not seem to identify that this is a core dump (simply print some weird chars).

Can you please help me converting the core-dump to an file that I can examine with GDB ? We already played with many parameters to find the issue.

 

Also, I found out that using the wiced_bt_printf API will corrupt the traces send on HCI-uart for debug (I used this API to format some strings that we use for our software usage, and found that this was generating some partial repetitions on the traces send to wiced_bt_trace). I've used a custom printf/snprintf implementation and the problem is solved.

Regards, Jerome

0 Likes
6 Replies
advait_kulkarni
Moderator
Moderator
Moderator
100 sign-ins 100 replies posted 25 solutions authored

Hi @jbruneaux ,

You can use tools like userdump.exe, procdump, MiniDumpWriteDump fucntion or any online intsruction set like: https://www.cse.unsw.edu.au/~learn/debugging/modules/gdb_coredumps/ for it. Kindly let me know if any of this helps. Also please share the file examined with gdb with us for our reference.

Thanks and regards,

Advait Kulkarni

0 Likes
advait_kulkarni
Moderator
Moderator
Moderator
100 sign-ins 100 replies posted 25 solutions authored

Hi @jbruneaux ,

I misinterpreted your query. So, the dump output must have been generated due to some VSC. Can you please let us know all the commands that were sent to the module before the reboot happened? BTSPY or terminal logs of the same would be helpful. I checked the opcode of the event that you are receiving and it does not match with any of those defined by Infineon.
Also did you try disabling the watchdog? Sometimes, junk logs are generated if the reset happens while memory related operations are going on. 

Thanks and regards,

Advait Kulkarni

0 Likes

Hi @advait_kulkarni ,

Well, that's not junk data which is output on the HCI uart but it is some core dump (as mentionned in the link that I posted in the first message : "The core dump is sent over the HCI-UART as BT-HCI vendor specific events.".). The internalblue hci parser (https://github.com/seemoo-lab/internalblue/blob/master/internalblue/hci.py around line 1101) explain some of the content that I was able to recover from the dump (in this dump, I can see the strings of our application, so that's not junk). It's clearly some content properly generated by the ROM code of the CYW20719. I've found that it is probably generated in the interrupt handler of the watchdog, as well as in every fault handler (bus fault handler vector, hardfault handler, ...). The function name in the exported symbol of the ROM (see patch.sym file or event the generated map file of any demo example) is A5dbb9e00 (address 0xA4DC6 of the ROM code)).

The missing part in the hci.py of internal blue is the decoding of the 0x9c packet type which is the Cortex-M4 CPU registers (addresses 0xe000ed00, 0xe000ed04 and so on, corresponding to registers important for debug purpose like NVIC interrupt states, NVIC interrupt enable states, ...).

Also, it seems like disabling the watchdog is not really effective, but I will make more test on this.

 

We really need to be able to debug what's happening on the product when it reboot, otherwise we can't develop the product based on this chipset. It's important that debug tools are available for your customers and that we don't loose to much time trying to understand what might be happenning in the ROM when simply using some common wiced API functions.

Hope we can get some help quickly.

0 Likes
advait_kulkarni
Moderator
Moderator
Moderator
100 sign-ins 100 replies posted 25 solutions authored

Hi @jbruneaux ,

We have this article: https://community.infineon.com/t5/Knowledge-Base-Articles/Sending-AIROC-HCI-UART-and-RAW-HCI-UART-co... that explains how to decode the HCi commands and events. However, as I said that the event you have received was not matching with the ones defined by infineon. Can you please send the entire event (along with the address it is returning) so that I will go through various files and also check what address it is pointing to?

Thanks and regards,

Advait Kulkarni

0 Likes

Hi @advait_kulkarni 

I know this document and I also couldn't find the trace of those events in this documentation. Probably that it is an internal debug tool that do the decoding of the content and that's why it is not disclosed in a public document, but if you have access to the engineers at cypress/infineon, they must have that tool somewhere as well as some sort of documentation that goes along with it.

I've attached an extract of the hci raw log (I can't attach the whole file because it contains some data from our product that are confidential). This is the first HCI events that are received during a crash of the module.

I also pointed you to the function in the rom code that seem to generate the whole core-dump (exported function name in patch.sym is A5dbb9e00, and address is 0xA4DC6 in the ROM code). The function name is probably mangled for some ROM code proprietary issues so you might need to find the real function name by looking at the map file of the ROM code, not by searching this function name that I've provided. One of the way would be to use the addr2line tool to find the source file and address (see the example command line bellow. You might have to replace the "arm-none-eabi-addr2line" command with the compiler prefix that you use):

arm-none-eabi-addr2line -e <path to the rom code elf file> 0xA4DC6

Regards, Jerome

0 Likes

Hi,

 

Looking at patch.elf from an old wiced release, I found an interesting symbol name which correspond to the CPU registers list that I can find in the core-dump. You can search for "dbfw_hal_coredump_hwregs_table" in the ROM code and you will find the function which generate the core-dump for sure.

 

Regards,

0 Likes