- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If I want to program a certain Bluetooth address into my device, is 20737_EEPROM.BTP the only file I need to modify? Do I only make modifications at these two lines?
DLConfigBD_ADDRBase = "FFFFFFFFFFFF"
DLConfigFixedBD_ADDRFlag = "Can change"
If the public address is 20:73:7A:13:5D:A6, do I just enter A65D137A7320 in the place of "FFFFFFFFFFF"?
What about the next line with the "Can change" field? What should it be changed to?
Sorry for these dummy questions I had to ask.
Thank you.
- Labels:
-
Manufacturing and Test
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think you will find section 7 of this document helpful: Programming the TAG2/TAG3 Board using command line tools
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried to use the command line to call Chipload.exe but got the following error message:
BluetoolDownloadMinidriver failed!
Here is my command line:
./ChipLoad.exe -BLUETOOLMODE -PORT COM24 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP ./20737_EEPROM.btp -CONFIG ./deviceFW.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251
I ran this in Cygwin and I put all the files in the same folder which is under C:/Cygwin64/home/. Please let me know what I did wrong.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
Are you using the SDK to produce the hex file or are you using cgs.exe?
Also were you able to download to the device using above command before you made any changes to the BTP file?
If not, I suggest you use this exact format with minor changes to the file names.
Remember you use -NODLMINDRIVER flag if device has never been programmed OR device is in recovery mode.
./chipload.exe –BLUETOOLMODE –BAUDRATE 115200nfc –PORT COM16 –MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex –CONFIG output.hex –NODLMINIDRIVER –BTP 20732_TAG32_EEPROM.btp
Also are you using your custom board? If yes, you should keep these points in mind.
minidriver - Loads the Hex file into EEPROM or SFLASH image.
- The MiniDriver uses P1 as the Write Protect Pin
- If you use a different pin for Write Protect, then the MiniDriver will NOT work.
- MiniDriver is specific to the P1 Write Protect Pin because it is driven LOW before Writing begins.
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi jamesle1
Thanks for your response.
Right now we are developing a product using your BCM20737S chip. In our schematic, Pin1 is floating. We use Pin27 to reset the chip and bring it to "programming mode".
The board I'm trying to program has been programmed before using the WICED IDE. Since using WICED IDE is not an efficient way in mass production, we are trying to learn how to call Chipload.exe in a command line to program the device. The "DeviceFW.hex" file is the firmware file I'm trying to write into the device. I renamed it in my post for convenience. The actual file name is xxxx-BCM920737TAG_Q32-rom-ram-Wiced-release.hex. "xxxx" is the product's name. I don't know how the software guys produced this hex file. I'm working on the manufacturing test for this product and it ended up that I'm the first one who's exploring how to call Chipload.exe to program the device.
If you are saying MINIDRIVER won't work in our case, how do we write into the EPROM with the firmware and the customized Bluetooth address, etc.? Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yliu
Have you tried this process on the TAG3 development board? I ask because the #1 problem customers run into on custom boards is getting the HCI_UART to come up in the correct mode (Programming); this is a common cause of Minidriver errors. If this works on the TAG3 board, you can at least eliminate syntax as an issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, I haven't. I don't have a TAG3 development board.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I just tried your command and it downloads fine.
I did get the same error: "BluetoolDownloadMinidriver failed!" when the COM port was incorrect.
So can you make sure you are using the right COM port?
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried it again and still got the same problem. Yes, I made sure the com port was correct (see the picture). I used a FTDI TTL-232RG-VREG3V3-WE cable and made connections to 3.3V, GND, HCI RX and HCI TX. There is a button switch between nMRST and GND.
Did you use the exact syntax of the command line as mine (except the com port# and the deviceFW.hex file)?
./ChipLoad.exe -BLUETOOLMODE -PORT COM24 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP ./20737_EEPROM.btp -CONFIG ./deviceFW.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. I used the exact syntax of the command line as yours using one of the TAG boards (except for the com port and the hex file).
Have you tried downloading the application using the SDK instead of command line?
I'm just guessing, but it might give error saying no device is being detected.
This could mean that the chip is not being able to communicate with the computer,
which probably means that your chip is not in the right mode or the connections are wrong/messed up.
(come to think about it, I actually used the same com port#. what a coincidence.)
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is COM 24 the only COM port opened?
Using the TAG boards, there are two COM ports that open up.
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using our development environment and the TAG3 (ask your developers if you can borrow; they would not have been able to create a program without it), there are two COM ports setup under windows once the FTDI USB to Serial driver is installed (Virtual COM Port Drivers ).
These are shown in the WICED Smart Quick Start Guide (SDK 2.x and TAG4 Board)
If programming a custom board from a PC, you will still need these drivers installed on the host.
If there is no USB to serial FTDI device on the custom design, then you will need to use the exact FTDI cable specified here on the forum (exact one as the voltage levels are tricky).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I used the exact FTDI cable specified in the forum: FTDI TTL-232RG-VREG3V3-WE. The driver was installed to PC without problem...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for confirming. Many do not.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like that's the only one (see the picture). To answer your previous question about using the SDK, no I've never programmed the device using the SDK. But I believe the software guys did. That's where I got the board from. So the reset pin works for programming without using P1?
I'll check the connections on the FTDI cable when I get a chance...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you get the TAG3 board from the SW guys? They had to use one to develop code for the device.
The minidriver will over-ride the strap settings of P1/WP. My guess is that the part is never going into programming mode.
Once you have the TAG3 board, it will be easy to compare the two and troubleshoot the process.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks. OK, I'll ask them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the software guys used the SDK to program the device before, then there probably isn't any issue with hardware.
You might want to confirm that before you check the actual hardware design.
For MINIDRIVER using P1, this is from the datasheet for 20737 SiP module:
P1 is the GPIO pin. On the actual module pin map, it is pin25, and it needs an external 10k pull-up.
Are you using 20737 SiP (SoC) module? Do you have external 10k pull-up on pin25?
[added]
If you are not using SoC and have external EEPROM, I believe you have to connect GPIO P1 to WP of the EEPROM and set VSS to GND.
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, we are using 20727 SiP module. Actually pin25 has an external 10k pull-up. Previously when you said P1, I thought it was Pin1. Sorry for the confusion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
xxxx-BCM920737TAG_Q32-rom-ram-Wiced-release.hex. This file is the factory image and includes the BD_ADDR already.
So if you are using this file, I don't think you can change the BD ADDRESS.
If you look at this Programming the TAG2/TAG3 Board using command line tools again,
there are at least two ways to change the BD ADDRESS:
1. change the btp file and use cgs.exe to produce a hex file that you want to write to EEPROM.
2. use the SDK and use a target name with specific BD ADDRESS to produce the hex file.
Changing the BD ADDRESS already happened before the software guys gave you the hex file.
So you wouldn't be able to change the BD ADDRESS if you already have the hex file.
As for as having PIN1 floating, I will talk to other engineers and get back to you.
The HCI UART is most likely not coming up in programming mode.
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Programming BCM20737S is working for me now. I mistakenly connected the RTS# wire from the FTDI cable to the nMRST pin of the BCM20737S chip and that was the problem.
Now, back to changing the Bluetooth address topic, I found that each time I reprogrammed the device using the same hex file in the command line, the Bluetooth address got changed (randomly). How do you explain this? Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
BD_ADDR: Changing BCM20737 Board Address for Production
There are multiple components which are leveraged during the creation of the hex file that eventually gets programmed into the device.
The EEPROM.btp file is one of those components.
There are several options:
- The user can edit Platforms/BCM920737ATAG_Q32/20737_EEPROM.btp file and set DLConfigBD_ADDRBase to the desired value.
- To use random address set DLConfigBD_ADDRBase = "20737A1*****" where every “*” will be replaced with a random value.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is the command line I ran to program my device:
ChipLoad.exe -BLUETOOLMODE -PORT COM24 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG test.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251
I ran it in the same folder with the same files. The public address of my device (showing when I used another BLE device to scan it) was changed:
from 20:73:7a:13:5d:a6 to
ec:5d:c8:4e:59:1e then to
E1:42:C8:4B:57:58
The first one came with the device from the software guys. The second and third one were from my programming the device. What did I do wrong?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ChipLoad.exe -BLUETOOLMODE -PORT COM24 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG test.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251
Open this file in Windows notepad.
Find the value "DLConfigBD_ADDRBase"
Does it look like this: DLConfigBD_ADDRBase = "20737A1*****"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, it looked like that exactly. Still I got this: ec:5d:c8:4e:59:1e
Then I changed it to
DLConfigBD_ADDRBase = "20737A135DA6"
and I got this: E1:42:C8:4B:57:58
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I didn't change the test.hex file at all.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Once you change DLConfigBD_ADDRBase to a fixed value in the BTP file, do you see the BD_ADDR changing to random values as noted previously?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes and that's what I meant by the following statement in my previous response:
Then I changed it to
DLConfigBD_ADDRBase = "20737A135DA6"
and I got this: E1:42:C8:4B:57:58
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
Are you still having a problem with changing the BD address?
If you are still having a problem, please read the following:
You mentioned that you are not changing the hex file when using ChipLoad.
If you don't change the hex file, I don't think you can change the BD address,
because hex file already has information about BD address.
(I'm not quite sure how you are observing changing addresses in your case...)
Below is an example of part of hex file: (notice how it has BD adress)
The following is a scan of advertisement from the device that has the above hex file.
You can see that it has the same BD address (with some permutations due to little-endian, I think).
If I am correct, the ChipLoad will not change the hex file, but it will only upload it to the chip's memory.
So changing BD address in the BTP file will not change the BD address when you are just using ChipLoad.
There are two easy ways to change the BD address.
Method 1. Using the SDK
If you are using the SDK, you can change the target name to have the BD address,
and then build it. After you build it, you can find the hex file in the build folder.
Use this hex file, which already has the same BD address as the one in the target name,
when using ChipLoad.
Method 2. Using cgs
If you look into the build folder, you can find the cgs file.
You can use this file to change the BD address.
Retrieve the cgs file, and change the BTP file with the wanted BD address.
Below is showing BTP file:
Then run cgs to create a hex file from the cgs file.
Then you can use Chipload to upload the resulting hex file to the chip.
You can see the BD address has changed.
You can find more details in this link:
Programming the TAG2/TAG3 Board using command line tools
I hope this will help you in changing BD address if you already haven't.
Please let us know if you have resolved your problem.
Thank you.
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi jamesle1
I'm trying to convert the .cgs file to a .hex file and here is the command I run:
At the end, it didn't say "...done....successful..."anything like that. The above shows all I got. In the folder where I ran the command (see below), nothing happened and I don't see any newly created or modified .hex file at all.
Can you tell me what's wrong? Thank you very much.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe you have used the incorrect CGS file. After compiling, you will have a folder of the name after your make target created under "WICED-Smart-SDK/build". Then you should use the CGS file in this folder. Something like this:
2) There are some details on this in another thread created by you:
Need to program a certain Bluetooth address into my device....(con't)
Let's continue the discussion in your new thread instead.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry I didn't know I created a new thread. I was replying the old thread and still don't know how the new thread was created.
Since you pointed out that I used the wrong .cgs file, I wanted to tell you that I tried the one you showed above too and got the same results. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I created the new thread because the old thread appeared to be answered and closed.
Community Admin.