XCore Exchange

This probably has been answered here before. I have, to be honest, wondered about this for years..

But now I have some code that seems to behave differently when xgdb'ed or xflash'ed.

What happens to my debug_printf calls (lib_logging) when the code is xflashed? Using xTIMEcomposer 14.4.1.

I have done nothing during the build to remove them for any special xflash'able code. Should I?

Or will xflash replace them with nops, put in stubs to make the code not do anything, or whatever?

Update: The different behavior is suspected for cases where there is no printing. I know that printing via XTAG blocks the processor.

Øyvind

Hey Øyvind,
I've actually encountered similar issues where a xe program behaves differently when run under xrun vs when flashed using xflash.

Eventually, after flashing the firmware using dfu, similar issues disappeared.

But this happened so rarely that I suspect what's going on under xgdb and xflash is not exactly what I imagined.

Vergil19,

for my case it's just a "feeling", because all of a sudden my problem has evaporated - in xgdb. The xflash'ed system kind of was the reference. This may or may not be a correct observation.

Cannot find "dfu" in the xTIMEcomposer manual. What is it? (df seems to be a unix command..)

But now, what happens with the lib_logging calls (and perhaps other debugger command) with the xe file when it's xflashed?

I've not been able to find a way to use debug_printf() via xscope with flashed devices. The only time I've needed to do this is where I'm using more than one xmos system simultaneously, but then I found that I could run multiple targets by identifying them in separate xrun instances. That might help.

DFU: https://en.wikipedia.org/wiki/USB#Devic ... _mechanism

Just to be clear, I've never missed depub_printf() from xflashed code.

I just wondered what happens with that code when it's xflashed. Assuming that it's the same starting point .xe file that's xgdb'ed and xflash'ed.

Ok, so DFU is Device Firmware Upgrade (DFU), Thanks!

The starKIT didn't use XTAG externally, y´there - but I (again) asuume that the bootloader and programming tool was xTIMEcomposer, not DFU..

I thought this could not be left open. From:

xTIMEcomposer User Guide. Tools Version: 14.0.x, Publication Date: 2015/10/29, chapter 32 XFLASH Command-Line Manual (pp 223) it's obvious that the downloaded binary comes from separate builds. If I do an "xflash myfile.xe --verbose" I see that at least these commands are run:

xgdb
libcompressor
Stage2_Loader::Compile : xcc
XFlash_Programmer_Program::IssueCompileCommand :xcc

Watching the .bin directory I also see a bunch of intermediate files appearing.

So I guess there might be situations where code will run in xgdb and not as xflashed. I have one such right now, which I will try to "resolve" by just not xflash'ing for a while and then see if the problem has disappeared on a next xflash. If not I attack main.xc and use my gut feeling.