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.
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.
Show LessWe 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 .
https://fresh2refresh.com/c-programming/c-printf-and-scanf/
#include <stdio.h>
int main()
{
char ch = 'A';
char str[20] = "fresh2refresh.com";
float flt = 10.234;
int no = 150;
double dbl = 20.123456;
printf("Character is %c \n", ch);
printf("String is %s \n" , str);
printf("Float value is %f \n", flt);
printf("Integer value is %d\n" , no);
printf("Double value is %lf \n", dbl);
printf("Octal value is %o \n", no);
printf("Hexadecimal value is %x \n", no);
return 0;
}
· %d got replaced by value of an integer variable (no),
· %c got replaced by value of a character variable (ch),
· %f got replaced by value of a float variable (flt),
· %lf got replaced by value of a double variable (dbl),
· %s got replaced by value of a string variable (str),
· %o got replaced by a octal value corresponding to integer variable (no),
· %x got replaced by a hexadecimal value corresponding to integer variable
· \n got replaced by a newline.
2. In wwd_debug.h, wwd_debug.c , wiced_defaults.h
We defined Macros to control the log output for different MODULE.
Modules are Application, library, Webserver , Network, RTOS,
Security , WPS, Supplicant, Wiced , WWD(Wiced wi-fi Driver) .
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
* WPRINT_<MODULE>_DEBUG.
* 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
* WPRINT_<MODULE>_INFO.
* 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:
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 :
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.
wiced_log_init(WICED_LOG_INFO, render_log_output, wiced_time_get_time);
wiced_log_msg(WLF_DEF, WICED_LOG_NOTICE, "wiced logging system is initialized\n");
typedef enum
{
WICED_LOG_OFF = 0,
WICED_LOG_ERR,
WICED_LOG_WARNING,
WICED_LOG_NOTICE,
WICED_LOG_INFO,
WICED_LOG_DEBUG0,
WICED_LOG_DEBUG1,
WICED_LOG_DEBUG2,
WICED_LOG_DEBUG3,
WICED_LOG_DEBUG4,
WICED_LOG_PRINTF, /* Identifies log messages generated by wiced_log_printf calls */
WICED_LOG_MAX
} WICED_LOG_LEVEL_T;
b: How to write to STDOUT .
use this function:
Enable time output with log together.
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 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.
I choose 43340 because it has 2.4G and 5G together.
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 .
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
After connection established “scan_suppress 1” , “roam_disable ” are preferred .
PM = 0 is good to be set also.
In command console:
Usage: scan_disable <1 = disable scan|0 = enable scan>
> scan_disable 1
If you didn’t have this command, please add it according another blog.
Please input “set country ”, then get channel , choose one channel to do connection with the AP created by instrument.
> get_country
Country is US (US/0)
> set_country CN/0
> get_country
Country is CN (CN/0)
> get_channels
1 2 3 4 5 6 7 8 9 10 11 12 13 149 153 157 161 165 >
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
1 Error
2 State change
3 Informational
4 Verbose
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.
Show LessHow 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:
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
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).
Debug steps:
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.
Show LessProduct Selection | Product Evaluation | WICED Sense | Product Development | Manufacturing / Production |
Revision | Change Description | Date |
---|---|---|
1.0 | Initial | 08/08/14 |
1.1 | Added J-Link Cable for Reference | 08/11/14 |
WICED Smart J-Link Debugger
The WICED Smart J-Link Debugger is a Software debugger combined with Segger J-Link Debug Probe.
Figure 1: J-Link Segger Debugger
2. Schematic of cable adapter to the J-Link 20 Pin connector:
Figure 2: J-Link Segger Debugger Interface Connector
3. Shown below is the connection to the BCM20737TAG_Q2 Board:
Figure 3: J-Link Connection to BCM20737TAG_Q2 Board
4. The Smart Designer J-Link setup procedure:
Start SDK
Figure 4: Boot ROM, Reset and Switch Buttons
Please refer to the Quick Start Guide: http://community.broadcom.com/docs/DOC-1602
Click “I” once then press F5 3 times.
Note: R3 (the 10K pulldown on RXd) must be removed for the debugger to work.
Please let us know if you have any issues.
Thanks
JT
Show LessThis blog is about basic debug information and configuration details for OS X on WICED SDK 2.4.1
The video shows very basic debug details
Before debugging always run 'Clean' from the 'Make Target' Window and not eclipse-->build-->clean
Debug Configuration on WICED SDK (2.4.1)
1) Main configuration tab
2) Debugger Tab (Make sure the 'Force thread list update on suspend' is unchecked)
3) Startup tab
4)Source tab
5) Common tab
HTH
vik86
Show LessThis was taken from a previous discussion started by jasonrc with input from frankf and tek thank you for the input...
We recommend using a USB wireless sniffer from one of the following vendors.
AirPCAP Nx -- works with Wireshark
Good, well-priced, easy-to-use network network analyser
http://www.riverbed.com/us/products/cascade/wireshark_enhancements/airpcap.php
http://www.wireshark.org [Win32 v1.4.14 is stable and works well]
All versions downloadable here: http://wiresharkdownloads.riverbed.com/wireshark/win32/all-versions/
Omnipeek
Full featured network analyser
http://www.wildpackets.com/products/network_analysis_and_monitoring/omnipeek_network_analyzer
AirMagnet
Full featured network analyser
http://www.flukenetworks.com/enterprise-network/wlan-security-and-analysis
Microsoft Network Monitor 3
A free tool which uses the Wi-Fi card in the laptop/PC.
http://support.microsoft.com/kb/933741
For doing analysis of the RF/WiFi environment, the following tools are useful:
WiSpy - PC dongle to do 2.4GHz and 5GHz spectrum capture. Can show 802.11 and non-802.11 interference.
http://www.metageek.net/products/wi-spy/
inSSIDer - Free scanning tool to show other 802.11 networks within range.
http://www.metageek.net/products/inssider/
Basic network scans are also available using the wireless utility in your PC or Mac.
Also for RF/WiFi environments if you have an iPad/iPhone/iPod Touch
WiPry - iPhone/iPad/iPod Touch dongle for 2.4GHz analysis
http://www.oscium.com/products/wipry-combo-spectrum-analyzer-and-dynamic-power-meter
The power meter function is quite handy if you want to make duty cycle measurements or measure actual TX times.
Here is another great tutorial for MACOS users...