Debugging XMOS based systems

[Thomas]

My XMOS based system doesn’t behave as expected, what steps can I follow to debug it?

[Thomas]

1. Determine if the XMOS device is in a valid state.
Use xrun --dump-state in order to analyse a system that booted from flash. Use xgdb to boot via JTAG and debug using breakpoints, xscope messages, etc
a. Check that the device has booted correctly and is executing in application space. Details about debugging boot problems are here: https://www.xcore.com/viewtopic.php?t=4060
b. Check if the application is hanging somewhere. Look for exceptions or if the PC points at instructions that operate on resources (in, out) Those instructions can block and cause hanging

2. Check that the HW design passes all the checks in the data-sheet sections: Schematics Design Check List, PCB Layout Design Check List.

3. Use a scope to check that critical input signals around the chip are clean and within specification (supply voltages, voltage sequencing, clocks, Reset, MODE pins)

4. Document and analyse any differences between your design and XMOS reference schematics for the components that are connected to the XMOS chip.

5. Try to reproduce the problem on an applicable XMOS Reference Design.
a. If yes, you can file a bug by emailing bug@xmos.com. Please provide all relevant information to reproduce the problem
b. Else, analyse how your Hardware differs from working XMOS reference Hardware

Note: The problem is often found during step 1 assuming that the chip is accessible via JTAG.
If JTAG access fails refer to this topic for potential root causes: https://www.xcore.com/viewtopic.php?t=3713

[Thomas]

How to analyse the output of xrun --dump-state ?:

When executing this command the internal state of the processor is read via jtag and printed on stdout.
For more information about xrun and other debug tools refer to the xTIMEcomposer User Guide

The dumpstate output starts with a summary of the current PC and code associated for all active logical cores (threads)
If the PC can be associated with high level source code then this code will be shown as well.

The subsequent sections of the dumpstate output provide further details for each of the active logical cores: Call stack, Disassembly, Registers
If an exception was taken on a logical core, the following registers should be analysed: et, ed, spc (PC of instruction that caused the exception)
et != 0 means that an exception was taken!
You can find more information about the Register Set in the xCORE-200: The XMOS XS2 Architecture (ISA)

The dumpstate output is very useful to determine if the application is in a valid state or if it is hanging somewhere.
Potential root causes for a hang are exceptions (et != 0) or if the PC points at instructions that operate on resources (in, out). Those instructions can block and cause the application to hang.

Examples:
- PC stuck in boot ROM (0xffffcxxx) indicating boot issue (or reboot when debug adapter connected)
Details about debugging boot problems are here: https://www.xcore.com/viewtopic.php?t=4060
- Exception – Find the logical cores where ed !=0 and follow the backtrace to see which task it was thrown in.
- Blocked task - waiting on input or output from channel. Find the other task that is connected via the channel to see what is the cause of the blockage and if it is expected

[cl-b]

Hi,

I find very interesting xCORE debugger scripts on xCORE GitHub (https://github.com/xcore/xgdb_scripts) but I can not find documentation to interpret the result of the commands.

ie details of a specified channel

Chanend 1:
inUse=1, ieMode=E, ieEnabled=1, ready=0, cond=NONE
inWaiting=0, inT=2, outWaiting=0, outT=0
dest=0x80020102

What are the meaning of all these fields ?

[Thomas]

Hi cl-b
I'm glad you're asking.

https://github.com/xcore/xgdb_scripts provides scripts for xgdb to read and display other System Registers via JTAG.

The xlreg script reads and displays information about the XMOS links.
The tilestate script reads and displays information about the hardware resources of an xCORE Tile.

For more information about System Registers, XMOS links and hardware resources refer to the following documents:
XS1-L System Specification - Xmos
xCORE-200: The XMOS XS2 Architecture (ISA)

[cl-b]

Thanks for the link but I cannot find information regarding chanend state (maybe I missed the information in the doc).
What is the meaning of these bitfields

Code: Select all

    set $ieMode     = ($resregval >>  1) & 0x1
    set $ieEnabled  = ($resregval >>  2) & 0x1
    set $inReady    = ($resregval >>  4) & 0x1
    set $inWaiting  = ($resregval >>  5) & 0x1
    set $outReady   = ($resregval >>  6) & 0x1
    set $outWaiting = ($resregval >>  7) & 0x1
    set $evValid    = ($resregval >>  8) & 0x1
    set $inT        = ($resregval >> 16) & 0xff
    set $outT       = ($resregval >> 24) & 0xff

[Thomas]

The information you're asking about is obtained from the Processor Status Register which is documented on page 9 in
xCORE-200: The XMOS XS2 Architecture (ISA)

Note: The tilestate xgdb script reads system registers over jtag into $resregval with the resreg command.

[cl-b]

Regarding chanend status register it seems that information can be read in a 32 bits register. In XS2 architecture documentation page 9 I can read information regarding processor status but not resource (in my case chanend) status.

Is there information about resreg command ?

[cl-b]

Can someone explain what inT and outT refers to ?

Thanks

[mon2]

Believe it is referencing 'Token".