How to debug non-responsive customer based hardware
So, you've got your custom hardware back from the build facility. It's populated with one of those sexy Broadcom Bluetooth devices. An exuberant crowd of managers and team leaders is milling about the lab, watching with anticipation as you attach the power source. The gleeful moment arrives, and you flip the switch to ON -- Viola! ... Nothing happens. Nada. Zip. Nilch. Maybe you had expected the board's LED to start pulsing indicating the application firmware (pre-programmed into the non-volatile memory) is running. You did pre-program the EEPROM/SFLASH right? Maybe you're just happy there was no smoke, popping sounds, or the acrid smell of "burnt Roast Beef" when the design is bad, or assembled using wrong/misplaced component(s). With a "pat on the back" and some encouraging words, management slinks-away to perform whatever their job function is; leaving you scratching your head and saying "Huh?". You reach for the schematics and an oscilloscope probe... Now what do you do?
Before you post a help request on the Community Forum (WICED Smart Bluetooth Forums), please consider some of the fundamental steps Broadcom recommends you try first.
We remind the reader there are three topologies in which Broadcom devices can operate which may impact how to debug the design:
- Chip on Board or System On a Chip (COB and SOC terms can be used interchangeably) - SOC designs use discreet components and are often very similar to Broadcom's TAG3 or TAG4 evaluation boards. In SOC designs, the (integrated) Broadcom radio and MCU is populated as one-component with additional circuitry added around it, such as the EEPROM, ferrite beads, capacitors/resistors, antenna, and (optional) 32KHz crystal. Broadcom's Bluetooth SOC device stenciling (part number markings) DO NOT end with the letter S, L, or an E and come in a 32pin QFN package. SOC designs are perhaps easiest to debug because you can get a scope probe on virtually everything that can go wrong. Note: Devices stenciled with an S, L, or an E are covered next under the SIP topology.
- System In Package (aka SIP) - a SIP offers the majority of the necessary components all-in-one package, including the antenna. They come with (Limited Module) FCC/UL/CE pre-certifications resulting in your company only needing to perform Spurious Emissions testing. Certifications can save hundreds of thousands of dollars, not to mention time to market and testing hassles. Some customer designs consist of only the Broadcom SIP and a battery! Presently, three flavors of the SIP are available and offer different features depending on the requirements (power, size, RF expertise, etc). These part numbers end with an S, L, or an E and come in a 49pin LGA package. SIPs are rarely defective, so debugging them is usually a function of getting the on-board 64k-byte EEPROM programmed with the users application.
- Modules - Broadcom's Partners offer world-class products and services! Our partners offer everything from device procurement, design services, Broadcom SDK Abstraction, FCC/UL/CE certified modules, to mass production and plastics up to and including Cloud Services. If you're reading this debug Blog, chances are you are not using one of our partner's devices/services because it would already be working for you.
Debugging hardware is easier when able to perform A<->B comparison tests/measurements against a known-good design. You can purchase a Broadcom TAG3/TAG4/WICED-Sense evaluation board, or evaluation boards from Broadcom's partners (IoT Partner Solutions) at this link: Purchase a WICED Bluetooth Dev Kit
Documentation for the TAG3/TAG4 (COB/SOC) eval boards, and SOC/SIP Technical Reference Manuals are found here: WICED Bluetooth Documents & Downloads.
While debugging, you must have access to these pins (at a minimum): VCC/VDD/VIN, HCI_UART_TX, GND, HCI_UART_RX, RESET_N
During debug/initial programming of the NVRAM, it's strongly advised to use a USB<->RS232 serial cable (one option is model #TTL-232RG-VREG3V3-WE found here: Programming the TAG2/TAG3 Board using command line tools).
- Visual Inspection for Mechanical / Assembly problems - Grab your magnifying glass and meticulously inspect both sides of the printed circuit board (PCB). Does anything look bent, damaged, or out of place? Are there any solder bridges, or open-connections on the fine-pitch (device) pins? Does anything look like it has experienced high-heating duress? Are their any cracks in the PCB?
- 'Buzz Out' (use a Volt-Ohm meter to make resistance and continuity measurements of) the Power and Ground Rails going to each device and component that touches them. Measure resistor values for for each resistor shown on the schematics. Verify any diodes or resistors in the design are installed in the correct direction.
- Verify VCC/VDD is 3.3volts.
- Measure the amount of power the board is consuming. Does it seem excessive, or too small? Are any of the components hot-to-the-touch?
- Confirm the timing of the RESET signal going to the BCM2073XX meets the timing requirements. Confirm the device is not being held in RESET which would happens when RESET_N pin is held low.
- There are two UARTs on the device. HCI_UART is used for programming NVRAM, and PUART is available for the users application. Upon powerup, the BCM2073XX device ROMCODE senses the HCI_UART_RXD pin to ascertain if it should enter programming mode. If asserted HIGH, the device enters programming mode. If low, it reads a small chunk of NVRAM contents. One good way to test if the on-board ARM is running romcode is to hold HCI_UART_RXD high during the RESET pulse to force it into programming mode. Then, execute the ~WICED-Smart-SDK/Tools/mbt/MBT.EXE utility(within the SDK) with the "reset COMxx" parameters to verify HCI Commands/Responses are working. It is very important to get this to succeed as it confirms there are no electrical or mechanical issues causing the problem(s), and that the embedded ARM controller is indeed running firmware.
- If MBT.EXE does not successfully run, Inspect the following areas:
- Either chip on board design, or module/SIP designs:
- If your design has a 2nd microcontroller in place, verify the UART interface signals are not reversed. In fact, you might want to isolate the Broadcom chip (cut the traces to the host MCU) to assist getting MBT.EXE to function, or to aid in programming the NVRAM with the SDK.
- Chip on Board designs (BCM2073X):
- Ensure the voltage levels for LDOIN/LDOOUT/VDDVCO/VDDPLL match those found on the Broadcom Evaluation Board.
- Ensure the 24MHz crystal running.
- Ensure TMC is asserted low.
- Monitor the Serial Flash/EEPROM's SDA and SCL pins after the RESET is de-asserted on the BCM2073X. You should see bus activity for a short period of time as the internal ARM MCU comes out of reset (ROMCODE tries to load the application firmware from NVRAM). Make sure you have pullup resistors on these pins.
- If the NVRAM has a known-good application image in it, ensure the HCI_UART_RXD pin of the 2073XX is asserted Low during powerup.
- Module/SiP designs (BCM2073XS, BCM2073XL, BCM2073XE):
- Either chip on board design, or module/SIP designs:
- These designs are difficult to debug because access to the crystal and NVRAM pins are not accessable from outside the package.
- Spend your entire effort getting Step #6 (execution of MBT.exe) functioning to ensure the issue is not a mechanical/electrical one.
- Consider NVRAM pre-programming services from Avnet to ensure the module has a known-good application programmed prior to board manufacturing.
- After getting MBT.EXE working, your next step is to program the NVRAM with your custom application, or a sample application from the SDK. Refer to Programming the TAG2/TAG3 Board using command line tools
If you find an error within this Blog, or have ideas on how to improve it, please send a Private Message to my In-Box so I can incorporate your recommendations.
Please do not post comments on this blog.