What are the debugging options are available for BCM4343W

Solved
pihlung's picture
pihlung
Junior(2)

I wanted to debug the MQTT JSON packages the BCM subcribe to, but are getting these errors:

Error with command: tools\ARM_GNU\bin\Win32\arm-none-eabi-gdb.exe --version
Cannot run program "tools\ARM_GNU\bin\Win32\arm-none-eabi-gdb.exe": Launching failed

Using latest WICED 3.5.2 IDE..

Thanks

 

PeterF's picture
PeterF
Moderator(16)

The IoT Starter Kit's JTAG interface supports the GDB debugger however this needs to be configured in WICED SDK.

 

For more detail, please refer to blog article titled "Creating and/or Editing Debug Configurations" on the Broadcom WICED WiFi forum website:
https://community.broadcom.com/community/wiced-wifi/wiced-wifi-forums/blog/2014/05/09/creating-andor-editing-debug-configurations

 

pihlung's picture
pihlung
Junior(2)

Thanks for the link to the debug configuration. It helped me start up the gdb but I am still not able to step through the upstart/program.  I wonder it there is a more detailed document or tutorial of debugging the WICED example projects. 

I could run shadow_light_sense app and connect to aws broker.

 

Pushed WICED debug ikon

 

 

I then used my own "WICED debug plp" from pull down menu.

And it seem to work at least partially.

 

 

Now I can only terminate the debug!! Please advise as how to proceed..

Thanks

Pih Lung

 

PS. I have encountered another issue using debug. 

I could not compile and download a project after ending/exited a debug session, I needed to restart WICED IDE.

"

Downloading Bootloader ...

"**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****"

The process cannot access the file because it is being used by another process.

The process cannot access the file because it is being used by another process.

Building apps lookup table

Downloading DCT ...

The process cannot access the file because it is being used by another process.

The process cannot access the file because it is being used by another process.

"**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****"

Downloading Application ...

The process cannot access the file because it is being used by another process.

The process cannot access the file because it is being used by another process.

"**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****"

Downloading WIFI_FIRMWARE ... at sector 1  size 88...

The process cannot access the file because it is being used by another process.

tools/makefiles/wiced_apps.mk:245: recipe for target 'WIFI_FIRMWARE_DOWNLOAD' failed

make.exe[1]: *** [WIFI_FIRMWARE_DOWNLOAD] Error 1

Makefile:220: recipe for target 'main_app' failed

make: *** [main_app] Error 2

10:38:03 Build Finished (took 5s.645ms)"

 

 

 

 

 

 

 

 

lornarmac's picture
lornarmac
Junior(0)

Hi Peter, that link no longer works - any chance you have an updated one?

pihlung's picture
pihlung
Junior(2)

 

 

 

To my previous post, it didn't copy the images..

PeterF's picture
PeterF
Moderator(16)

GDB Debugger Note
 

Make sure you use the following format for your make target when building the binary images (eg. this make target example based on the simplest snip.scan application):

 

snip.scan-BCM94343W_AVN-debug download_apps download

 

ie.
-debug added to platform name (so image includes debug info)
download_apps to relocate radio firmware to SFLASH memory

 

Launch your custom GDB debug configuration after build + download of your make target to the board...

 

douglasnappier's picture
douglasnappier
Junior(0)

After running through the tutorial on setting up the debugger, I continue to have issues. When the debug environment launches I get the following error:

[New Thread -134376703]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread -134376703]
0x0800c6ea in _start () at WICED/platform/MCU/STM32F4xx/../../ARM_CM4/crt0_GCC.c:58
58        __asm__( "   ldr r1, =link_stack_end\n"

 

Has anyone seen this before? I have tried this on different example demo projects and snips.

PeterF's picture
PeterF
Moderator(16)

That Program received signal SIGTRAP, Trace/breakpoint trap message means that your processor is being stopped by a breakpoint (see comments at the following page).

http://stackoverflow.com/questions/9809413/program-received-signal-sigtrap-trace-breakpoint-trap

 

I'd suggest test the debugger first with one of the proven Broadcom snip example applications. Once you have verified GDB is working correctly, then go back to figuring out why this is happening with your own application

 

PS: Other advice seen in this regard is to set a couple of your own breakpoints and then clear all breakpoints (to flush-out all of the hardware breakpoint registers)

 

Make sure your make target has "-debug" appended to the target name (ie. BCM94343W_AVN-debug) so that the build output includes the debug info which facilitates source-level debugging.

douglasnappier's picture
douglasnappier
Junior(0)

That's the funny thing, I am trying to setup the simple scan demo. My make target is "snip.scan-BCM94343W_AVN-debug download_apps" and it seems to work fine.

I tried the trick of filling up and clearing out the hardware break point and that fix the problem. The problem isn't that it is breaking necessarily, it's where it is doing it at. It says I hit a SIGTRAP in crt0_GCC.c. It's almost as if it is trying to enter at the wrong place. Any thoughts on what could cause this? Below is the full console output:

[New Thread -134376703]

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread -134376703]
0x0800c6ea in _start () at WICED/platform/MCU/STM32F4xx/../../ARM_CM4/crt0_GCC.c:58
58        __asm__( "   ldr r1, =link_stack_end\n"

PeterF's picture
PeterF
Moderator(16)

Try reducing your compiler optimization and see if you get more meaningful results (if compiler optimization is too aggressive it can be hard to tell which code your breakpoint maps to) 

 

This is done by changing the –O optimize parameter in the wiced_toolchain_ARM_GNU.mk file (located under \tools\makefiles)