10.4 Tools Bug?

[jonathan]

I'm using the SPI example from XMOS

Code: Select all

	//configure_clock_rate(blk1, 50, SPI_CLOCK_DIV);
	configure_clock_rate(blk1, 50, 10);

If I use the first (commented out) line and define SPI_CLOCK_DIV in an included header file, changing it between successive simulations doesn't seem to get picked up - the previous value is used in that simulation. I think I can only get the change in the header file picked up by creating a new debug configuration!

If I use the second (uncommented out) line and just input constant values into the function, these get picked up in successive simulation runs.

Can someone else verify that this isn't just an oddity of my installation (which should be pretty standard?).

[Andy]

Have you checked to see it is actually recompiling the file you have changed? Sometimes Eclipse doesn't seem to recognise you have edited a file and just runs the old binary (I experienced this on the 9.9 release).

[jonathan]

Have you checked to see it is actually recompiling the file you have changed? Sometimes Eclipse doesn't seem to recognise you have edited a file and just runs the old binary (I experienced this on the 9.9 release).

Well put it this way.

If I just change the header file, it claims it has no work to do, so I guess it just reads the old binary.

**** Build of configuration Debug for project kent ****

xmake all
xmake: Nothing to be done for `all'.

If I change the header file *and* the XC code (for example, send a different command) it knows it has to recompile and invokes as follows.

**** Build of configuration Debug for project kent ****

xmake all
Building file: ../kent_test.xc
Invoking: XC Compiler
xcc -O0 -g -Wall -c -o "kent_test.o" "../kent_test.xc" "../XC-1A.xn"
Finished building: ../kent_test.xc

Building target: kent.xe
Invoking: Mapper/Linker
xcc -Werror=timing-syntax -o "kent.xe" ./kent.o ./kent_test.o ../XC-1A.xn
Finished building target: kent.xe

So it does, but it still doesn't pick up the change in the header file!

So basically it seems that it won't pick up changes to constants defined in header files between simulation runs, even on a recompile? Really? That can't be "Eclipse's fault" can it...?

[mike]

Can you describe how you imported the SPI app into the XDE and added your own source? Also, which version of the tools and SPI module are you using? Our apps use standard makefiles rather than the managed build which you get when you create XC projects, but it looks like your project is also using managed build for some reason.

[jonathan]

Can you describe how you imported the SPI app into the XDE and added your own source? Also, which version of the tools and SPI module are you using? Our apps use standard makefiles rather than the managed build which you get when you create XC projects, but it looks like your project is also using managed build for some reason.

I created an XC project and then added two XC files (kent.xc kent_test.xc) using File->New->Source File and then pasted the contents in. Then created the header file (kent.h) using File->New->Header File and pasted those contents in. So this wasn't really a question of using any pre-configured XMOS SPI stuff - this was just using raw source files...

[jonathan]

Can you describe how you imported the SPI app into the XDE and added your own source? Also, which version of the tools and SPI module are you using? Our apps use standard makefiles rather than the managed build which you get when you create XC projects, but it looks like your project is also using managed build for some reason.

Tools version 10.4 and a slightly modified version of the standard SPI code that I originally downloaded a few months ago. But surely the SPI version doesn't matter? This is a question of a few source files and a header....

[mike]

Yeah this looks like a managed build issue in XDE. The workaround for now would be to do a clean each time.

[jonathan]

Yeah this looks like a managed build issue in XDE. The workaround for now would be to do a clean each time.

OK, thanks.

Do I need to report a bug or have you raised it?

[mike]

No I've created a bug on our internal system, we'll look at getting this resolved in the next tools release.

Mike