Unintended Task launched, best way to Debug

[shaw]

We are working on a new project on XU316-1024-FB265-C32, based on Xmos USB Audio 2 development software kit. We are trying to optimize certain tasks and we are trying to make sure we have a good handle on the overall task structure. During a analysis of running threads we realized that one of the tile 1 threads was not intentionally launched in our software. Output from (gdb) info threads is listed here:

15 tile[1] core[7] rx_bit_ep () at .../wkspace/lib_uart/lib_uart/src/multi_uart_rx_8chan.S:128
14 tile[1] core[6] (dual issue) at .../wkspace/lib_uart/lib_uart/src/multi_uart_tx.xc:230
13 tile[1] core[5] (dual issue) at .../wkspace/lib_xua/lib_xua/src/core/mixer/mixer.xc:444
11 tile[1] core[3] (dual issue) at .../src/extensions/uart_tile1.xc:93
10 tile[1] core[2] (dual issue) at .../src/extensions/tile1_control.xc:821
9 tile[1] core[1] (dual issue) at .../wkspace/lib_xua/lib_xua/src/core/audiohub\xua_audiohub_st.h:12
8 tile[1] core[0] (dual issue) at .../wkspace/lib_xua/lib_xua/src/core/audiohub/multiPin.xc:206
12 tile[1] core[4] 0x00088afa in ?? ()


Thread 12 on tile[1] core[4] is confusing how it was launched. Are there any clues in the "Info Threads" output, AND what are some ways to try to identify where in our code this task is being created, so we can remove it. Thanks for any help.

[infiniteimprobability]

It can sometimes help to switch to the task type "t 12" to switch to that thread and then do a backtrace "bt" to look at the call stack.

[xhuw]

Just been thinking about this - xgdb supports "resource watchpoints" that break whenever a resource is accessed. Spawning a thread on an xcore usually requires adding the thread to a "synchroniser," which is a kind of resource. The IDs of the synchronizers on an xcore are:

0x3,0x103,0x203,0x303,0x403,0x503,0x603.

So, for example, reswatch 0x3 will trigger a breakpoint when that synchroniser is configured. We don't know which synchroniser is used for your thread, so you will have to try all of them