firmware programming through FTDI VCOM 22 to BCM20736S

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

cross mob
Anonymous
Not applicable

Hi,

I am using a FTDI based virtual UART to program the BCM20736S on my own develop PCB. I am pressing the reset button but the WICED Smart SDK is not detecting my device on this virual Comm port.

Seek your kind guidance for programming  the firmware in custom design.

Waiting for your kind reply.

Thanks in advance...

Best Regads,

Ghalib 

0 Likes
1 Solution

Kits like WICED Sense were designed for demo purposes, so those need to come up in Application mode. If you want to program them, you need to crack the case and reset the device.

So per the TAG3 board schematic in the Hardware User Guide (SDK 2.x and TAG3 Board)​, you will notice that SW5 on the TAG Board applies VDDIO to the SDA pin on the EEPROM, preventing the device from reading the image stored in the EEPROM and forcing it into programming mode (insert this into the boot logic I provided earlier).

So with regards to I2C on boot, if VDDIO is present on SDA during boot up, then the firmware bypasses the step where it looks to the EEPROM for a valid image and goes directly into programming mode.

However, you will find comments in other posts which imply that you can also GND the SDA pin and see the same behavior.

This works as well and is probably a better choice since connecting SDA to Vdd/Vio to recover is probably not optimal for the following reason provided to me by one of the senior firmware engineers:

SCL and SDA are both open-drain configuration and the pull-ups pull the signal high while the HW drives it low (never drives high, but floats the output pad leaving the pull-up to pull the line high). If you put a scope to either of these lines on the board when the firmware accesses these, you will see that high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC.

If you connect SCL/SDA to Vdd, then when the HW block drives SDA low, there will be a direct short (though momentary) between Vdd and GND, which is not ideal (even if the recovery works fine). This will happen pretty early during boot because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip.

So shorting to GND on the other hand is safer because that is what happens when there is a 0 bit on the bus and there is a 10K pull-up which will limit the current to something within the max ratings of all components on this line.

The forums are the only place where these things are documented.

jakewtorres

View solution in original post

0 Likes
24 Replies
JacobT_81
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

Hi ghalibjanjua

When you connect your custom PCB, are you able to find the COM port in you Windows Device Manager?

If the FTDI is wired to the USB correctly, the COM port will appear whether or not a 20736S chip is connected on the other side. If you can, in fact, find the COM port, we can narrow the problem down to the interface on the 37 chip-side of the FTDI.

Jacob

0 Likes
Anonymous
Not applicable

Hi Jacob,

Thanks a million for your reply.

My FTDI is showing COMM port 22 in device manager. I'm mentioning UART=COM22 in make target like "hello_sensor-BCM20736TAG_Q32 download UART=COM22" but when I double click message appears reset BCM20736S and try again.

Seek your guidance in it.

Thanks again.

Kind Regards,

Ghalib

0 Likes

Hi ghalibjanjua

First, please attempt to recover the chip by booting from ROM, then editing the make target so it overwrites the entire EEPROM.

     1. power cycle while your SDA pin is connected to ground. (this disables i2c communication to EEPROM forcing the system to boot from ROM).

     2. Input the make target "hello_sensor-BCM920737TAG_Q32 recover UART=COM22" and execute the make.

If this still doesn't work, is there any way that you could post your schematic or perhaps just the portion that interfaces to the FTDI chip?

Also, please attempt the below make target without specifying COM port:

"hello_sensor-BCM920736TAG_Q32 download"

*this is how it appears on my local machine but may have changed in newer SDK versions (notice the chip number slightly varies)

Jacob

0 Likes

What is the state of the HCI Rx line when you attempt to program the device?

A pullup on the HCI UART RX line should cause the part to come up in prgramming mode.

0 Likes
Anonymous
Not applicable

Hi Jacob,

Thanks a million for your reply.

1-  In my schematic SDA pin is pulled High and I have provided the external ground and tried the "hello_sensor-BCM920737TAG_Q32 recover UART=COM22" and console message says "recovery failed"

2- I have tried "hello_sensor-BCM920736TAG_Q32 download" but message console says unable to find the Device.

3- I want to mention here that I am adding "UART=COM22" by editing "hello_sensor-BCM920736TAG_Q32 download" . you are right it appears the same "hello_sensor-BCM920736TAG_Q32 download" on my machine as well.

4- In my schematic HCI UART RX is pulled low as per your instruction I have provided the external pull-up but results are same "Download Fails"

5- My FTDI circuit is as below and I'm using UART at 1.8V and I have tested it its working OK.

pastedImage_0.png

6- My BCM20736S circuit is as follows & VDD_C=1.8V.

pastedImage_1.png

Seek your further guidance.

Thanks again.

Have a nice day!
Kind Regards,

Ghalib

0 Likes

Per the Electrical Chars shown here: Re: BCM20736 UART Rx Voltage level

The HCI UART/EEPROM is on the VDDM rail, which suggests a lower operating level of 1.62V, below which performance degrades.

In fact, if VDDIO is 1.8V, then VIH on HCI UART RX would be 1.35V (VDDO x .75).

I believe this is why for most custom boards that use external FTDI programming cables, we require the 3V version of the FTDI cable specified here: Programming the TAG2/TAG3 Board using command line tools

The BLE apps team can confirm on Monday when everyone returns to the office.

0 Likes
Anonymous
Not applicable

Hi Jacob,

Thanks a million for your reply.

Is it ok? if I operate BCM20736S at 1.8V and HCI UART at 3.0V . Will I give a try to download the firmware with these voltage levels?

Have a nice day!

Kind Regards,

Ghalib

0 Likes
Anonymous
Not applicable

Hi Jacob,

Thanks for your valueable guidance. I have tried to operate the FTDI at 3.0V and 3.3V but no success in console when I mention UART=COM22 it display message "Download failed - Press the reset button on the device and retry". I have tried it with pull-up on HCI RX but results are still unsuccessful.

Seek your help and guidance.

Thanks.

Kind Regards,

Ghalib

0 Likes

Hi ghalibjanjua​,

Based on the pinout, it appears that you're using a FT232R. Is this correct?

Upon quick analysis of your schematic, it may be that pin 20 is incorrectly wired. What is VDIO powered at? According to the data sheet for FT232R, "The minimum operating voltage VCC must be +4.0V (could use VBUS=+5V) when using the internal clock generator."

Also, I want to ensure that you did the recovery process correctly. You can find more detailed instructing in other forum posts. The core of it is to power cycle while SDA is pulled low. Then, release SDA so data can once again flow to EEPROM. Then carry out the firmware recovery process by changing the make target.

Jacob

0 Likes
Anonymous
Not applicable

Hi Jacob,

Thanks a million for your reply. I'm using FTDI232RL and have tested it with Serial Terminal @3.0V and its working fine.

I have made the SDA pulled-low and power up the device then release it and made the HCX RX pull-high and ran the recovery "health_thermometer-BCM920737TAG_Q32 recover UART=COM22" but it failed.

Mean until I'm unable to recover I can't download code in the core?

Looking forward for your kind guidance.

Kind Regards,

Ghalib

0 Likes
Anonymous
Not applicable

Hi Jacob,

Kindly  let me know the baud rate of COM port and data that appears on COM. I want to view in serial console.

Kind Regards,

Ghalib

0 Likes
Anonymous
Not applicable

Hi jakewtorres

unfortunately I am still unable to recover or download the firmware in to BCM20736S. I seek your help if you can tell me if there is any way to program the board with BCM92073X_LE_KIT as below:

pastedImage_0.png

Also let me know do I need to use NODLMINIDRIVER  for FTDI chip, I'm using SDK2.2.2.

Thanks in advance.

Waiting for your reply.

Kind Regards,

Ghalib

0 Likes
Anonymous
Not applicable

Hi,

Need help I'm still unable to download firmware or recover BCM20736S.

1- On my SDA pin 1.8V is coming, let me know if this behavior is OK or not ?

2- I am able to make USB2UART from CP2015 which two COM ports are appearing, which to use (on hardware I'm using pin 12 & 13 of IC)? I'm using COM13 when it appears COM13 & COM14.

3- Is there any why to check BCM20736S is working or not? mean any test.

Waiting for your reply.

Thanks in advance.

Kind Regards,

Ghalib

0 Likes

Apologies for the delay.

Baud rate should be 115200.

Were you able to use CP2015 to download to the board?

1.8v sounds right for your SDA pin.

There is likely a voltage problem/logic level mismatch somewhere, or a problem in your recovery process. What is VDIO running at on your schematic?

Try increasing VDD_C, it will go up to 3.3. I've never personally run the chip below 2v.

You will certainly need to do a recovery before any download will work at this point. 

Jacob

0 Likes
Anonymous
Not applicable

HI Jacob,

Thanks a million for your reply.

VDD_IO is 3.0V for UART to operate at 3.0V.

Initially UART was also at 1.8V then what I understood from your reply is 1.8V is less so I raised the UART to 3.0V keeping BCM20736S power at 1.8V, Is it OK?

Kind Regards,

Ghalib

0 Likes

If you are still using the same FTDI chip, put 5v on VDDIO and 3.3v on VDD_1.8.

Then on VDD_C put 3.3v.

Please attempt the recovery process at these voltage levels.

Are you following the exact recovery process? What do you see on UART traces when you attempt it?

0 Likes
Anonymous
Not applicable

Hi Jacob,

Thanks a million for your help and kind cooperation, problem  got solved.

Kind Regards,

Ghalib

0 Likes
Anonymous
Not applicable

Hi jakewtorres

I just noticed that you suggest to pull high the UART_RX line to enter programming mode. Why is this needed? All the suggested reference designs have this line pulled low.

Regards

Marco

0 Likes

Remember that When sampled on RESET only:

HCI UART Rx = High (Programming mode)

HCI UART Rx = Low (Application mode)

From RESET, the boot sequence for the BCM2073XS series essentially follows the process defined below:

1.

Code in ROM executes and initializes the device processor, clock domains, peripherals, etc. 

2.

The following checks then occur:

2a.

Boot ROM checks EEPROM for a valid configuration

And if not found

Boot ROM then checks Serial Flash for a valid configuration

If a valid configuration is found in either location and HCI_UART RX  is NOT asserted, the Boot ROM will continue to load the rest of the configuration, patch and user application code.

At this point, the part comes up in application mode running the previously programmed application.

Note: In addition, if HCI_UART RX  is asserted, the part will still come up in programming mode, even though a valid configuration was found.

2b.

If no valid configuration was found, the next step depends on whether the HCI_UART RX pin is asserted or not:

• If HCI_UART RX  is asserted, the part enters recovery mode

• If HCI_UART RX  is NOT asserted, the ROM will assume all default configuration settings and then boot up into download mode

jakewtorres

Anonymous
Not applicable

Thanks for this clear explanation. Maybe I'm missing something though. On all reference designs there is no way to pull up UART_RX. After reset this is always pulled low by a 10k resistor.

Regards

Marco

0 Likes

Kits like WICED Sense were designed for demo purposes, so those need to come up in Application mode. If you want to program them, you need to crack the case and reset the device.

So per the TAG3 board schematic in the Hardware User Guide (SDK 2.x and TAG3 Board)​, you will notice that SW5 on the TAG Board applies VDDIO to the SDA pin on the EEPROM, preventing the device from reading the image stored in the EEPROM and forcing it into programming mode (insert this into the boot logic I provided earlier).

So with regards to I2C on boot, if VDDIO is present on SDA during boot up, then the firmware bypasses the step where it looks to the EEPROM for a valid image and goes directly into programming mode.

However, you will find comments in other posts which imply that you can also GND the SDA pin and see the same behavior.

This works as well and is probably a better choice since connecting SDA to Vdd/Vio to recover is probably not optimal for the following reason provided to me by one of the senior firmware engineers:

SCL and SDA are both open-drain configuration and the pull-ups pull the signal high while the HW drives it low (never drives high, but floats the output pad leaving the pull-up to pull the line high). If you put a scope to either of these lines on the board when the firmware accesses these, you will see that high to low transitions will be very sharp while low to high transitions will be pretty slow due to the intrinsic RC.

If you connect SCL/SDA to Vdd, then when the HW block drives SDA low, there will be a direct short (though momentary) between Vdd and GND, which is not ideal (even if the recovery works fine). This will happen pretty early during boot because the ROM always uses 0xA0 as the slave address of the EEPROM and you can see that there are repeated 0s in this sequence (and the shorts) which could do bad things to the supply or the chip.

So shorting to GND on the other hand is safer because that is what happens when there is a 0 bit on the bus and there is a 10K pull-up which will limit the current to something within the max ratings of all components on this line.

The forums are the only place where these things are documented.

jakewtorres

0 Likes
Anonymous
Not applicable

Hi, thanks for this answer. This clarifies everything.

Regards

Marco

0 Likes
Anonymous
Not applicable

Also is there some documentation describing these mechanisms clearly?

Regards

Marco

0 Likes