- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
I keep getting
Detecting device...
Device found
Downloading application...
****Download failed - Press the reset button on the device and retry ****
18:37:10 Build Finished (took 3s.111ms)
When trying to program our module on our custom board. Have you seen this before?
Thanks!
Ethan
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good idea. Start with downloading to TAG (not custom board), and download a clean - unmodified version of a simple App, like Hello Sensor or Proximity App, or some such. If you can get this to work, then move forward to next step.
If you have added a lot of code or large memory buffers, it is possible to corrupt the module every time it runs.. in this case Recovery will run successfully and the App will run one time (or maybe start to run and die).. and then the next download will fail. I have seen this and solved the problem by reducing the size of a memory buffer that I had allocated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are a number of reasons, both HW and SW, as to why a download process can fail. The below thread offers some insights into these issues.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is a common issue on custom boards.
Assuming you are using the SIP module and the onboard EEPROM for NVRAM and that your custom program runs fine on the TAG3 development board, make sure you check the following:
1.
HCI_RX is high so the part goes into programming mode: Re: Programming the BCM20736S on a custom PCB
2.
Another thing to check is I2C loading per the post here on Feb 28, 2015 8:28 PM: Re: BCM20737S recovery problems
3.
Make sure you are using the correct FTDI USB to serial cable: Re: BCM20736S recovery problem - SDA high does not enter recovery mode
4.
Make sure you are using the GPIO corectly, especially the dual bonded pins noted here: BCM2073XS GPIO Basics
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just checked my download.log and I see
ERROR! Unrecognized command-line argument BLUETOOLMODE
However it describes that as an option:
Tools\ChipLoad\Win32\ChipLoad.exe -BLUETOOLMODE [-BAUDRATE nnnn] [-MINIDRIVER minidriverfile] [-CONFIG configdatafile] [-FIRMWARE firmwarefile] [-BTP btpfilename] [-NODLMINIDRIVER] [-LOGTO optionallogfile] [-DLMINIDRIVERCHUNKSIZE bytesize] [more options]
where
Looks like I am calling BLUETOOLMODE twice
download_using_chipload:
$(QUIET)$(ECHO_BLANK_LINE)
$(QUIET)$(eval UART:=$(shell $(CAT) < com_port.txt))
$(QUIET)$(if $(UART), \
$(ECHO) Downloading application... && $(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -NOERASE -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 \
&& $(ECHO) Download complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) \
|| $(ECHO) $(QUOTES_FOR_ECHO)****Download failed - Press the reset button on the device and retry ****$(QUOTES_FOR_ECHO), \
$(ECHO) Download failed. This version of the SDK only supports download to BCM20736A1 and BCM20737A1 devices)
recover_using_chipload:
$(QUIET)$(ECHO_BLANK_LINE)
$(QUIET)$(ECHO) Recovering platform ...
$(QUIET)$(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -NODLMINIDRIVER -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -LOGTO build/$(OUTPUT_NAME)/$(OUTPUT_NAME).log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 && $(ECHO) Recovery complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) || $(ECHO) $(QUOTES_FOR_ECHO)**** Recovery failed - retry ****$(QUOTES_FOR_ECHO)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I restarted the IDE and rebuilt. Still get a download failed but now the download.log says
BluetoolDownloadMinidriver failed!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like I was able to recover the platform by making a new recovery target
Recovering platform ...
Recovery complete
Application running
12:26:57 Build Finished (took 9s.71ms)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I still can't program it regularly even though recovering seems to consistently work. Here are my recovery settings:
$(QUIET)$(call CONV_SLASHES,$(CHIPLOAD_FULL_NAME)) -BLUETOOLMODE -PORT $(UART) -BAUDRATE $(PLATFORM_BAUDRATE) -NODLMINIDRIVER -MINIDRIVER $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_MINIDRIVER) -BTP $(SOURCE_ROOT)Platforms/$(PLATFORM_FULL)/$(PLATFORM_BOOTP) -CONFIG build/$(OUTPUT_NAME)/$(OUTPUT_NAME).hex -LOGTO build/$(OUTPUT_NAME)/$(OUTPUT_NAME).log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/$(OUTPUT_NAME)/download.log 2>&1 && $(ECHO) Recovery complete && $(ECHO_BLANK_LINE) && $(ECHO) $(QUOTES_FOR_ECHO)Application running$(QUOTES_FOR_ECHO) || $(ECHO) $(QUOTES_FOR_ECHO)**** Recovery failed - retry ****$(QUOTES_FOR_ECHO) |
It looks like there is some option for -NODLMINIDRIVER that is not present in the other download settings. Is there a reason why recovery seems to succeed but download does not?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We will run this past the developers during our meeting tomorrow and see if they can provide some guidance.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Ethan,
The -NODLMINIDRIVER should be included ONLY in recover mode.
Remove this when in program mode.
Thanks
JT
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi JT,
Can you explain a bit more about the purpose of the MINIDRIVER?
I keep getting the error
BluetoolDownloadMinidriver failed!
When I try to do a download to the device outside of Recovery Mode.
I want to know why I keep getting this error and what the ramifications of it are. Can I get away with not using the Minidriver and just programming my boards all in Recovery Mode?
My ultimate goal is to program firmware onto my production devices WITHOUT overwriting the MAC address which is already serialized on the parts
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When programming either with the SDK or using the command line tools, the part downloads the minidriver to RAM then the SDK/Command Line Tools push the code you are programming over the HCI uart to the minidriver which will then write it to EEPROM. Think of the minidriver as the programming protocol brains that handles all of the memory mapping, writing and verification of your program for you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
My questions are:
1) Why do I keep getting "BluetoolDownloadMinidriver failed!" in download mode
2) If the Minidriver is needed to write to EEPROM, how am I able to load a recovery image onto my board without using the Minidriver option?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1.
Not sure. That is the message you generally receive when the HCI_UART is not in programming mode or cannot be contacted by the minidriver. If you look through the forums, many users struggle with this when bringing up their custom boards.
2.
I checked with the developers and they said that the minidriver is still downloaded with –NOMINIDRIVER. It just disables sending a command before the download because the command does not work in recovery mode.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So if the board updates in when I do a recovery, but not when I do a regular download, it's probably doubtful the real reason is the HCI_UART is not in programming mode. Otherwise it wouldn't be able to update using recovery right?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
May I suggest that we take a step back and do this downloading on a well-behaved platform like the tag3? Let's try to establish a consistent download on the tag3, then we can try to duplicate it on your customized board.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good idea. Start with downloading to TAG (not custom board), and download a clean - unmodified version of a simple App, like Hello Sensor or Proximity App, or some such. If you can get this to work, then move forward to next step.
If you have added a lot of code or large memory buffers, it is possible to corrupt the module every time it runs.. in this case Recovery will run successfully and the App will run one time (or maybe start to run and die).. and then the next download will fail. I have seen this and solved the problem by reducing the size of a memory buffer that I had allocated.