I can't do recovery at this time here. I get an error that HCI_RESET could not be executed.
Would recovery help my guys in China be able to program without overwriting the MAC address? I put those two options in the Makefile I posted above, I wonder why it still overwrites the MAC address?
Can I check with you the following:
1) Are you using a flash or eeprom?
2) How did you download your apps onto the storage? by tag3 or a customized jig?
In parallel, are your China colleagues being currently supported by any Broadcom reps in their area?
1) We are using the BCM29736 part from Broadcom, as I understand it, we are using the EEPROM on this part.
2) We use an FTDI board and cable to upload the firmware. It works fine to update the firmware.
3) We are not currently being supported by the Broadcom reps in China. Could you please put us in touch with the Shenzhen China reps and any reps in the Silicon Valley?
I do not have the right asset in ShenZhen right now. All the information related to downloading during production are documented in the below blog. I can only advise you to test out the downloading process on tag3 before migrating to your actual HW.
Who is supplying you the 20736?
We are following the instructions found in BD_ADDR: Changing BCM20737 Board Address for Production
However, we are running into the problem described here:
Could you please have a look?
Can you furnish me a name, email and contact number of your Chinese colleague?
I'm having issues with using these cgs and chipload options myself.
Starting with the .RAR archive posted to the blog on changing BD_ADDRs, I modified the batch file to use the following commands (with the intention of not over-writing the BD_ADDR stored in the EEPROM):
cgs.exe -D . -O DLConfigFixedHeader:0 -A 0xFF000000 -B 20737_EEPROM.btp -I output.hex --cgs-files A_20736A1-hello_sensor-rom-ram-spar.cgs
Chipload.exe -BLUETOOLMODE -PORT %1 -BAUDRATE 115200 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -BTP 20737_EEPROM.btp -CONFIG output.hex -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 -NOERASE
Chipload successfully downloads the minidriver but after that it doesn't appear to actually program anything. The process happens very quickly, unlike the standard script where Chipload takes several seconds to download the new code. Here's the console output:
Note: I'm using a WICED Sense device for my hardware (BCM20737S SIP).
Thanks Ethan for the email. Actually I was hoping that someone could actually look at your HW in ShenZhen but your colleague is with you now in US. At the mean time, Andrew is still your best bet in your time zone.
I am going to migrate to the new SDK version and verify some of the process described in here.
Please add -LOGTO chipload.log to your call to chipload.exe and try again. This will produce a more detailed log in chipload.log that you can attach to this discussion. You can also try to use Portmon to monitor data in either direction over the COM port you are using for the download.
I worked on the tag3 and have no issue with the following:
1) cgs.exe -I mysensor.hex -A 0xFF000000 -B 20737_EEPROM.btp -D . A_20736A1-hello_sensor-rom-ram-spar.cgs
2) chipload.exe -BLUETOOLMODE -BAUDRATE 115200nfc -PORT COM13 -MINIDRIVER uart_DISABLE_EEPROM_WP_PIN1.hex -CONFIG mysensor.hex -DLMINIDRIVERCHUNKSIZE 251 -BTP 20737_EEPROM.btp -LOGTO chipload.log