cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Contributor

Hi ,

I use the SDK to download my app, and it will download successful without error. But I try to use the chipload to download my app,and it download fail. I have already read the article about chipload(Programming the TAG2/TAG3 Board using command line tools and BD_ADDR: Changing BCM20737 Board Address for Production).

I do some experiment with chipload.

1. Use SDK to download hello_sensor, and then download my app with chipload. My app will download successful.

0.jpg

2. I modify the hello_sensor,and I increasing the space of RAM.

1.jpg

I use the SDK to  download the hello_sensor again, and then download my app with chipload. My app is download fail.

Here is my chipload log.

2.jpg

Here is my test configure and command:

SDK Version:2.2.2

CGS command: cgs.exe -I my_app.hex –A 0xFF000000 –B 20737_EEPROM.btp -D . my_app.cgs

chipload command: chipload.exe –BLUETOOLMODE –BAUDRATE 115200nfc –PORT COM7 –MINIDRIVER uart_64bytes_DISABLE_EEPROM_WP_PIN1.hex –CONFIG my_app.hex –NODLMINIDRIVER –BTP 20737_EEPROM.btp

3.jpg

I don't understand why the size of the RAM will affect the programming. Can anyone verify if I am doing something wrong here?Any help is appreciated.

Thank you.

Jack

0 Likes
Reply
1 Solution
Employee

Sorry for the late reply as I was on a business trip in the entire last week.

Let me be a little clear of my setup.

HW: Sense 1

SDK: v2.2.2

Below are my steps:

1) Reboot SENSE, using SDK: wiced_sense-BCM920737TAG_Q32 recover UART=COM63

2) Build and download SENSE app.

wiced_sense-BCM920737TAG_Q32 download BT_DEVICE_ADDRESS=7223A11874A8 UART=COM63

3) Build the glucosemeter

glucose_meter-BCM920736TAG_Q32 build

4) Extract the CGS file of the glucose meter to my chipload working folder

cgs.exe -I myGlucose.hex -O DLConfigFixedHeader:0 -A 0xFF000580 -B 20736_EEPROM.btp -D . A_20736A1-glucose_meter-rom-ram-spar.cgs

5) Perform a conversion of the CGS file to HEX format

6) Add another line (02000004FF00FB)

:02000004FF00FB

:02000004FF00FB

: .... ....

7) Chipload it onto my SENSE 1 kit

chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM63 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -NOERASE -CONFIG myGlucose.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20736_EEPROM.btp

😎 I used both LightBlue (free for download in App Store) and Wiced Sense, scan and found "BLE Glucosemeter" with "7223A11874A8" as the BD address.

Firstly, are you trying to achieve the above effect?

View solution in original post

28 Replies
Employee

You may have corrupted the EEPROM after your first download attempt. Do a recovery and download your app only.

0 Likes
Reply
Contributor

Hi boont,

Thanks for your comment.

You may have a corrupted EEPROM after your first attempt.

>If the EEPROM is corrupted after my first attempt, it will show error message when I use the SDK to download my app. I can use the SDK to download my app without any error. But I use the chipload to download my app, and it will terminated when it try to download the minidriver. It always terminated in the same address.

Do a recovery and try again.

>I already try it. I use the SDK to run recover mode, and I use the chipload to download my app again. It still not work.

make target: my_app-BCM920737TAG_Q32 download recover UART=COM13

1-1.jpg

If the app use of RAM more than 18KB,and the app will download fail with chipload.

Jack

0 Likes
Reply
Employee

We are investigating. At the mean time, you may want to check out this thread:

BCM20732 Memory Map Architecture

0 Likes
Reply
Moderator
Moderator

Jack,

I spoke to the apps team today about this issue and they wanted some level of clarification on the process you are using to extend the available memory.  Are you making modifications to the BTP file?

This is probably the best thread on the topic: https://community.broadcom.com/thread/2268

Or is this issue something all together different, and the issue related to the fact that the application is exhausting the free RAM that is available on the part (~27K)?

jakewtorres

0 Likes
Reply
Contributor

Hi mwf_mmfae,

Thanks for your response.

Are you making modifications to the BTP file?

>I didn't modify BTP file. My BTP of chipload is copy from the path(Platforms\BCM920737TAG_Q32). I only modify crystal warm up time(2800=>5000) in the mandatory.cgs.

I also upload my chipload data to the forum. Hope you can figure out where is the problem.

1.Use the SDK to upload the hello_sensor app.

2.Use the chipload to upload the hello_sensor.hex,and it will upload success.

3.Reset the chip and use the chipload upload the hello_sensor.hex again,and it will upload fail.

Jack,

0 Likes
Reply
Employee

Hi Jack,

Since the SDK is able to successfully download your app, but not the command prompt method, you should be able to get chipload working by emulating exactly what the SDK does.

In your make target in the SDK, add "VERBOSE=1". Begin the download. 

In the print out of the verbose download process you will find the exact cgs.exe arguments and the exact chipload.exe arguments that the SDK uses. If you emulate the exact procedure arguments that the SDK is using for your app, you should have no problem downloading using chipload.

Jacob

Contributor

Hi Jacob,

Thank for your advice.

I add "VERBOSE=1" to my make target in the SDK, and it download my firmware success. I performing a reset switch, and I download my firmware again. The result is also success. So I check the cgs and chipload command in the log, and I emulate the command that type to the cgs and chipload. The result is success.

cgs command: cgs.exe -I my_app.hex -O DLConfigBD_ADDRBase:207777123456 -A 0xFF000000 -B 20737_EEPROM.btp -D . my_app.cgs

chipload command:ChipLoad.exe -BLUETOOLMODE -PORT COM13 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG my_app.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 -LOGTO download.log

I use the above command can be executed. But I add "-NOERASE" to my chipload command,the download will be fail.

Here is the chipload command:

ChipLoad.exe -BLUETOOLMODE -PORT COM13 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG my_app.hex -CHECKCRC -NOERASE -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 -LOGTO download.log

Can you help me to figure out where is the problem?

Jack

0 Likes
Reply
Employee

In your CGS conversion, you have created a unique hex file with a unique bd addr. Therefore, in your chipload process, I will not insert the "-NOERASE" because I want to update the bdaddr. This command "-NOERASE" will actually perform a chip erase before downloading the new config data. I'm a little surprised that this could be the cause of your issue.

0 Likes
Reply
Contributor

Hi boont,

Thanks for you comment.

Our products will store some important parameters to NVRAM(VS section) in factory programming. But we may release new firmware version to our customers. We don't want erase the NVRAM because we have important parameters store in the NVRAM. So I tested the feature, and the customers will not erase the NVRAM when they perform firmware update process. Do you have any suggestions?

Jack

0 Likes
Reply
Employee

You can try something like below:

1) Generate a new HEX file based on the newer version of your app, but do not touch the first 40 bytes.

cgs.exe -I myNewVerApp.hex -O DLConfigFixedHeader:0 -A 0xFF000580 -B 20736_EEPROM.btp -D . A_20736A1-my_App-rom-ram-spar.cgs

2) Download it:

chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM13 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -NOERASE -CONFIG myNewVerApp.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20736_EEPROM.btp

Let me know if it helps.

0 Likes
Reply
Contributor

Hi boont,

I modify btp source in your cgs and chipload command(20736_EEPROM.btp => 20737_EEPROM.btp). I try to use the cgs tool to create the hex files with the hello_sensor.cgs, and it can create new hex files. But the download was fail when the chipload would like to download the firmware into first address(0xFF000580). I tested my app and hello_sensor cgs file, and it also crash in the same address(0xFF000580). But I remove the "-NOERASE" in the chipload command, and the chipload was download  success. I also found an interesting thing that the WP pin was keep low level("0") after download fail.Can you help me to figure out where is the problem?

My cgs file was copy from build/my_app. Is the cgs source correct?

4-1.jpg

Jack

0 Likes
Reply
Employee

Correct, the cgs file should be from the build/app folder after compiling.

Are you doing this on your own HW or tag3? I'm doing all the above on my tag3 by the way. And I was able to swap my applications (from hello_sensor to glucose monitor) without touching the BDaddr. Let's take a step back and try to figure this problem with the hello_sensor app first.

In whatever platform you are in, can you perform the following?

1) Do a recovery, using the proximity app.

2) Download the hello_sensor app, normally

3) Download again, with the change to the base address

Let us know what you get.

0 Likes
Reply
Contributor

Hi boont

Thanks for your suggestion.

Are you doing this on your own HW or tag3?

>I have use our hardware(BCM20737S) to do the test. I don't think our hardware has a bug because I can use the SDK to download my app without error.

I try your method in the tag3(BCM20737) and WICED SENSE TAG(BCM20737S) . I can download the glucose monitor successful when I use the tag3. But the WICED SENSE TAG has crash in same situation(download the firmware to first address - 0xFF000580).

Here is my work flow:

1.do the recovery in tag3 and WICED SENSE TAG

2.compiling the hello_sensor and glucose monitor in SDK

hello_sensor-BCM920737TAG_Q32 download

glucose_meter-BCM920737TAG_Q32 download

3.create hex file

cgs.exe -I hello_sensor.hex -O DLConfigBD_ADDRBase:207777123456 -A 0xFF000000 -B 20737_EEPROM.btp -D . hello_sensor.cgs

cgs.exe -I glucose_meter.hex -O DLConfigFixedHeader:0 -A 0xFF000580 -B 20737_EEPROM.btp -D . glucose_meter.cgs

4.download the hello_sensor firmware to tag3 and WICED SENSE TAG. Both of EVBs are download successful.

ChipLoad.exe -BLUETOOLMODE -PORT COM17 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG hello_sensor.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251

5.press the reset button in tag3 and WICED SENSE TAG, and download the app again.

chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM17 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -NOERASE -CONFIG glucose_meter.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20737_EEPROM.btp

The WICED SENSE TAG and my customized PCB are meet same situation. Can you check my work flow and command correct?

Jack

0 Likes
Reply
Employee

Hi Jack,

I've tried your below method on a TAG4 and a WICED Sense and I am seeing the same error as yours during downloading on both devices, with -NOERASE on step #5. With the -NOERASE option removed it does download correctly.

>Download config error trying to write 64 bytes to address 0xFF000580

1.do the recovery in tag3 and WICED SENSE TAG

2.compiling the hello_sensor and glucose monitor in SDK

hello_sensor-BCM920737TAG_Q32 download

glucose_meter-BCM920737TAG_Q32 download

3.create hex file

cgs.exe -I hello_sensor.hex -O DLConfigBD_ADDRBase:207777123456 -A 0xFF000000 -B 20737_EEPROM.btp -D .hello_sensor.cgs

cgs.exe -I glucose_meter.hex -O DLConfigFixedHeader:0 -A 0xFF000580 -B 20737_EEPROM.btp -D . glucose_meter.cgs

4.download the hello_sensor firmware to tag3 and WICED SENSE TAG. Both of EVBs are download successful.

ChipLoad.exe -BLUETOOLMODE -PORT COM17 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG hello_sensor.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251

5.press the reset button in tag3 and WICED SENSE TAG, and download the app again.

chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM17 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -NOERASE -CONFIG glucose_meter.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20737_EEPROM.btp

Let me get in touch with the developer of chipload and see where the error might be coming from.

boont, could you possibly try WICED Sense from your side?

Thanks,

Jaeyoung

0 Likes
Reply
Employee

Hello Jack,

-NOERASE means that a CHIP ERASE command to erase the entire memory is not sent to the minidriver, and so the EEPROM is not erased.

Still, when a specific serial flash page is being written to for the first time, the minidriver will attempt to perform a SECTOR ERASE for a single page. For some hardware it seems this command is not working properly maybe due to some HW settings. We will look into this issue further, but it might take a while as the engineers who have knowledge on this are on vacation.

In the meanwhile, if you wish to retain the parameter information in your NVRAM while performing an application upgrade, you could use OTA as this would not erase the NVRAM VS area. Please refer to following discussion for details.

WICED Smart BCM92073X EEPROM and SFLASH Layout

WICED Smart BCM92073X OTA Firmware Upgrade (1)

WICED Smart BCM92073X OTA Firmware Upgrade (2)

Thanks,

Jaeyoung

0 Likes
Reply
Contributor

Hi Jaeyoung,

Thanks for your comment.

I have already porting secure OTA to my app, and the VS will not be erase in the EEPROM when I use  the OTA to upgrade my frimware. But some user may not have Bluetooth dongle or smart phone, so our product still need to support for uploading firmware by UART.

I will waiting for your response. Thank you.

Jack

0 Likes
Reply
Employee

I confirm that I too see the download issue on the sense tag. We are investigating.

0 Likes
Reply
Contributor

Hi jaeyoung & boont,

Any update?

Jack

0 Likes
Reply
Employee

We need more time to look at this as you know we are in the midst of integration into a new company.

Contributor

Hi,

Can someone help me solve the problem?

Any help is appreciated.

Jack

0 Likes
Reply
Employee

Can I suggest an unusual method? After conversion, you hex file may look something like this:

:02000004FF00FB

:FB05800018010000A21A006C300 ... ... ...

:FB067B00044 ... ... ...

Now, repeat another time for the top line, and it should look like this:

:02000004FF00FB

:02000004FF00FB

:FB05800018010000A21A006C300 ... ... ...

:FB067B00044 ... ... ...

This method allows me to retain my BD address yet change my application, using the chipload method. Below is my commands:

cgs.exe -I mySense.hex -O DLConfigFixedHeader:0 -A 0xFF000580 -B 20737_EEPROM.btp -D . A_20737A1-wiced_sense-rom-ram-spar.cgs

chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM25 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -NOERASE -CONFIG mySense.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20737_EEPROM.btp

In the SDK, I use the following make target to build my application:

wiced_sense-BCM920737TAG_Q32 build

Contributor

Hi boont,

Thanks for your suggestion.

I have test your method with BCM20737S(our own Hardware & wiced sense tag 1). I change the hex file just like you say(second download). But it still crash in the same address(Download config error trying to write 64 bytes to address 0xFF000580). I also find the GPIO:P1(WP pin) in low level after download fail. I try -NOERASE command work in the tag3(BCM20737), but it will crash in the wiced sense tag(BCM20737S). The EEPROM isn't the same in BCM20737 and BCM20737S. So the problem may be in EEPORM?? Any idea?

Are you doing this on your own Wiced sense tag or tag3?

Dose the SDK support command to disabled the erase NVRAM(like command "-NOERASE" in chipload)?

Jack

0 Likes
Reply
Contributor

Hi Cypress FAE,

This issue still exists, and I can't find the way to solve the problem. My step and Chipload command are correct, but it always crash in the 0xFF000580. Why the Chipload will fail with "-NOERASE" command in BCM20737S? But the "-NOERASE" command can work in the BCM20737. Our products are designed with the BCM20737S. So I must be found the problem. Can you help me figure out the problem? Did it has solution to solve the issue? Or the issue can't be solve? Thanks for your reply.

Jack,

0 Likes
Reply
Employee

Sorry for the late reply as I was on a business trip in the entire last week.

Let me be a little clear of my setup.

HW: Sense 1

SDK: v2.2.2

Below are my steps:

1) Reboot SENSE, using SDK: wiced_sense-BCM920737TAG_Q32 recover UART=COM63

2) Build and download SENSE app.

wiced_sense-BCM920737TAG_Q32 download BT_DEVICE_ADDRESS=7223A11874A8 UART=COM63

3) Build the glucosemeter

glucose_meter-BCM920736TAG_Q32 build

4) Extract the CGS file of the glucose meter to my chipload working folder

cgs.exe -I myGlucose.hex -O DLConfigFixedHeader:0 -A 0xFF000580 -B 20736_EEPROM.btp -D . A_20736A1-glucose_meter-rom-ram-spar.cgs

5) Perform a conversion of the CGS file to HEX format

6) Add another line (02000004FF00FB)

:02000004FF00FB

:02000004FF00FB

: .... ....

7) Chipload it onto my SENSE 1 kit

chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM63 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -NOERASE -CONFIG myGlucose.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20736_EEPROM.btp

😎 I used both LightBlue (free for download in App Store) and Wiced Sense, scan and found "BLE Glucosemeter" with "7223A11874A8" as the BD address.

Firstly, are you trying to achieve the above effect?

View solution in original post

Contributor

Hi boont,

1.Firstly, are you trying to achieve the above effect?

>Yes.

2.Thanks for your comment.I have use your method in 4 different computers. One is W7 64bit, another is W10 32 bit, and the others are W10 64 bit. The method can work in W7 64bit and W10 32bit. But it can't work in W10 64bit.  Could you help me find the problem? Thanks for your reply.

3. I would like to clarify one thing. Did the step1(run recovery mode in sense1) was necessary? Or the step1 is ensure the NVRAM isn't corrupt?

Jack

0 Likes
Reply
Employee

2) I saw some folks in this forum reporting various issues concerning W10 and you can do a search to see them. I am using win7/32-bit though.

3) Not necessary. I did it only to convince myself that the eeprom is OK and everything is under control.

0 Likes
Reply
Contributor

Hi boont,

Most of topic is talking about SDK work in the W10 and run Chipload in other OS(e.g. MAC or linux). The thread is closer my issue, but it was unable to clarify my question(Does Win32 Chipload.exe work on Win64 laptop?). I don't know which Windows version was lucyli used in her test. I can work Chipload in W10 32bit, but it will crash in W10 64bit. But lucyli say that can work in the 64 bit Windows OS. I also compared the 4 hex files(1 W7-64, 1 W10-32 and 2 W10-64). The hex files are same that create from each OS.  So I can confirm that the problem is in the Chipload. But I can't think what is the problem. Could you give me some suggestion? Thanks for your advice.

Jack,

0 Likes
Reply
Employee

Lucy Li is likely to use Win 7 because that is the default OS the company issues for its laptops.

My advice is to go with the system that works for you, eg win7-64. The current issue will get resolve in future releases but if you have a production schedule to meet, then don't wait.