By default the LwIP standard debug prints are disabled to save memory and re-use the same for other parts of application threads. But in-case, you nee...
By default the LwIP standard debug prints are disabled to save memory and re-use the same for other parts of application threads. But in-case, you need to enable the standard debug prints in LwIP stack, which is done by LWIP_DEBUGF, you need to follow the steps mentioned below.
lwipopts for WICED SDK can be found in 43xxx_Wi-Fi/WICED/network/LwIP/WWD/FreeRTOS/lwipopts.h. If you are on a DEBUG build (specified by -debug in the make target), WICED_LWIP_DEBUG macro will be enabled, but the prints are still disabled by default.
A standard snip example is considered to demonstrate the how-to operation for a DEBUG build.
Make Target: snip.tcp_client-<platform_name>-FreeRTOS-LwIP-debug download
2. Switch the LWIP_DBG_TYPES_ON to LWIP_DBG_ON
3. To enable specific debug messages in LWIP, just set the specific define value for the *_DEBUG value to " LWIP_DBG_ON". A comprehensive list of debug defines that can be enabled usually found in the 43xxx_Wi-Fi/WICED/network/LwIP/ver2.0.3/src/include/lwip/opt.h file. You need to copy the defines for the debug messages you want to enable into the lwipopts.h file and enable them there. As an example, I have switched the following on in my lwipopts.h file
#define TCP_DEBUG LWIP_DBG_ON
#define ETHARP_DEBUG LWIP_DBG_ON
#define PBUF_DEBUG LWIP_DBG_ON
#define IP_DEBUG LWIP_DBG_ON
#define TCPIP_DEBUG LWIP_DBG_ON
#define DHCP_DEBUG LWIP_DBG_ON
#define UDP_DEBUG LWIP_DBG_ON
Attached is the modified lwipopts.h file and and the uart terminal print. Please note that enabling debug prints can add extra size (approximately 20 kB for the mentioned settings) to the code. It will also slow down performance of the LwIP code due to required run-time checks and output. It's is recommended to enable debug support only if there is no chance of attaching an external debugger to the target platform and step through the code.
SUMMARY: We divide the SDK code into different module or library for specific function, and Hierarchical software design also is useful for the code ...
We divide the SDK code into different module or library for specific function, and Hierarchical software design also is useful for the code maintenance. This blog is to show the log setting for different module. Please see below architecture from SDK release document. Our aim is to print useful logs when issue happens, upload one module picture from SDK release .
HOW TO Print LOGS：
To use “printf” directly, this is very convenient for the debug, but not easy to make a good management for the logs added. Some basic knowledge of print is in this link：
We have good instructions and warnings for the log setting:
* ** WARNING for PRINTING **
* If printing is enabled, the stack of each thread that uses printing
* must be increased to at least 4 kBytes since the printf function uses
* a lot of memory (including dynamic memory)
/* Select which group of functions are allowed to print */
/* WPRINT_ENABLE_<MODULE>_ERROR - Enable print messages in the respective <MODULE> that are present
* as WPRINT_<MODULE>_ERROR.
* For instance, if WPRINT_ENABLE_WWD_ERROR is enabled, then trace messages that are under
* WPRINT_WWD_ERROR will be printed. This directive shall also result in an ASSERT if the target is built in DEBUG mode.
* WPRINT_ENABLE_<MODULE>_DEBUG - Enable print messages in the respective module that are present as
* For instance, if WPRINT_ENABLE_WWD_DEBUG is enabled, then trace messages that are under
* WPRINT_WWD_DEBUG will be printed.
* WPRINT_ENABLE_<MODULE>_INFO - Enable print messages in the respective module that are present as
* For instance, if WPRINT_ENABLE_WWD_INFO is enabled, then trace messages that are under
* WPRINT_WWD_INFO will be printed.
If you disable all the logs, there will have a compiled error, so please keep this one at least:
#define WPRINT_ENABLE_APP_INFO /* Application prints */
So general debug sequence for log enable:
Enable WPRINT_ENABLE_MODULE_INFO to track the process.
If found an error was printed out, check which module , then enable DEBUG and ERROR mode also. Be noted, Debug compile will go to an assert if enable ERROR layer .
Find the bug position , add more debug info by using the same level log print.
I think if you want to manage the log clearly , you can define one MACRO to just add your debug info ,like #define WPRINT_ENABLE_BUG_DEBUG_INFO , after issue is fixed you can disable it .Another log print mode :
3. Wiced_log_setting, it is often used on application area.
If you want to close the log , please change the log to WICED_LOG_OFF, the logs added in the application will be disabled. And strongly suggest to use this debug info in application debug stage.
Log initialize at application_start and enum structure.
Summary: The difference between Signal mode and Direct mode is: we only need to connect the EVB with the test AP created by AP, then AP will have ...
The difference between Signal mode and Direct mode is: we only need to connect the EVB with the test AP created by AP, then AP will have a menu to test TX and RX related. Its aim is to figure out if the actual running power is matching what you want, RX path has no RF de-sense in a normal running mode. If signal mode passed all the RF standard, we can have a confidence that current RF path include TX and RX, current RF configuration like NVRAM have no critical issues. We can move the product into next long-run function tests.
Which EVB is for the tests?
I choose 43340 because it has 2.4G and 5G together.
How to set 8860C before test.
1. Set the static IP address
2. configuration .
Which means creating a AP at 153 channel with 6M rate and power is -15dbm.
After AP created we use command to join the AP, then we can do the test .
Which application is needed for the tests?
I used the command console for the test because we can use a lot of embedded commands to join a specific AP and do some command input.
And we are using the normal firmware for the test, please see the command output.
test.console-BCM943340WCD1 download run
Which commands are needed before the tests?
After connection established “scan_suppress 1” , “roam_disable ” are preferred .
This blog post shows how to use macros in WICED to debug TLS (Transport Layer Security) data. The mbedTLS library provides debug macros MBEDTLS_DEBUG_...
This blog post shows how to use macros in WICED to debug TLS (Transport Layer Security) data. The mbedTLS library provides debug macros MBEDTLS_DEBUG_C, MBEDTLS_SSL_DEBUG_ALL and MBEDTLS_DEBUG_LOG_LEVEL defined in /WICED/security/BESL/mbedtls_open/include/mbedtls/config.h and they are disabled by default. You can enable those macros and define MBEDTLS_DEBUG_LOG_LEVEL as per the level of debugging required. Higher the level, more details can be captured in the logs. The log levels are defined as shown below:
0 No debug
2 State change
In addition, you also need to enable WPRINT_ENABLE_SECURITY_DEBUG in /include/wiced_defaults.h. Please note that debug printing consumes a lot of memory so you need to allocate at least 4 kB to the stack of every thread that uses debug printing.
How to debug non-responsive customer based hardwareSo, you've got your custom hardware back from the build facility. It's populated with one of those...
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 (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 TAG3or TAG4evaluation 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) - aSIP 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 (Partners) at this link: Purchase a WICED Bluetooth Development Kit
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.
If you are having problems with your installer, check that the download size of the installer is roughly 260MB, installer problems are typically caused by incomplete downloads.
The picture below shows a very common error message. Our SDK utilizes a 32-bit version of an Eclipse based IDE which requires a 32-bit version of JRE to be installed. If you already have the 64-bit JRE installed, you will also need to install the 32-bit version as well. The JRE is designed to allow both 32 and 64 bit variants to be installed on the system.
The WICED Sense kit uses a Silicon Labs USB to Serial Device. The TAG3 board uses an FTDI USB to Serial Device. Both should be installed as part of the SDK 2.2.1 installation process. If not, the FTDI drivers for the TAG3 reinstall them using the file /WICED-Smart-SDK/Drivers/dpinst.exe (make sure you access from the command line). The Silicon Labs USB Drivers can be foundWICED Sense Table of Contents
Everything we have for the WICED Sense, such as schematics, drivers, and Android application source code, can be accessed through theWICED Sense Table of Contents. A great post for the WICED Sense is theWICED SENSE Kit BLOGwhich is like a WICED Sense quick start guide.
Some Android devices appear to have issues pairing to the WICED Sense Tag from inside the app, linked is a work-around that should allow you to connect to your Android device:WICED Sense Android Pairing Work-Around