debug_printf and xflash'ed vs. xgdb'ed code (14.4.1) Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 498
Joined: Wed Apr 25, 2012 8:52 pm

debug_printf and xflash'ed vs. xgdb'ed code (14.4.1)

Post by aclassifier »

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
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
View Solution
User avatar
vergil19
Member++
Posts: 22
Joined: Thu Jan 20, 2022 3:54 am

Post by vergil19 »

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.
User avatar
aclassifier
Respected Member
Posts: 498
Joined: Wed Apr 25, 2012 8:52 pm

Post by aclassifier »

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?
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
CousinItt
Respected Member
Posts: 365
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

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
User avatar
aclassifier
Respected Member
Posts: 498
Joined: Wed Apr 25, 2012 8:52 pm

Post by aclassifier »

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..
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
aclassifier
Respected Member
Posts: 498
Joined: Wed Apr 25, 2012 8:52 pm

Post by aclassifier »

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.
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/