Are there any tutorials for debugging in WICED?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
EdGo_4771641
Level 3
Level 3
10 replies posted 5 replies posted 5 sign-ins

I'm looking for good resources on how to debug in WICED studio, such as documents or videos.

I have followed the document Debugging_WICED, and can step through code, but when i need to catch specific things, I find the information misleading.

1) The function names in the stack shown in the Debug window are wrong. I can see a clue as to where the wrong names come from in the Disassembly window. It may be because some of the functions come from libraries.

wrong function names in stack.PNG

I thought optimisation was turned off with the -debug, so what else can I do to get the correct function names?

2) Is there no reset button? The button "Restart a process of debug target without terminating and relaunching" does not do anything. Currently I have to Terminate, then reenter the debug session.

3) The Debugging_WICED document doesn't mention that you have to check the breakpoints have a little blue tick next to them or they won't work.

I'm trying to debug a hard fault (although not in this screenshot), so I need to be able to understand the low level details. I'm used to Microvision, so I've already wasted a lot of time trying to understand what the problems are.

Any help will be greatly appreciated. Thanks.

0 Likes
1 Solution
Charles_Lai
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 sign-ins

Hi,

  1. The actual line it currently goes onto is nx_tcp_socket_receive() and it's correctly identified at both file "tcpip.c" and Disassembly window, which we can regard as cross-verified. Hence it's almost not possible that the debug bridge is malfunctioning.
    And speaking of TCPIP, usually the receiving/sending requests are handled solely in a worker thread, so would you confirm that if you are referring to and expanding the wrong thread in Debug window? Because multiple threads can simultaneously launch their own stack referring to the file "tcpip.c" and the screenshot doesn't have enough information to clarify this.
  2. Yes, you have to terminate and re-run the debug procedure.
  3. There can be different types of breakpoints and they can have different properties. thay are designed so funky to make debug procedure more efficient and tactical. The mechanism of breakpoints are adopted from Eclipse and you can try to find the relevant docs from Eclipse homepage.

Best regards

View solution in original post

0 Likes
3 Replies
Charles_Lai
Moderator
Moderator
Moderator
500 replies posted 250 solutions authored 250 sign-ins

Hi,

  1. The actual line it currently goes onto is nx_tcp_socket_receive() and it's correctly identified at both file "tcpip.c" and Disassembly window, which we can regard as cross-verified. Hence it's almost not possible that the debug bridge is malfunctioning.
    And speaking of TCPIP, usually the receiving/sending requests are handled solely in a worker thread, so would you confirm that if you are referring to and expanding the wrong thread in Debug window? Because multiple threads can simultaneously launch their own stack referring to the file "tcpip.c" and the screenshot doesn't have enough information to clarify this.
  2. Yes, you have to terminate and re-run the debug procedure.
  3. There can be different types of breakpoints and they can have different properties. thay are designed so funky to make debug procedure more efficient and tactical. The mechanism of breakpoints are adopted from Eclipse and you can try to find the relevant docs from Eclipse homepage.

Best regards

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Chunlei, thanks for the reply.

1. I understand now that you have to get the function name from the disassembly instead of the Debug window. You are correct – I think the debugger is working.

Regarding which thread was expanded in the Debug window, I can't be sure any more. I had to give up that project as I was wasting so much time on it. However, I created a new project and I can see it's a worker thread.

I expanded the networking worker thread stack to 12KB, and this can be seen in the structures for worker_thread_main(). I don't think I was looking at the wrong thread previously.

0 Likes

In the end, with the understanding that you can't always trust the function names in the Debug window, I have been able to identify my problem. (i had stored a pointer to a local variable that had then been freed).

I don't think I was looking at the wrong thread, but that would have been a side issue.

Thank you for your help.

0 Likes