rtc_sample bricks our BCM20736S-based board

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.

Thanks,

Javier

Hi mwf_mmfae,

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.

Thanks,

Javier

Hi mwf_mmfae,

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...

Cheers,

Javier

Hi mwf_mmfae,

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.

Thanks,

Javier

Hi mwf_mmfae,

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).

Best,

Javier

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.

Best,

Javier

Hi mwf_mmfae,

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?

Thanks,

Javier

Hi MichaelF_56

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.

Cheers,

Javier