cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

Hey guys,

I want to program my custom board with a BCM20736S-Controller on it. But everytime I want to download the program I get either the error:

Download failed - Press the reset button on the device and retry

when I add to the make target of the hello_sensor program: BT_DEVICE_ADDRESS=20736S100331 PLATFORM_NV=SFLASH UART=15

or the error:

Download failed. This version of the SDK only supports download to BCM20736A1 and BCM20737A1 devices

when I make no changes in the make target.

I searched in the forum and found some tricks to fix this problem like adding

JOBS=1

VERBOSE=1

to the makefile, but these changes had no effect. What else can I do to fix the problem? Or have I missed something?

0 Likes
Reply
1 Solution
Anonymous
Not applicable

You have to have access to the SDA pin to do recovery.

You will need to modify your design. Floating SDA is not the way to go.

It has been recommended that SDA be connected to ground instead of vcc when powering on for Recovery - safer for the chip.

I have found the recovery to be more sensitive to variations in the USB cable.  Some of the cables we built cannot perform recovery successfully.

Keep the cable short, I have not been able to recover with a cable longer than about 9 inches.  Keep any solder connections "nice".  Do NOT use a breadboard for this.  I was not able to recover until I ditched the breadboard and made a short straight cable from the USB to the module.

Steps:

1. power off board (e.g. disconnect USB cable from PC)

2. connect SDA to ground

3. Power up board while SDA is grounded

4. Wait a couple or three second

5. Disconnect SDA from ground

6. Double click the Recover target in the SDA.

This works for me.  We use a FTDI USB to RS-232 3.3 volt cable.  It has LED's in the USB connector and you can see them flicker when the download/recovery is in progress.

View solution in original post

0 Likes
Reply
32 Replies
Moderator
Moderator

This is a common error which simply means that the SDK/Minidriver that programs the part over the HCI using a proprietary protocol is not receiving a response from the HCI UART.  This could be SW or HW.

Recall this discussion: How do I program a BCM20736? There are quite a few things that need to be in place for this process to work.

Which FTDI USB to Serial Cable are you using?  Here, I ask because many have struggled with this process while using the wrong cable.  You will need the 3.3V version per the thread here: Re: Information: Programming your BCM20732S-based board from an onboard UART header

Also, how is the HCI_RX line being handled?This line needs to be pulled high to put the part into programming mode:

Re: Programming the BCM20736S on a custom PCB

Note that there have also been similar problems reported when excessive I2C loading occurs: Re: BCM20737S recovery problems

and here: Re: problem when programming custom board with BCM20737S

jose.raffucci ehoffman gmelcer fourniala yves.godin jcardona vik86

0 Likes
Reply
Anonymous
Not applicable

I'm using the TTL232R 3V3 cable from FTDI for the programming.

While powering up the board via USB up the RX-Pin is pulled up via a 1 kOhm resistor. After reseting the controller I release the resistor to program. I removed the -NODLMINIDRIVER from the makefile, but still it is not working...

0 Likes
Reply
Anonymous
Not applicable

In the Project Explorer can you open the build subfolder and navigate to your project build and open the download.log file?  Do you see anything of interest there?  or is it one line of download failed...

When you edit your make target I think it has to start with some very specific format...

for example mine appears as follows:

heart_rate_monitor-BCM920736TAG_Q32 download UART=COM13

the first part "heart_rate_monitor" has to match the name of my App folder.

The second part BCM920736TAG_Q3 has to be in this format or it will say something like device not supported.

The UART=COMxx is optional if you have configured the COMxx in the SDK setup.

Can you double check that your make target is in this format?

Eric

0 Likes
Reply
Anonymous
Not applicable

My make target is built up like yours.

In the project explorer is actually something of interest. The cgs-file can't be converted to the hex-file. What could be the reason?

0 Likes
Reply
Anonymous
Not applicable

I have not run into that error yet.  I did discover that the make file is delicate and an accidental character inserted at the wrong place caused me a great deal of grief and was difficult to isolate because the error message sent me off in other directions.  If I were you, and if you have edited the makefile (which I think you might have mentioned above), review your edits and diff with the original to ensure no accidental insertion or deletion was made.  Also turning on VERBOSE will not affect your build but may give additional information as to where things went wrong.  I just noticed that in your original post you show UART=15.  I think you meant UART=COM15.  If you left out the COM that might cause trouble.

Hope this helps.

Eric

0 Likes
Reply
Moderator
Moderator

Thanks for the help Eric.

Note that phill.giancarlo is also having problems converting the CGS file into Hex under a similar scenario: Creating HEX File with CGS for 20736S

0 Likes
Reply
Anonymous
Not applicable

Also I am not using the FLASH option, so I don't know what pitfalls might be lurking in that area.... but I think there are a number of threads that deal with issues programming with FLASH.   Are you sure you are using the module (736S) and not the Chip version of the 726?

One thing that comes to mind... I remember getting this error for multiple reasons, but one time when I saw

"This version of the SDK only supports download to BCM20736A1 and BCM20737A1 devices"

I think the reason turned out to be that I had made a copy of my build target, and the copy, by default, started with the words "Copy of heart_rate_monitor" instead of just "heart_rate_monitor"  when I edited the name to take out "Copy of" it built successfully.  Not sure now.. maybe the error message was more like "No such make target".  Another way I got that error wasy by making a typographical error in my "BCM920736TAG_Q32" platform name in the build command.

0 Likes
Reply
Moderator
Moderator

Good catch. There are alot of previously undocumented pitfalls associated with using external flash as compared to the internal EEPROM.

j.t has attempted to catch them in the blog he published here just yesterday: TAG3 Serial Flash Configuration

I think much of this came from the master SFLASH thread here:  Re: Change BCW920737TAG from EEPROM to SFLASH failed

0 Likes
Reply
Anonymous
Not applicable

If I understand it in the right way phill.giancarlo is using the command line in the thread Creating HEX File with CGS for 20736S. Is this the only way I can program my custom board with a SDK-example?

Because when I try to download my code (I changed the hello_sensor-program) to the development kit I have no problems. The cgs-file gets converted to the hex-file and the controller gets found. But when I swap the controllers and try to download the code to my own board by using the make file it fails. And it makes no difference when I use the EEPROM or the FLASH...

0 Likes
Reply
Anonymous
Not applicable

I just realized that the conversion of the cgs to the hex-file always fails. So, when I'm programming the developmet kit the same failure occures. But the application gets downloaded anyway and it runs in the right order. That confuses me much more...

0 Likes
Reply
Moderator
Moderator

Does the conversion of the CGS to HEX always fail, or only when you program your custom program onto your custom board?

My thinking is let's figure out what works and try to work back from there.

You can program one of the included SDK apps (no changes to the make file) onto your custom board with no problems correct?

0 Likes
Reply
Anonymous
Not applicable

When I remove the changes I made in the make file the cgs converts to the hex file but the download fails:

Download failed - Press the reset button on the device and retry

0 Likes
Reply
Moderator
Moderator

So both with and without changes to the makefile, the download from your PC running SDK 2.2, using the recommended 3.3V FTDI USB to Serial cable to your custom board (using BCM20736S) fails (different error messages each time), both when using EEPROM and SFLASH.

Other notes:

-While powering up the board via USB, the HCI UART RX Pin is pulled up via a 1 kOhm resistor

-There is nothing on the I2C bus which could be casing a loading problem and forcing the part into recovery mode

-When programming the same program to the TAG3 development board, it works fine

Is all of this correct?

0 Likes
Reply
Anonymous
Not applicable

Yes, this is correct.

0 Likes
Reply
Moderator
Moderator

Have you been able to successfully program any of the default vanilla programs from the SDK onto your custom board using the EEPROM on the SIP module, not the external serial flash? Have you tried disabling peripherals on your board (i.e. create a basic configuration that resembles the TAG3 development board)?

0 Likes
Reply
Employee

I see two issues with make target string:

- If this is a 20736S module, there is an I2C EEPROM in the module and the app should always be downloaded to this. So you don't need PLATFORM_NV=SFLASH which is only when you have an SPI serial flash for NV storage (which is not possible with the S module).

- UART=15 is incorrect. Did you mean UART=COM15 ?

Since this board has never been programmed before, have you tried recovery steps? For hello sensor, assuming the device is on COM15, this would be my make target string:

hello_sensor-BCM920736TAG_Q32 UART=COM15 recover

0 Likes
Reply
Anonymous
Not applicable

Until now I haven't programmed any code to my custom board. I guess the main problem is that the controller can't be detected. Neither by programming via the EEPROM nor via the serial flash.

I wrote UART=COM15 to the make file. UART=15 was a spelling mistake...

Recovery steps fail, too: Recovery failed - retry

0 Likes
Reply
Anonymous
Not applicable

After trying out some of the suggestions I finally got access to my custom chip. But only twice... After that I get the same messages as before. "No BCM20736 detected" or "Download failed". What could be the reason why it worked twice and then suddenly without changing anything it doesn't work anymore?

0 Likes
Reply
Anonymous
Not applicable

Hello Andre,

Have you tried the Recovery Procedure: WICED Smart Quick Start Guide (SDK 2.x and TAG3 Board)

Please see page 26:

pastedImage_2.png

Note: An empty EEPROM/SF should always be recovered

Thanks

JT

0 Likes
Reply
Anonymous
Not applicable

No, not on my custom board.

But I have only a reset button and no BOOT ROM button on it. Does it work in the same way just without using the BOOT ROM button?

0 Likes
Reply
Anonymous
Not applicable

Andre,

To recover, we use both the BOOT ROM and reset buttons.

Thanks.

0 Likes
Reply
Anonymous
Not applicable

And what else can I try when I have no BOOT ROM button? The strange thing is, that I was able to download my program twice but after making some changes in the code it didn't work anymore. Neither after removing the changes in the code...

0 Likes
Reply
Employee

On the eeprom, short SDA and Vcc with a pincer while doing a power reset. Not sure it helps here...

0 Likes
Reply
Anonymous
Not applicable

The SDA/SCL pins are floating on my board, so it is not possible to me to short SDA and Vcc.

I only use pins 18 (UART_RX) and 19 (UART_TX) on the controller. P0 and Reset are high. The controller is supplied by the USB-Converter TTL232R 3V3. Normally that should be enough to program the chip, or do I need more pins so the controller can be detected?

0 Likes
Reply
Anonymous
Not applicable

sorry, I meant P1 is high...

0 Likes
Reply
Anonymous
Not applicable

In the download.log file I found the following line:

BluetoolDownloadMinidriver failed!

I guess that this is the reason why the download fails... How can I accomplish to download the minidriver?

0 Likes
Reply
Anonymous
Not applicable

Hello Andre,

Can you send us your download.log file?

Thanks

JT

0 Likes
Reply
Anonymous
Not applicable

Hello JT,

In the download.log file is only one line which says:

BluetoolDownloadMinidriver failed!

That's all, nothing else is written there...

0 Likes
Reply
Moderator
Moderator

The minidriver is the brains of the download process (contains the protocol used to talk to the BLE device) as it exists within the SDK as hex code and is uploaded to your board during the programming process.

Specifically, the SDK triggers the process which downloads the minidriver to RAM (on your board) and then runs it.  The SDK then pushes the code over the HCI uart to the minidriver, which will then write to EEPROM.

I believe the message you described just means that the HCI UART on your board is not responding.

vik86

0 Likes
Reply
Anonymous
Not applicable

And what could be the reason? Because I can measure High and Low level on TXD and RXD when I release the pull up for RXD and only supply the board with 3,3 V.

0 Likes
Reply
Moderator
Moderator

bachelor2015, please respond to vik86 and let him know if you would like to take him up on his offer.

0 Likes
Reply
Anonymous
Not applicable

You have to have access to the SDA pin to do recovery.

You will need to modify your design. Floating SDA is not the way to go.

It has been recommended that SDA be connected to ground instead of vcc when powering on for Recovery - safer for the chip.

I have found the recovery to be more sensitive to variations in the USB cable.  Some of the cables we built cannot perform recovery successfully.

Keep the cable short, I have not been able to recover with a cable longer than about 9 inches.  Keep any solder connections "nice".  Do NOT use a breadboard for this.  I was not able to recover until I ditched the breadboard and made a short straight cable from the USB to the module.

Steps:

1. power off board (e.g. disconnect USB cable from PC)

2. connect SDA to ground

3. Power up board while SDA is grounded

4. Wait a couple or three second

5. Disconnect SDA from ground

6. Double click the Recover target in the SDA.

This works for me.  We use a FTDI USB to RS-232 3.3 volt cable.  It has LED's in the USB connector and you can see them flicker when the download/recovery is in progress.

View solution in original post

0 Likes
Reply