cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

Anonymous
Not applicable

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

0 Likes
Reply
1 Solution
Moderator
Moderator

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.

View solution in original post

11 Replies
Anonymous
Not applicable

You can disable auto-build in your Debug Configurations. That way it doesn't rebuild.

Can you build the debug target without error messages?

Anonymous
Not applicable

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

0 Likes
Reply
Anonymous
Not applicable

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

Anonymous
Not applicable

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

0 Likes
Reply
Anonymous
Not applicable

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.

0 Likes
Reply
Moderator
Moderator

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.

Anonymous
Not applicable

I have found now a reproducable behaviour,

Please find configuration screenshots and debugger logfiles attached.

There are also notes of the steps performed in the file Avtivity log.

Thanks for supporting me.

0 Likes
Reply
Anonymous
Not applicable

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?

Anonymous
Not applicable

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?

0 Likes
Reply
Moderator
Moderator

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.

View solution in original post

Anonymous
Not applicable

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

0 Likes
Reply