xmap: Error: Tile id does not refer to tile declaration.

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
kc3i
New User
Posts: 3
Joined: Thu Nov 02, 2017 11:04 am

xmap: Error: Tile id does not refer to tile declaration.

Post by kc3i »

Hello
I've got strange error during compilation: xmap: Error: Tile id does not refer to tile declaration.
It's look like my procedure is too big. If I coment few code lines it compile without any errors:
Constraint check for tile[0]:
Cores available: 8, used: 8 . OKAY
Timers available: 10, used: 8 . OKAY
Chanends available: 32, used: 17 . OKAY
Memory available: 262144, used: 76644 . OKAY
(Stack: 23180, Code: 37552, Data: 15912)
Constraints checks PASSED.
Constraint check for tile[1]:
Cores available: 8, used: 8 . OKAY
Timers available: 10, used: 8 . OKAY
Chanends available: 32, used: 26 . OKAY
Memory available: 262144, used: 128220 . OKAY
(Stack: 22596, Code: 99284, Data: 6340)
Constraints checks PASSED.

Is there any restriction for size of procedure running on single core?

xTIMEcomposer 14.3.2


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

@kc3i,

1) post your XN file for this project

2) which specific XMOS CPU is the target ?
kc3i
New User
Posts: 3
Joined: Thu Nov 02, 2017 11:04 am

Post by kc3i »

XCORE-200-EXPLORER.xn
(2.1 KiB) Downloaded 191 times
XCORE-200-EXPLORER.xn
(2.1 KiB) Downloaded 191 times
XEF216-512-TQ128-C20
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Your XN file has a target of:

Code: Select all

<Package id="0" Type="XS2-UEnA-512-FB236">
but your hardware is:

XEF216-512-TQ128-C20

This could be an issue. Does the tool chain offer a more suitable match for your target? Test and post your results.
kc3i
New User
Posts: 3
Joined: Thu Nov 02, 2017 11:04 am

Post by kc3i »

changed to XS2-UEFnA-512-TQ128 (according to XEF216-512-TQ128 Datasheet), stil got errors but sometimes new one (depending how many lines of code I add or remove):
xmap: Error: port or clock "XnDOUT.info" has invalid tile reference.
source code:
on tile[1] : in port XnDOUT = XS1_PORT_1D; //X1D11
Interesting thing is that XnDOUT is first port definition in program, If I comment this definition error will be on next one. Maybe something wrong is with platform.h file? Mine looks like below, I've added #pragma warnings but they never shonw:
/* .....
* Version: Community_14.3.2
*/

#ifndef _platform_h_
#define _platform_h_

#ifdef _PLATFORM_INCLUDE_FILE
#pragma warning "PLATFORM INCLUDED"
#include _PLATFORM_INCLUDE_FILE
#else
#pragma warning "PLATFORM NOT INCLUDED"
#endif /* PLATFORM_INCLUDE_FILE */

#endif /* _platform_h_ */

EDIT:
Amazing thing is that I can comment few lines of code and everything compile without errors, so it looks like xmap bug.

EDIT 2:
Rolling back to 14.2.0 gives flood of errors:
Creating boot_xcore_200_qspi.xe
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section attributes for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section attributes for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
...

EDIT 3:
temporary workaround is to change optimization from -O0 to -O1 in makefile, so it looks like some problem with code size...
User avatar
johned
XCore Addict
Posts: 185
Joined: Tue Mar 26, 2013 12:10 pm
Contact:

Post by johned »

-O0 can lead to some very large executable sizes. I would recommend -Os or -O2.
Note -Os often leads to the most efficient code because boiler plate code is removed very efficiently. -O3 can often lead to higher performance at the expense of larger code size.
John
robertxmos
XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Post by robertxmos »

I would recommend `-Os` as standard.
`-O2` and `-O3` are similar but will attempt to dual issue and other more aggressive optimisation.
Dual issue is very poor at present, so if you really want `-O2` or `-O3` I would turn it off as defauilt with `-mno-dual-issue`.
If you then decide a particular function should be dual-issue, you can turn it on for that function by marking it in code with `[[dual_issue]] void myfunc()`.
And for completeness there is also a flag `-mdual-issue` and an attribute `[[single_issue]]`.
Post Reply