- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Group,
I will eventually be using the CEL WB4343SP2 in my project but until the prototype board is ready I'd like to get a head start on the firmware using the BCM94343WWCD1 eval board. I am trying to get familiar with the WICED IDE. Its different from the Kiel system we normally use for embedded projects and I am trying to get familiar with it.
I comes with all sort of good examples and with the help of our rep I was able to change the Make Target file from the standard Eval board that it assumes (BCM943362xx) to the BCM94343xxx that I have. I was able to compile the SCAN application, download it to the eval board and run it with its output going to PuTTY.
Great.
The next thing I wanted to do as suggested in the getting started document is to debug the scan program just to get familiar with breakpoints and such.
Here is where it gets weird. Just as in the compile-download and run make file, I created a compile-debug and download make file called
snip.scan BCM94343WWDC1-debug download.
It properly compiled and apparently downloaded the program but when I click on the debug icon I get the following error.
tools/makefiles/wiced_config.mk:224: *** Unknown component: Default. Stop.
make: *** No rule to make target 'build/Default/config.mk', needed by 'main_app'. Stop.
I assume the component that is "unknown" is the BCM94343xx but perhaps not.
The console doesn't give any hint about that even though I think it should to help people like me.
What am I doing wrong?
Thanks
Bill
- Labels:
-
Debug
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bill,
Checking if you took care of configuring your debug settings?'Creating and/or Editing Debug Configurations
thnx
vik86
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks vik86,
I followed the example in the link you provided. After hacking at it much of the day,
I am getting the following error in the details drop down when I attempt to launch the debugger
Error in final launch sequence
Failed to execute MI command:
-exec-run
Error message from debugger back end:
Don't know how to run. Try "help target".
Don't know how to run. Try "help target".
I think I am getting close. Suggestions?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you share screenshots of each tab in your debug configuration. Its mainly the debug configuration that needs to be set right in order to trigger the debug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bill
1) you are suppose to create a new GDB Hardware debugging not C/C++ Application debugging option to your left ,marked 1.
Also once you do that make sure the box 2 is filled by hitting browse button(marked 3) and yours should be WICED SDK.
Match the screens as per the blog for configuring debug options.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've decided to start over because I've tried so many things that I'm sure that I changed something that I should not have.
I re-installed WICED SDK.
In Make Target I copied and pasted the snip.scan-BCM943362WCD4 download run to snip.scan-BCM94343WWCD1 download run.
I compiled that and it downloaded and ran fine.
Then I copied snip.scan-BCM94343WWCD1 download run to snip.scanBCM94343WWCD1-debug download.
I compiled that with no problem. Then I pressed the debug button and got this error.
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
Remembering your last response I figured that I had to create a new GDB Hardware Debugging entry that knows about the BCM94343WWCD1 target. You said to follow the blog. I'm not sure which blog you are talking about but I did try to follow the directions at this link: Creating and/or Editing Debug Configurations
Now I have a second entry under GDB Hardware Debugging.
The original one called WICED-SDK Debug and my new one called WICED-SDK Debug BCM94343WWCD1
There are many differences between these. I need to know how to set up each tab for the BCM94343WWCXD1 EVAL board. I can't afford any more hacking or guesswork.
I would think there would be a simple way to point the project to a specific platform.
I am going to have to go through this again once I get my hardware that uses the CEL module so I need to learn how to do it.
I apologize for my inadequacy but please don't assume I know what an experienced WICED user might know.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bill,
One of our engineers ran into a similar problem:
"In my case the default path for the executable (tools\ARM_GNU\bin\Win32\arm-none-eabi-gdb.exe) wasn't where the .exe was actually located on my computer.
He shouldn't need to use debugging to switch to the CEL platform file - that is specified by the target in the command (BCM94343WWCD1)."
We have a guide that you can follow for the CEL module when you receive it along with the the platform file.
Regards,
-Vince
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks shotsimon
That helped get me to the next plateau. I got into the debugger but something is still awry.
I am back to my original error when I try to debug.
C:\\Users\\bbrown1\\Documents\\WICED\\WICED-SDK-3.5.2\\WICED-SDK\\make.exe" Default
MAKEFILE MAKECMDGOALS=Default OTA2_SUPPORT is disabled
Making config file for first time
tools/makefiles/wiced_config.mk:224: *** Unknown component: Default. Stop.
make: *** No rule to make target 'build/Default/config.mk', needed by 'main_app'. Stop.
But now at least I know that this is pointing to the wiced_config.mk file line 224. The variable called "COMPONENTS is set to "Default" which is not recognized.
I've looked around and can't seem to see where either the script gets a specific component name that it likes or perhaps a place where "default" is set to that component name.
The script references SOURCE_ROOT and COMPONENT_DIRECTORIES variables. I have a feeling that this might be the same type of relative path vs absolute path that got me past the last hurdle.
I be grateful for any help.
Bill
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From our engineering folks again:
I think in this line "C:\\Users\\bbrown1\\Documents\\WICED\\WICED-SDK-3.5.2\\WICED-SDK\\make.exe Default" it is interpreting "Default" as an argument which you don't actually want there. There may be an issue with the path that is forcing the default argument. Depending on your file system, you may need to change the settings so the paths don't have two "\\" in them.
Here are some instructions for setting up the debug environment: https://community.broadcom.com/community/wiced-wifi/wiced-wifi-forums/blog/2014/05/09/creating-andor...
I had to play around with the order of the files in the "Source" tab, eventually ending up with only this option. I am running Windows 8.1.
Here is my console output when I build snip.scan with the -debug flag set:
make snip.scan-BCM943438WCD1-debug download
MAKEFILE MAKECMDGOALS=snip.scan-BCM943438WCD1-debug download OTA2_SUPPORT is disabled
Building Bootloader
Finished Building Bootloader
You can see that it is putting the values from the make target command into the MAKECMDGOALS= argument.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you ShotSimon for your response.
It did point out two things that I hadn't noticed.
While the double backslashes may look a little strange, I do not think that they are the problem. I think that they are artifact from the unix vs MS-DOS way of delimiting paths. Back in the day unix (yes I am that old) used forward slashes in their paths. Then when MS_DOS turned on to sub-directories, they used backslashes because they were already using the forward slash to delimit command line options. Unix used dashes for that. I think that since Eclipse works on many platforms they use the double backslash as a kind of escape character to indicate paths.
The other thing you pointed out is that "Default" parameter to make.exe. I can't figure out how to get rid of it or change it to something more useful.
<edited>
Update:
I created a new entry in the manage configuration icon (the motorcycle wheel) called BCM94343WWCD1.
This seems to take care of the default problem.
< edited>
Another Update:
I'm sorry about all this but I didn't want you to waste any more of your valuable time..
On a whim and because I've tried everything else I deleted the C/C++ Application entry in the Create manage and run configurations dialog box. I kept the GDB Hardware Debugging entry. I was able to build, and single step through the scan program; Success!
I'm not sure what I'm doing and that doesn't make me feel comfortable but its progress.
Thanks for everyone's time an patience.
Bill
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Bill - Thanks for being patient as well. It sounds like you made some progress.
We had another follow-up from engineering:
"When I was seeing a similar problem, it was related to my folder path not being specified correctly. Because the debugger was unable to find the make file in the specified location, it was using the "default" one which wasn't correct. Correcting the path issue allowed the debugger to use the correct make file. On my Windows 8.1 machine, the double "\\" didn't work.
If you are using this option:
check that you have the path to the project specified correctly in the "Main" tab:
My "motorcycle wheel" icon is set to "1 Default"."