Custom Hardware CYBT-213043-02 Programming

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

cross mob
ToKr_4627616
Level 1
Level 1
First question asked First reply posted First like received

Hello,

I am working on a project that uses the CYBT-213043-02 EZ-BT Module. I am having trouble downloading firmware to the module (more specifically the CYW20819 silicon device on the module). Below is some background info and a description of my issue

Background:

I found little mentioned with regard to programming the module WITHOUT an onboard USB to UART bridge such as the CY7C65215 included on the CYBT-213043-EVAL kit. In the preliminary CYBT-213043-02 datasheet (I believe the preliminary is all that is available currently), it states under the HCI UART Interface section,"CYBT-213043-02 includes a UART interface for factory programming...". Additionally, the Knowledge Base Article KBA223428-Programming an EZ-BT WICED Module is included as a reference. Therein it describes using the HCI-UART interface to download application code to the Cypress CYW20706 silicon device. The KBA included more detail than the datasheet, but I didn't know if it was applicable for the CYW20819. I went ahead with what I could gather from these references (preliminary CYBT-213043-02 datasheet, KBA223428, and CYBT-213043-EVAL) and broke out the dedicated UART pins of the module for programming/included reset/recover buttons.mcu_connections.jpgprogramming_header.jpgbuttons.jpgprog_header.JPG

Current Situation:

After assembling the board (no evident hardware issues), I connected an external USB to UART bridge (shown as COM3 in device manager) to the UART pin header to download test firmware. Fired up ModusToolbox IDE and tried the Program launch setting. The COM port was recognized but I kept getting a baud rate error. I tried just about everything, making sure baud rate was 115200, recover/reset button procedure, searching through community posts, flipping tx and rx lines, editing makefiles, downloading CyBlueTool, etc. No progress.

pastedImage_1.png

pastedImage_0.png

pastedImage_6.png

Question:

Did I totally miss something? Let me know if there is any more information I can provide to help resolve the issue, tried to be descriptive yet brief.

Thanks!

1 Solution
DheerajPK_41
Moderator
Moderator
Moderator
750 replies posted 500 likes received 500 replies posted

Hi,

Seems like you have done enough high level checks in your custom board to detect the failure.

The schematics and UART connections are looks good to me. (Since PC could detected the board).

Since the error says, "cannot determine the baud rate", We need to confirm whether the device actually goes to the autobaud mode after recovery procedure or not. (Press and hold Recovery button- Press and release Reset button - Release Recovery button).

I would suggest you to try monitoring the reset line and UART signals using a logic analyzer to understand the situation much better.

It would be great if you can independently test each of the below units to debug this issue.

  • Modustoolbox and Application configurations (makefile, UART, etc.). :- Use CYBT-213043-MESH kit to verify it. Try to download the application to the MESH kit to confirm that the Software side is correctly configured.
  • External USB-UART bridge.

Thanks,

-Dheeraj

View solution in original post

3 Replies
DheerajPK_41
Moderator
Moderator
Moderator
750 replies posted 500 likes received 500 replies posted

Hi,

Seems like you have done enough high level checks in your custom board to detect the failure.

The schematics and UART connections are looks good to me. (Since PC could detected the board).

Since the error says, "cannot determine the baud rate", We need to confirm whether the device actually goes to the autobaud mode after recovery procedure or not. (Press and hold Recovery button- Press and release Reset button - Release Recovery button).

I would suggest you to try monitoring the reset line and UART signals using a logic analyzer to understand the situation much better.

It would be great if you can independently test each of the below units to debug this issue.

  • Modustoolbox and Application configurations (makefile, UART, etc.). :- Use CYBT-213043-MESH kit to verify it. Try to download the application to the MESH kit to confirm that the Software side is correctly configured.
  • External USB-UART bridge.

Thanks,

-Dheeraj

Hey Dheeraj,

Thanks for response and advice. I successfully programmed the module using the USB-UART bridge on the CYW920819EVB-02 Evaluation Kit. I removed the HCI UART jumpers from the evaluation kit and connected the UART lines (RX,TX,CTS,RTS) to the custom board.

IMG_5010.JPGIMG_5006.JPG

IMG_5008.JPG

Something to note is that I had to manually specify the HCI UART COM port in the makefile. Auto serial port detection failed. Also, the "Failed to determine baud rate" error still occurs with the above setup if the recovery procedure (Press and hold Recovery button- Press and release Reset button - Release Recovery button) has not been carried out. If the recovery procedure is carried out right before programming, no issues.

Perhaps it is like you said, some issue with the external USB-UART bridge. I probed the RX and TX lines and there were no indications of communication during programming attempts. No wonder they failed. I don't know whether that is a compatibility with modustoolbox/drivers issue or if it is just a broken bridge. I guess the lesson here is to use verified hardware made by the manufacturer (the eval kit) for the best shot at things working.

Thanks for the help.

Hi,

Thank you very much for sharing the test results. Glad to hear, that the programming worked for you.

Recovery procedure is kind of mandatory in WICED BT chips before the download. Especially if the program that has been flashed previously to the chip is capable of modifying the HCI baud rate. In that case, the chip should be put it into autobaud mode before download using the recovery procedure.

"I don't know whether that is a compatibility with modustoolbox/drivers issue or if it is just a broken bridge."

-> I believe you will be able to test the bridge by executing a loopback test. Short the Rx and Tx pins, use any serial terminal emulator to send some random data and check whether you receive it or not. You will be able to create similar tests to check the working of CTS and RTS too.

Thanks,

-Dheeraj