CYW20706 modes: download, hosted, and embedded

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

cross mob
LJYe_2922526
Level 5
Level 5
25 likes received 10 likes received 5 likes given

I'm developing with CYW20706 without any external flash. I read “WICED-HCI-Control-Protocol.pdf” and I'm still confused about how to get to all the modes.

1) If I toggle RST_N, the RAM would be initialized to zeros, wiping the previously downloaded firmware. Is this correct?

2) If I set CTS to low, then de-assert RST_N, the device enters into autobaud firmware download mode where only few vendor specific HCI command that supports firmware download works. Is this correct? After firmware download procedures are completed, and LAUNCH_RAM is issued, the chip goes into embedded application mode?

3) I'm confused about what happens when I set CTS to high, then de-assert RST_N. HCI document mentioned the chip will read NVRAM for configurations, but 20706 does not have any NVRAM.

4) How to enter fully hosted HCI mode? I plan to use this mode in manufacturing to run standard HCI tests. Do I need to load a specific .hcd firmware to RAM for this? Where do I find this .hcd?

Thanks!

1 Solution

>>Do you mean my app code needs to send BT HCI reset to the stack? Is this done through API btu_hcif_send_cmd()?

No, you would send the reset over the HCI UART. The entire point of this is to send hosted mode commands over UART so there is no point in changing the application to send a reset if you have a host attached anyway. On the other hand, if you are trying to initiate some RF tests from within the app, then this is a different use-case that we would address very differently.

>>After the reset, in full HCI mode, is the chip in auto-baud mode again like in download mode?

No, it is in hosted mode.

>>If I use the hardware RST_N pin to reset the chip when it's in full HCI mode, it would go back to auto-baud download mode, correct?

Correct.

Jacob

View solution in original post

14 Replies
Anonymous
Not applicable

Hi,

Have you found answers for your questions as even I have same queries ?

Thank you,

Pravinkumar

Anonymous
Not applicable

rroymifo​    Please assist us here.

Thank you

Adding the Level 1 applications team.

grsr lsri rash mady gsns ankh,wwfe

And jact​ from Level 2

JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

1. Yes, asserting reset for the required duration puts you into a known stable power-on state. RAM will be wiped.

2. Correct.

3. The chip will check for the presence of attached FLASH and download it into RAM if it exists. If it finds no external flash, it will enter autobaud.

4. You can load the application as normal using the direct load method, then issue an HCI reset. The chip should now enter full HCI mode.

Jacob

Hi Jacob,

Is there a standard firmware for hosted HCI mode(using standard BT HCI, not WICED HCI)? I remember seeing discussions of people using 'uart.hex', but I'm not sure if it is for RAM or external flash. Could you provide the standard firmware in .hcd format (we don't use external flash)?

Thanks,

LJ

I don't believe it is necessary for you to acquire this file as the application code produced in the SDK will contain all of the required patches. The patches will still exist after you perform the HCI reset as I described in (4). If you do still require the HCD file, then you will have to work with your FAE as these are platform-specific files that must be custom made for your hardware.

Jacob

In (4), do you mean I should load my custom app as usual but instead of 'launch RAM', issue 'HCI reset'? How do I go into application mode after I'm done with the hosted HCI mode (full power reset and reload app? or just issue launch RAM at the end)?

You would issue launch RAM, then issue the HCI reset.

To enter the regular app code after, you will need to restart the whole download process as the app code will be wiped.

Jacob

After 'launch RAM' HCI command, the device should enter application mode and run my firmware. At this point I would need to issue the reset command defined in the WICED HCI document, correct? From looking at the demo app provided in the SDK, the WICED HCI reset is simply implemented as triggering a watchdog reset...

No, you must issue an HCI reset as defined by the BT spec.

Jacob

Do you mean my app code needs to send BT HCI reset to the stack? Is this done through API btu_hcif_send_cmd()?

After the reset, in full HCI mode, is the chip in auto-baud mode again like in download mode?

If I use the hardware RST_N pin to reset the chip when it's in full HCI mode, it would go back to auto-baud download mode, correct?

>>Do you mean my app code needs to send BT HCI reset to the stack? Is this done through API btu_hcif_send_cmd()?

No, you would send the reset over the HCI UART. The entire point of this is to send hosted mode commands over UART so there is no point in changing the application to send a reset if you have a host attached anyway. On the other hand, if you are trying to initiate some RF tests from within the app, then this is a different use-case that we would address very differently.

>>After the reset, in full HCI mode, is the chip in auto-baud mode again like in download mode?

No, it is in hosted mode.

>>If I use the hardware RST_N pin to reset the chip when it's in full HCI mode, it would go back to auto-baud download mode, correct?

Correct.

Jacob

Thanks Jacob. I'll give it a try.