Settings compiler flags for SPI Slave Boot Loader thru XTime Composer Studio

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
KurtOz
Junior Member
Posts: 5
Joined: Tue Jul 04, 2017 7:56 pm

Settings compiler flags for SPI Slave Boot Loader thru XTime Composer Studio

Postby KurtOz » Wed Aug 23, 2017 8:55 pm

Hi,
I have been working on a SPI Slave Boot Loader for our project which is based on xCore XU216. The application note AN00238 (1.0.2) clearly outlines the steps to compile both loader and a demo application by using standalone Makefiles. I would like to extend those compiler settings by using xTime Application Makefile editor to bind loader objects to our applications created by xTimeComposer. Currently I am working on xTimeComposer 14.2.24.

Specifically I would like to add those flags to corresponding Makefile editor fields:

XCC_EXTRA_MAP_FLAGS = -L . -lloader -Xmapper --first -Xmapper ./loader_pre_crt.o ./loader_init.o

Is there any field that I can insert those extra flags, or should I directly edit the Makefile at source level as:

...
# The flags passed to xcc when building the application
# You can also set the following to override flags for a particular language:
# XCC_XC_FLAGS, XCC_C_FLAGS, XCC_ASM_FLAGS, XCC_CPP_FLAGS
# If the variable XCC_MAP_FLAGS is set it overrides the flags passed to
# xcc for the final link (mapping) stage.
XCC_FLAGS = -O2 -g
XCC_MAP_FLAGS =
XCC_XC_FLAGS =
XCC_EXTRA_MAP_FLAGS = -L . lloader -Xmapper --first -Xmapper ./loader_pre_crt.o ./loader_init.o
...

Even if I include as shown above make fails by complaining about not finding loader_init.o file. All the loader files are copied at the project directory top level.

Should I ignore the makefile created by the xTimeComposer and use a standalone Makefile for this purpose?

Thanks
User avatar
xsamc
Active Member
Posts: 54
Joined: Fri Mar 04, 2011 3:38 pm

Postby xsamc » Tue Sep 12, 2017 3:23 pm

KurtOz wrote:Is there any field that I can insert those extra flags, or should I directly edit the Makefile at source level as:

Switching to the "Source" tab in the Makefile editor allows you to edit parts of the Makefile for which there aren't fields in the "Options" view. The "Options" view is just editing the Makefile for you behind the scenes though, so not having a field for this shouldn't stop you from using it for the rest.

KurtOz wrote:XCC_EXTRA_MAP_FLAGS = -L . lloader -Xmapper --first -Xmapper ./loader_pre_crt.o ./loader_init.o
...
Even if I include as shown above make fails by complaining about not finding loader_init.o file. All the loader files are copied at the project directory top level.


I'm not very familiar with the mapper flags myself, but have you tried adding "-Xmapper" before "./loader_init.o"?

Cheers,
Sam
KurtOz
Junior Member
Posts: 5
Joined: Tue Jul 04, 2017 7:56 pm

Postby KurtOz » Fri Oct 06, 2017 7:06 am

Thank you for your reply. You are right. It is better to work on the Source edit mode and set the flags there. I have tried several schemes, including your suggestion but none of them worked. It is hard to guess about how to edit those fields without knowing the rules running on background.

Thanks again.
robertxmos
Experienced Member
Posts: 105
Joined: Fri Oct 23, 2015 10:23 am

Postby robertxmos » Fri Oct 06, 2017 5:07 pm

Hi KirtOz
As an overview, the flags are passed to the xcc driver, the driver then calls the necessary tools (compiler, assembler, linker/mapper) forwarding relevant flags.
N.B. .o files are correctly handled by the xcc driver and forward to the mapper.

Sometime you will want to pass a flag to a particular tool, through the xcc driver.
This is the case when telling the mapper to place the contents of an objects code before it places other object code (early in each memory section) viz

Code: Select all

--first  ./loader_pre_crt.o

The xcc driver wont understand, so we tell it to blindly forward the details of the two tokens to the mapper (see xcc --help) viz

Code: Select all

-Xmapper --first -Xmapper ./loader_pre_crt.o

It should be noticed that the mapper will probably be running in the .build directory not the project directory thus the file is <project root>/.build/loader_pre_crt.o

The XCC_EXTRA_MAP_FLAGS is passed to the xcc driver when it finally tries to build the app. Thus is a suitable place to insert a source loader_init.o.
(There is no need to add the extra -Xmaper) BUT the path of the .o file must be relative to the .build directory.
Assuming you have placed the .o in <project root>/objCode/loader_init.o I would suggest you try (turning on -v for verbosity):

Code: Select all

XCC_EXTRA_MAP_FLAGS = -L . lloader -Xmapper --first -Xmapper ./loader_pre_crt.o    ../objCode/loader_init.o -v


If you continue to have trouble, please upload the command line output and the location of the loader_init.o file.

robert
shdrmr
Junior Member
Posts: 5
Joined: Tue Oct 17, 2017 4:47 pm

Postby shdrmr » Tue Oct 17, 2017 5:02 pm

Hey, were u succesful in booting in SPI SLave, I am not able to transfer the image in my SLICEKIT X200
KurtOz
Junior Member
Posts: 5
Joined: Tue Jul 04, 2017 7:56 pm

Postby KurtOz » Mon Nov 06, 2017 8:02 pm

I was successful loading binary image to my XU210 via SPI Slave boot. I would like to thank you robertxmos for his insightful comments. There is an important issue that everybody who utilize SPI Slave booting, should know. The SPI Select line should be asserted (LOW) during the boot loading; if your SPI select line switches between HI and LO during each byte transfer then your boot loading fails. If your host doesn't support such a feature I would suggest to use a GPIO line as SPI select instead of built-in CSS line of your host SPI engine. Before SPI loading we have inserted 1ms wait time once the reset line asserted and de-asserted again. In another words, our boot loading flow is:
Reset LO -> wait 1ms -> Reset HI -> wait 1ms -> program (Baud rate=2.5KHz, CPHA=CPOl=1, LSBFirst).
I have tried with 5ms wait time and it worked also.

I should add that our boot loading is successful under Both X0D06/X0D05/X0D04 = 011 and 010. The tools provided by the code support of the application note AN00238 are used. That mode, unfortunately has code size limitation of 256K. I haven't figured out yet how to use X0D06/X0D05/X0D04 = 011 option to program code images whose size is larger than 256K. I will submit that part as a separate post later.

Return to “Development Tools and Programming”

Who is online

Users browsing this forum: No registered users and 14 guests