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

AIROC™ Bluetooth Forum Discussions

Dobre
Level 2
25 sign-ins 10 sign-ins 5 replies posted
Level 2

Good day!

Initially I bought CYBT-353027-EVAL. I thought it is debug-enabled but unfortunately it is not according https://community.infineon.com/t5/AIROC-Bluetooth/Can-t-debug-on-CYBT-353027-EVAL-in-ModusToolbox/m-... (comment by )

Then I saw this post https://community.infineon.com/t5/Bluetooth-SDK/Debug-of-CYBT-343026-EVAL-and-CYBT-353027-EVAL-using.... In this post KeTa_1341526 is expected the same problems with CYBT-353027_EVAL and CYBT-343026_EVAL and was advised by Charles_Lai ‎(Sep 16, 2021) to use CYBT-423028-EVAL instead.

I want to have step by step debugging - so I bought 2 CYBT-423028-EVAL. First of all it's not possible to use them in ModusToolbox because it is called obsolete - only old WICED Studio can be used. Secondly I still can't debug it. I read WICED JTAG Debugging for CYW207x9.pdf. But this document is about CYW920719WCDEVAL development board and all mentioned instructions are not suitable for my CYBT-423028-EVAL although they have the same CYW20719 core.

Could you provide me with the clear instruction how can I switch on debugging on my CYBT-423028-EVAL? I waste a lot of time trying to start work on this evals and have not even moved ahead...

Best regards,

Dobre

0 Likes
1 Solution
Charles_Lai
Moderator
Moderator 250 replies posted 100 solutions authored 100 replies posted
Moderator

Hi,

Could you show the log of why the doc's instructions were not suitable?

And the hardware debug wouldn't provide much help though. Because as a wireless communication controller, many callbacks require synchronic execution. Besides as a microcontroller that has limited sources for stack/heap/multi-tasks, the chip couldn't provide fully compatible and functional hardware debug as you wish.

So if you manually pause and resume the execution, some events are usually missed or some steps could expire during that period. Yet HCI trace or stub log could easily cover this and provide a clean and accurate understanding of the issue.

So we seldom use hardware debug upon a BT controller. Instead, we recommend you rely on the HCI trace or stub log.

You can find the guide here:
CypressAcademy WBT101: CH05 Debugging

Or you could go through the whole training of the WICED/AIRoC chips to get you hands-on:
https://github.com/Infineon/CypressAcademy_BT101_Files

Best regards

View solution in original post

0 Likes
2 Replies
Charles_Lai
Moderator
Moderator 250 replies posted 100 solutions authored 100 replies posted
Moderator

Hi,

Could you show the log of why the doc's instructions were not suitable?

And the hardware debug wouldn't provide much help though. Because as a wireless communication controller, many callbacks require synchronic execution. Besides as a microcontroller that has limited sources for stack/heap/multi-tasks, the chip couldn't provide fully compatible and functional hardware debug as you wish.

So if you manually pause and resume the execution, some events are usually missed or some steps could expire during that period. Yet HCI trace or stub log could easily cover this and provide a clean and accurate understanding of the issue.

So we seldom use hardware debug upon a BT controller. Instead, we recommend you rely on the HCI trace or stub log.

You can find the guide here:
CypressAcademy WBT101: CH05 Debugging

Or you could go through the whole training of the WICED/AIRoC chips to get you hands-on:
https://github.com/Infineon/CypressAcademy_BT101_Files

Best regards

0 Likes
Roy_Liu
Moderator
Moderator 1000 replies posted 500 solutions authored 5 questions asked
Moderator

This discussion is being locked due to being inactive for a long time, please start a new thread if needed.

Roy Liu
0 Likes