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:
Note that there have also been similar problems reported when excessive I2C loading occurs: Re: BCM20737S recovery problems
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...
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?
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?
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.
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.
Good catch. There are alot of previously undocumented pitfalls associated with using external flash as compared to the internal EEPROM.
I think much of this came from the master SFLASH thread here: Re: Change BCW920737TAG from EEPROM to SFLASH failed
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...
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...
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?
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
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.
-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?
Yes, this is correct.