file input runs and exits before clients can connect about orbuculum

[karlp]

I tried this again recently by trying to configure openocd to write the swo trace to a fifo instead of a file, and telling orbuculum to read from teh fifo. It now at least "runs" but it doesn't seem to get any data from it, it just sits there. I know openocd's writing to the fifo, because I can manually cat it and get the swo trace I expect.

[karlp]

Solution here is to just use netcat with openocd's captured file. In this case, using plain STLink hardware.

# openocd configured to write to swo.dump.log via...
tpiu config internal swo.dump.log uart off <corespeedinhz>

$ tail -f swo.dump.log | nc -v -v -l 9999 -k

And orbuculum in another window reading that. It's not really "segger" format, it's just "raw swo pin data"

./ofiles/orbuculum -g 9999 -b md/ -c 0,text,"%c"

Perhaps this can just be addressed as documentation, rather than trying to make it follow the file itself.

[mubes]

Originally the file input mode was really just there for development purposes. It doesn't work well because of the timing relations that are implicit in the tpiu decoder....and, as you've found, it doesn't wait for data to arrive in the file.

I'll leave this open for now and look at enhancing the file handling to wait for data so it can be used with tools like openocd. I've added some documentation to the README referencing this thread too.

Sorry this has taken a while to respond to....been away creating the parallel trace fpga configuration, but now is time to solidify the core apps.

[karlp]

no problem, glad to see you back again :) the tail -f | nc is working very well anyway, just wasn't going to make a bunch of PRs for documentation on that sort of thing.

[mubes]

If you look in the Devel branch I added the file tracking capability but it's not extensively tested. It now won't drop out at the end of the file but rather will continue to wait for new input (CTRL-C to interrupt). Please give it a try and see if it avoids you needing the nc hack. There are some other not well tested changes in that branch too so ymmv but I think it should be a reasonably safe experiment.

[karlp]

Hrm, I don't really see anything in the Devel branch that adds this? It's a bit hard to see from your commits though, you've only got a single commit there which fixes mkdir, changes transfer sizes for everyone and then a whole pile of seemingly irrelevant EOL printf changes all in the same commit. Are you missing a git push from your end perhaps?

[mubes]

User to dumb to use git. Replace user and press any key. I'll commit the change tomorrow when I'm back in front of the machine that has the development code on it. Dave

…

On 9 Oct 2017 1:39 pm, "Karl Palsson" ***@***.***> wrote: Hrm, I don't really see anything in the Devel branch that adds this? It's a bit hard to see from your commits though, you've only got a single commit there which fixes mkdir, changes transfer sizes for everyone and then a whole pile of seemingly irrelevant EOL printf changes all in the same commit. Are you missing a git push from your end perhaps? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFMwj-8WOdGWVG9d7tjMliCkpvNl5WsGks5sqhPpgaJpZM4PGrPg> .

[mubes]

OK. Please give that a try on the Devel branch. If it works for you I'll close off this PR.

Dave

[karlp]

Yep, this works, as long as I still have my "force itm sync" hack. but that's a different issue, so this can be closed thanks!