no support for asynchronous ITM about orbuculum

[mubes]

The problem with this is that you can only use temporal information to synchronise the ITM in the absence of sync packets. The easiest hack is what you've done, to just force the ITM to be synced. In that case, if an ITM Sync arrives, everything will be re-synched, but if it doesn't with the current arrnagement then once you're out of sync you stay there...which is not nice. Need to think on this one.

[karlp]

"try harder" :) you can detect most things by just discarding invalid sequences. it tends to actually resync quicker than you think. (I've written parsers for this before, but yours has more bits in it that I don't want to handle myself) See http://git.zapb.de/libswo.git/ for one implementation, I handled it less gracefully in https://github.com/karlp/swopy (which worked but was a kinda fragile PoC)

sync packets are a serious intrusion on the bandwidth available, and I've been using this already for the last few weeks with just the HACK: commit referenced above.

[mubes]

Karl,

Once it's synced it won't unsync unless it's told to by the TPIU (which won't happen with no TPIU in stream) so all that's needed is to start off initially synced rather than not synced. When an non-understood or corrupt packet arrives the default is to drop back to the idle state anyway (see the ITM_HW, ITM_SW, ITM_TS and ITM_EXTENSION states) so by your logic it should re-sync very quickly.....but the consequence is likely to be 'noise' packets from time to time so it might need to be a switchable option, especially given that the codespace for the first octet is very full....there aren't many invalid sequences!

Main focus for past few weeks has been on increasing the available b/w via parallel trace rather than reducing the amount of traffic :-)

To implement this change you don't need to change each program in the suite, just change line 48 of itmDecoder.c to be i->p=ITM_IDLE rather than ITM_UNSYNCED.

For now I'll leave this open, but do report back on how it behaves for you. If the current state machine does fall into sync then I'm happy to add a command line switch to enable this behaviour with a suitable warning about the potential for noise in the readme.

[mubes]

OK, I've added a -n command line switch to force the ITM into sync'ed mode on all of the tools, cos I can see some use cases where that might be handy.

However (and it's quite a big however), I did a bit of testing recording 60 seconds of PC samples as an example data flow. During that time 17 ITM Syncs were received, while 1080704 octets of real ITM traffic arrived at the same time. Given that an ITM Sync is 6 octets that means that the overhead for including Syncs in that traffic flow was about 0.01%. You can send Syncs more quickly if you wish, but that gives you some idea of the 'cost' of including them.

Don't believe everything you read in Arm documentation :-)

DAVE

[karlp]

That.... doesn't match my experience, I saw far more syncs. but ok. cool :) -n will work for me :)

[mubes]

Well, you can make it spit them out more often - it depends on where you place the SYNCTAP in DWT_CTRL of course. This is the least frequent you will get them if you've got it enabled. You can tap at CYCNT[24], CYCCNT[26] or CYCCNT[28]. My core was running at 72MHz and I was on CYCCNT[28] which is 3.728secs/sync ~= 16 syncs/min (which is what I saw). At its most frequent you would get 257 of them per min on CYCCNT[24], giving you an overhead in my use case of about 0.15%. Either way, not a whole hill of beans. When you start switching on things like timestamping then thats a different matter, and you'll very quickly overfill the channel. Anyway, feel free to use -n :-)

See http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0337e/ch11s05s01.html for more.

[mubes]

OK, I'm convinced on this one...when using the tools with JLink no syncs are issued, which means they sit silently until you figure out what's wrong. I've inverted the sense of the '-n' switch to make it enforce rather than relax the SYNC requirement. Sending you this note 'cos its likely to burn you and your scripts otherwise when you upgrade.