More details on this...
It appears that our boards cannot complete a recovery procedure, even the good (unbricked) ones. Or at least this is the conclusion we arrived to based on the following observations:
1. Both a good board as well as a bricked board report **** Recovery failed - retry ****. After a failed recovery, the good board continues to be programmable, while the bricked board does not.
2. The logs show that the hardware responds in the same way for both the good and the bricked boards:
22:16:57.058 Will be downloading 0 bytes of code and 4931 bytes of data using minidriver Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex 22:16:57.058 BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp 22:16:57.058 The config data is coming from the following files 22:16:57.058 build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.hex 22:16:57.058 Sending bytes to HW: 4 bytes: 01 03 0C 00 22:16:57.062 Received bytes from HW: 7 bytes: 04 0E 04 01 03 0C 00 22:16:57.062 Sending bytes to HW: 259 bytes: 01 4C FC FF 00 10 20 00 10 B5 81 B0 73 48 00 F0 E3 F8 00 23 72 49 0B 60 72 49 0B 60 00 F0 EF FB ... 22:16:57.087 Received bytes from HW: 7 bytes: 04 1C 08 04 30 F0 00 22:16:57.091 Received bytes from HW: 7 bytes: 04 1C 08 04 30 F0 00 (...) 22:16:57.577 ERROR: Download minidriver error trying to write 251 bytes to address 0x00201000
3. Even though the ChipLoad is invoked with the -NODLMINIDRIVER option, ChipLoad seems to try to download the minidriver.
Tools/ChipLoad/Linux64/ChipLoad -BLUETOOLMODE -PORT /dev/ttyUSB0 -BAUDRATE 115200 -NODLMINIDRIVER -MINIDRIVER Platforms/BCM920736TAG_Q32/uart_DISABLE_EEPROM_WP_PIN1.hex -BTP Platforms/BCM920736TAG_Q32/20736_EEPROM.btp -CONFIG build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.hex -LOGTO build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.log -CHECKCRC -NOVERIFY -DLMINIDRIVERCHUNKSIZE 251 > build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/download.log 2>&1 && "Tools/common/Linux64/echo" Recovery complete && "Tools/common/Linux64/echo" && "Tools/common/Linux64/echo" "Application running" || "Tools/common/Linux64/echo" "**** Recovery failed - retry ****" **** Recovery failed - retry ****
4. After removing the -MINIDRIVER option from the chipload arguments, chiploads honors the NODLMINIDRIVER argument but the recovery still fails, with a different error:
22:31:42.061 Will be downloading 0 bytes of code and 4931 bytes of data without a minidriver 22:31:42.061 BTP file: Platforms/BCM920736TAG_Q32/20736_EEPROM.btp 22:31:42.061 The config data is coming from the following files 22:31:42.061 build/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release/proximity-BCM920736TAG_Q32-rom-ram-Wiced-release.hex 22:31:42.062 Sending bytes to HW: 4 bytes: 01 03 0C 00 22:31:42.066 Received bytes from HW: 8 bytes: 04 1C 08 04 0C 60 00 F0 (...) 22:31:42.164 ERROR: Failed to execute HCI Reset
The way we used to enter recovery mode in earlier SDKs was to hold SDA to VDD, then hit RESET, release SDA and then make recovery. Is there anything in the recovery code that might have changed in SDK 2.1.1 ?
Also, another observation related to recovery:
The recovery process works on the TAG3 board but only if dipswitches 1-4 are ON. If any DIP switches 1, 2 or 3 are off when the reset + bootroom buttons are pressed, the device does not enter recovery mode. In other words, the following sequence will always fail:
1. attach usb cable to PC
2. turn any combination of dipswitches 1,2 or 3 off
3. press and hold boot_rom push button (SW5)
4. press RESET
5. release SW5
6. turn on all dip switches
7. attempt to make recover
This always fails. But leaving all dipswitches on in step 2 will work. In other words, it appears as if the UART must be connected during recovery boot, which is in contradiction with the answer given here: Unable to (re) program BCM20736
Any advice on how to recover this boards would be very appreciated. Overall we are finding these devices too easy to brick and too hard to recover.
Per the other thread, I personally do not see how using P11/P12 (primary) for the external clock will conflict with P26/P27: Re: BCM2073xS (BCM20737S) GPIO bonding
I am not aware of any external crystal related fixes in SDK 2.2
Can you confirm that this is a SIP module design as noted in the other thread as opposed to an SOC design as noted in this one. The pin/GPIO mappings between the two are quite a bit different.
I will also engage a few others on my team tomorrow that have more experience than myself in this area and have them confirm my my understanding of how primary and secondary GPIO assignments work and what is lost when you make the decision to use one over the other. I will also try to find some others users here on the forum that were able to get the external crystal working within their design.
Thanks for your help. Yes, I confirm that our design uses a SIP (BCM20736S).
Just to summarize our problems with our design after this long thread:
1. When flashing rtc_sample the board becomes "unreprogrammable"
2. The recovery procedure (SDA-to-VDD + RESET) has stopped working, both for good as well as for "unreprogrammable" boards.
1+2 result in a bricked, unrecoverable board.
Ok, so it looks like you are trying to translate the SOC based example here (can be used on the TAG board, which uses the SOC) to your own SIP module design: how to config RTC use external 32.768?
Per the datasheet here for the SOC: BCM20737 SOC Data Sheet
P26/27 or P11/12 can be used for the crystal circuit, which explains the dual function pin descriptions discussed in the other thread.
I also noticed that we recommend a circuit in figure 6 on page 20 of the datasheet as well (note that we recommend different values vs. what is shown):
So at this point, the approach you have taken to implement this on the SIP module design seems sound.
There are quite a few software changes noted in the thread above as well. Have you since worked through those as well? If I am not mistaken, I think this example should now be included within the SDK as well.
Yes, we are trying to use the rtc_sample.c example code that is included in SDK 2.1.1 on our SIP based design.
Unfortunately, until we resolve the recovery problem, we cannot do much experimentation with the rtc: every failed example costs us one bricked board, and we don't have that many prototypes...
Have you ever been able to program one of your own boards without the external Xtal setup? I ask because most customers struggle to initially setup the programming interface to their own board.
There are 2-3 other examples of such that are in progress now within the forum.I'm trying to figure out if it's a programming setup issue, HW conflict, SW conflict, etc. These bricking issues are definitely the most difficult issues to figure out.
Yes, we were able to program our boards successfully. The HW evolution has been...
proto002 - no SDA exposed, no external clock
- programmed successfully
- after bricking a board, we realized we needed SDA access to unbrick
- reworked one proto002 to expose SDA
- recovered that board with the SDA-high + RESET sequence
- captured engineering change order for proto003: expose SDA
proto003 - exposes SDA (via test point) + external clock
- programmed successfully
- bricked board while testing the external clock
- bricked board could not be recovered with SDA-high + RESET sequence
- tried recovery sequence on non-bricked boards, and also fails
- documented recovery troubles here: BCM20736S recovery problem - SDA high does not enter recovery mode
We have proto004 plans on hold until we resolve this problem.
As a follow up to the dialog over the weekend, I wanted to update/confirm with you a few items I learned/verified today (item 1 was posted in the previous thread and was related to the proper use of available GPIO).
I learned that the rtc_sample that is provided within the SDK was only tested on an engineering prototype board initially. This board, like the TAG3 development board, uses an SOC. To date, we have not tested this feature on a board that uses the SIP module.
With that said, have you tested this yourself using the TAG3 board first using the following instructions related to installing the 0 ohm resistors provided within the comments?
* To demonstrate the app, work through the following steps.
* 0. Enable the external 32KHz oscillator on the TAG board (see Quick Start Guide -
* make sure that R102 and R103 on BCM920737TAG_Q32 are populated
* with a 0 Ohm resistor, else the the behavior is undefined).
* 1. Plug the WICED eval board into your computer
* 2. Build and download the application (to the WICED board)
* 3. Application initializes and RTC and prints time every second.
* 3.a Application programs and enters deepsleep, optionally configuring for a timed wake.
The good news here is that VikramR_26 configured this tonight, using the TAG3 board and sample rtc_sample app from the SDK - installing only the 0 ohm resistors and loading the sample app, and everything appears to be working fine (he confirmed he could re-program the board and that the external clock was working).
Since we do not have a reference design to verify with using the SIP module, the team has asked that you send your schematics to mailto:email@example.com
Once received, we will review and see if there is anything on the SIP schematic design that looks like a problem.
At this point, we are thinking that since you copied the sample app from the SDK and have selected the right GPIO to call per the other thread where GPIO for the EXT OSC is being discussed, that the problem must be HW related. We are just not sure where at this point.
Thank you for following up.
1. Yes, we had tried the rtc_sample program on a TAG3 (with R102 and R103 populated) and it worked as documented.
2. Regarding sharing the schematic, what is the visibility of that mailing list? I don't think we can make the design publicly available (yet).
The mailing list is internal to our team. Broadcom only.
This is just to report that we are now able to recover from this failure, but we have not been able to get the external crystal to work. I had sent my schematic for internal review, but no feedback yet.
This post (BCM2073XS GPIO Basics) indicates that we cannot use P26 and P27 when using the external clock. We are now disabling those when running this test. In fact we are just trying the unmodified rtc_sample.c application to test this.
Any suggestions welcome.
Prior to the holiday break, VikramR_26 was able to implement the TAG3 board and the example rtc_sample from the SDK with no modifications other than the addition of the zero ohm resistors mentioned within the .c file included within the rtc_sample. The external crystal that is included on the TAG3 design came up without a hitch and he was able to see the clock transitions on the scope.
The only feedback I've received thus far on your schematic is as follows (I believe we've already discussed):
His schematic looks good, in his program he has to take care of this
// Since the 32K external LPO is connected to P10, P11, P12, P26 and P27,
// input and output disable all 5 GPIOs.
Source : rtc_sample.c
When using the external crystal . So he cannot use P10, P11,P12,P26 and P27 when the external Oscillator needs to be used.
Prior to the holiday break, vik86 was able to implement the TAG3 board and the example rtc_sample from the SDK with no modifications other than the addition of the zero ohm resistors mentioned within the .c file included within the rtc_sample. The external crystal that is included on the TAG3 design came up without a hitch and he was able to see the clock transitions on the scope.
Yes, but I don't know how is that information relevant. As I said in the original post, and repeated on this thread, we were also able to run the example from the SDK on the TAG3 board. The issue is with the BCM20736S-based board. The same rtc_sample.c that works on the TAG3 fails on the SIP.
Looking at the rtc_sample.c code, I don't see any reason why it should not work as is on the BCM20736S. Of course, that assumes that the following calls behave the same on the SOC as well as the SIP:
1. P39 is not documented on the SIP datasheet. Assuming SIP behavior is the same as SOC.
// Always clear interrupts on P39, which is the interrupt pin used by the wake-from-deep-sleep HW block. gpio_clearPinInterruptStatus(GPIO_PIN_P39 / GPIO_MAX_NUM_PINS_PER_PORT, GPIO_PIN_P39 % GPIO_MAX_NUM_PINS_PER_PORT);
2. P10 is not brought out neither on the SOC nor the SIP, yet the code configures it.
// Since the 32K external LPO is connected tp P10, P11, P12, P26 and P27, // input and putput disable all 5 GPIOs. gpio_configurePin(0, 10, GPIO_INPUT_DISABLE, 0);
3. rtc_init() is not documented. Assuming it works on the SIP.
// Initialize the RTC. rtc_init();
4. bleapputils_changeLPOSource() is documented as "Internal, not for application use". Yet it is used by the application example. Assuming it works on the SIP.
bleapputils_changeLPOSource(LPO_32KHZ_OSC, FALSE, 250);
Also, regarding our schematic, it seems that we have correctly hooked up the crystal, and the advice from your team is to have our program take care of disabling all 5 GPIOS. But our program is the unmodified rtc_sample.c, which does disable all 5 GPIOs. In an act of desperation, we even unsoldered the components that were connected to P26 and P27 so they would be left floating. Still no luck.
So right now our assumption is that we have hit a hardware limitation on the SIP.
If the SIP has not been tested with an external clock, may I lend you some of our boards so your team can examine this issue? And if it has been tested, can we have access to the test code?
I was wondering if the new year will bring us some new insights to those of us trying to hook up an external clock to a BCM20736S... Anything new to report? As I mentioned on my last post, I can provide sample boards if someone wants to troubleshoot this.