exception on chkct in wakeCore()

Technical questions regarding the XTC tools and programming with XMOS.
pasau
Experienced Member
Posts: 77
Joined: Fri Dec 06, 2013 7:05 pm

exception on chkct in wakeCore()

Post by pasau »

Hi, i am trying to run a build on my slicekit. I get the ET_ILLEGAL_RESOURCE exception. Upon entering the exception, the spc register is at 0x145e4, meaning an exception on chkct. I have 0x2 in the ed register, so it means an error on a channel operation. I would like to get some ideas that would get me to troubleshoot my problem further and find exactly which channel allocation causes the problem.

As far as i know, the res[rn] argument means it's a resource argument but i don't get why my r1 reg has the 0x2 value in it, which seems like a bad resource identifier. I probably don't understand the proper use of res[rn] though, could it be an array or some indirect addressing to a resource array? I haven't read the whole architecture document, but i haven't seen better info about the res[rn] argument. Also, what are the codes right next to the instruction like (lru6)

Code: Select all

<wakeCore>:
             0x000145d6: 00 f0 46 6c: ldw (lru6)      r1, cp[0x6]
             0x000145da: bc 91:       add (2rus)      r3, r11, 0x0
             0x000145dc: d9 16:       setd (r2r)      res[r1], r2
             0x000145de: c5 ae:       out (r2r)       res[r1], r1
             0x000145e0: d5 4e:       outct (rus)     res[r1], 0x1
             0x000145e2: c1 b6:       in (2r)         r0, res[r1]
             0x000145e4: d5 ce:       chkct (rus)     res[r1], 0x1
             0x000145e6: 40 69:       ldc (ru6)       r5, 0x0
             0x000145e8: 05 af:       out (r2r)       res[r1], r5
             0x000145ea: d5 4e:       outct (rus)     res[r1], 0x1
             0x000145ec: 06 f0 c8 62: ldaw (lru6)     r11, dp[0x188]

Code: Select all

Currently logging to "gdb.txt".
Future logs will be written to test.log.
Logs will be appended to the log file.
Output will be logged and displayed.
Currently logging to "gdb.txt".
Future logs will be written to test.log.
Logs will be appended to the log file.
Output will be logged and displayed.
  2  tile[1] core[0]  0x0001710a in waitForZero ()
* 1  tile[0] core[0]  0x0001460e in _DoException ()
[Switching to thread 1 (tile[0] core[0])]#0  0x0001460e in _DoException ()
r0             0x0	0
r1             0x2	2
r2             0x40000002	1073741826
r3             0x156bc	87740
r4             0xf	15
r5             0x14fe8	85992
r6             0x0	0
r7             0x0	0
r8             0x0	0
r9             0x0	0
r10            0x0	0
r11            0x156bc	87740
cp             0x14e98	85656
dp             0x15068	86120
sp             0x1fef0	130800
lr             0x144c2	83138	 main + 42
pc             0x1460e	83470	 _DoException + 2
sr             0x51	81
spc            0x145e4	83428	 wakeCore + 14
ssr            0x0	0
et             0x4	4
ed             0x2	2
sed            0x0	0
kep            0x10080	65664
ksp            0x0	0


User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am

Post by segher »

"res[..]" is just assembler syntax, making it clear that the
register you use there holds a resource identifier. It's much
harder to misread (or miswrite) "in r0,res[r1]" than "in r0,r1".

"lru6" is the instruction form, just ignore it, it's almost always
useless, and always redundant. I'm surprised you've never
seen those in the architecture book, more than half of the
pages show one or more ;-)

2 is a perfectly fine channel end resource id. The top 16
bits are the node id (0 here); the middle 8 bits are the
channel end # on that node (0 here, each processor has
00..1f, and ff means "black hole"); and the low 8 bits are
the type of resource (2 here: a channel end).

The instructions immediately before your failing instruction
used r1 as channel end id just fine, too.

The architecture book lists all the reasons a chkct can fail.
The usual reason is that the next token received is not a
control token, but instead a data token.
richard
Respected Member
Posts: 318
Joined: Tue Dec 15, 2009 12:46 am

Post by richard »

Do you have the link switch on the xSYS adaptor board set to on or off? This error can sometimes be caused by trying to use xSCOPE while the switch is set to off.
pasau
Experienced Member
Posts: 77
Joined: Fri Dec 06, 2013 7:05 pm

Post by pasau »

@richard: thanks, that could very well be it, ill check that next time i get to work on my slicekit.

@segher: ok, i understand there are several reasons for exception on the architecture level, but now that i know that a specific channel is receiving a bad token, is there a way i can relate this to higher level of code like how can i find what i did wrong in my XC/C code? Can i find channel 0 of processor 0 in my XC program? Also, since i get an error in wakeCore(), am i wrong to say that my error must occur on a global declaration of some kind, since i haven't entered my main function yet?

Thanks guys
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am

Post by segher »

You debug this like you debug anything else: you formulate
your expectations ("what do I think this code should do"),
you do some measurements ("what does the code actually
do"), repeat, refine, until you see what is wrong.

Since it seems to happen in the startup code and that is a
black box without available source code (or even a vague
description in the documentation), there's not too much you
can easily do. Occam's razor says there is likely something
wrong with (or unusual about) your hardware or your XN
file, or maybe how you compile.

Eliminate possibilities: has your board ever run any code
properly? Can it now run simple example code? Etc.

A good first thing to test is Richard's suggestion ;-)