- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Working with WICED Studio 4.1.0, Win10, Platform BCM94343W_AVN added
Hi
Debugging of the snip.scan sample app on the Avnet IoT Starter Kit fails. The normal snip.scan app runs without debugger runs.
I followed the debug settings stated in other posts here.
I have target "snip.scan-BCM94343W_AVN-debug download run" copied to "snip.scan-BCM94343W_AVN-debug download run"
Compiling works and last console message is:
....
Downloading DCT ...
No changes detected
Downloading Application ...
Download complete
Resetting target
Target running
Build complete
Making .gdbinit
10:55:44 Build Finished (took 18s.522ms)
After pressing Debug button, the following message appears on the CDT Build Console:
10:44:28 **** Incremental Build of configuration Default for project 43xxx_Wi-Fi ****
"C:\\Users\\Klaus\\Documents\\WICED\\WICED-Studio-4.1\\43xxx_Wi-Fi\\make.exe" Default
MAKEFILE MAKECMDGOALS=Default OTA2_SUPPORT is disabled
Making config file for first time
tools/makefiles/wiced_config.mk:244: platforms//.mk: No such file or directory
tools/makefiles/wiced_config.mk:255: *** Unknown component: Default. Stop.
make: *** No rule to make target 'build/Default/config.mk', needed by 'main_app'. Stop.
10:44:29 Build Finished (took 326ms)
What did I miss?
Thanks for any help!
Klaus
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From the debug configuration images, the path for GDB command in Debugger tab is not clear. Ensure that it is set up correctly. For instance, I have configured the GDB command path as C:\Users\grsr\Documents\WICED\WICED-Studio-4.1\43xxx_Wi-Fi\tools\ARM_GNU\bin\Win32\arm-none-eabi-gdb.exe. Similarly you need to configure the last_built.elf path in the Main tab as C:\Users\grsr\Documents\WICED\WICED-Studio-4.1\43xxx_Wi-Fi\build\eclipse_debug\last_built.elf. There should be no ${workspace_loc}\... in the path. I hope you have removed the "stepi" from the Run Commands window as I stated earlier. Perform these changes and let me know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can disable auto-build in your Debug Configurations. That way it doesn't rebuild.
Can you build the debug target without error messages?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've disabled auto rebuilding for debugger now.
Building works once without errors.
Debugging works also only once.
A complete reboot of the (Windows10) PC is necessary to be able to recompile and debug again.
After a debug termination, restarting debugger is no more possible:
"No source available for "0x8000608" "
Remaking the target or clean do not execute a second time.
There are different problem messages, but the most confusing is:
Invalid project path: Include path not found (Users\Klaus\Documents\WICED\WICED-Studio-4.1\43xxx_Wi-Fi\tools\ARM_GNU\include).
Situation is difficult to describe, because I did not yet find a reproducable and consistent behaviour.
I will investigate further.
May it be helpful to install an earlier version of the SDK?
Thanks for supporting!
Klaus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One thing I've found is that terminating or disconnecting the debugger
doesn't kill the openocd process in the background. I always need to open
up Task Manager and kill openocd-libftdi.exe after debug before I can run
the debugger again.
I'm not sure how you got the error about include path though.
Josh
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, task openocd-all-brcm-libftdi.exe remains active and must be closed manually.
Building target with "snip.scan-BCM94343W_AVN-debug download run" works without error message
But debugger still worked just once, but since then I get messy messages like:
No source available for "(gdb[0].proc[42000].threadGroup[i1],gdb[0].proc[42000].OSthread[1]).thread[1].frame[0]"
after next debug attempt (openocd was terminated before):
No source available for "0x8000608"
It seems that some source files are blocked by an other background task or debug information is not fully included in the .elf.
It is really difficult to find a reproducable behaviour. Each time relaunching the procedure, the system behaves differently
Any ideas how to catch the reason for the debug problems are welcome ...
Klaus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is really strange and I've never seen that before. I guess check that your GDB process (arm-none-eabi-gdb.exe) is also terminated.
Elf files usually include all the information and I don't think that's what the problem is. The suggestion above is a quick fix I can think of.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you share your debug configuration settings? You need to ensure that the path for arm-none-eabi-gdb.exe is correct. Go to the Debugger tab and the GDB command path should be C:\...\WICED-Studio-4.1\43xxx_Wi-Fi\tools\ARM_GNU\bin\Win32\arm-none-eabi-gdb.exe. Similarly the last_built.elf path should be correctly set in the Main tab under C/C++ Application. Go to the Startup tab and remove stepi under Run Commands and check if this solves your problem. You need not go to the task manager to close openocd-all-brcm-libftdi.exe; you can simply delete the path C:/.../WICED-Studio-4.1/43xxx_Wi-Fi/tools/ARM_GNU/bin/Win32/arm-none-eabi-gdb.exe (7.7) in the Debug window to close the debugging.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From your OpenOCD log:
Error: JTAG tap: stm32f4xx.bs expected 1 of 1: 0x06413041 (mfg: 0x020, part: 0x6413, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Is there something wrong with your debugger? It's the on-board FTDI chip on the Starter Kit isn't it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FTDI chip is on-board. Problems remain the same with a second Starter Kit.
FTDI driver itselfs seems to work normally, because terminal works as well as downloading bootloader. DCT and application.
Openocd is also used for downloading to the target, so openocd seems also OK.
Sometimes (approx. once from 20 WICED Studio relaunch and making target attempts) , debugger works.
Something is not stable (timing?) or another application interferes wirh the debugger task.
grsr
Could you find problems in my configurations?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From the debug configuration images, the path for GDB command in Debugger tab is not clear. Ensure that it is set up correctly. For instance, I have configured the GDB command path as C:\Users\grsr\Documents\WICED\WICED-Studio-4.1\43xxx_Wi-Fi\tools\ARM_GNU\bin\Win32\arm-none-eabi-gdb.exe. Similarly you need to configure the last_built.elf path in the Main tab as C:\Users\grsr\Documents\WICED\WICED-Studio-4.1\43xxx_Wi-Fi\build\eclipse_debug\last_built.elf. There should be no ${workspace_loc}\... in the path. I hope you have removed the "stepi" from the Run Commands window as I stated earlier. Perform these changes and let me know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi grsr
Thanks for your help. It works!
I have changed the path entries, but I had overseen the removal of "stepi" from the run command.
A little problem remaining: The breakpoints are not taken, when restarting the debugger. Breakpoints have to be removed and re-selected again directly in the source window (disabling and re-enabling in the breakpoint list does not help).
If I do not find the reason, I will open a new Forum entry.
Regards and thanks
Klaus