2

i tried Grabserial to measure the startup code of my embedded Linux device. It works somehow but after a while (that means a longer startup code - talking about > 26 s) it stops printing out the messages, but grabserial still is running - i have to hit the [CTRL-C] to retrieve control. I checked the serial port with putty and it's working so it's a problem with grabserial. But i can't think of what it is.

I downloaded and installed with both of the 2 install-variants and it just changed the look-and-feel but stucks at the same point.

Does anyone ever had the same problem ?

Greets

[edit:] i just checked the code, it's nothing special and actually should just break when [CTRL-C] or a timer was set and running out. But the program doesn't even break it just stops printing to console.

[edit2:] i found out, that script is too slow for processing. It seems like it only can output information when something has been sent by the serial line (like an interrupt), but it's like 2 letters transmitted but only 1 is shown. Since the script-processing is slower than booting i can't see everything, only the stuff it managed to show until my device finishes booting. I tried this with a reboot-loop process, so it gets new messages over and over again, and it never stopped printing out.

I still need support for this, does anyone have smart solution before i have to code it by my own?

user3085931
  • 1,757
  • 4
  • 29
  • 55
  • after 26s your kernel should be ok, maybe there's no more messages written on serial by the device, no ? – Mali Dec 11 '13 at 12:20
  • no it takes about 30 s... I just mention 26 s because that's the number when it stops. I just realized the last 5 commands is about initializing the ATMEL_SERIAL (i'm working on an AT91 9SAMG25). But again, with my Serial Console (Putty) i can go further without any problems – user3085931 Dec 11 '13 at 12:51
  • Speculation, but if this is software running on a different machine from the kernel in question, communicating over a true serial port, then I'd wonder if perhaps the kernel serial (re)configuration stage is causing a framing error or similar, and this client software doesn't clear the resulting receiver fault, while the terminal program tried in comparison does. Or perhaps this program tries to be "smart" and only collect until a certain condition is met, which is false triggering. – Chris Stratton Dec 11 '13 at 17:21

1 Answers1

1

I've just started using grabserial and I've not reproduced your problem. Current grabserial (1.6.0) does have an option to autostop your program.

-e, --endtime=<secs> End the program after the specified seconds have elapsed.

In case it could help, this is my command line (I've downloaded it from git)

./grabserial -v -d "/dev/ttyUSB1" -b 115200 -w 8 -p N -s 1  -t
kikeenrique
  • 2,589
  • 2
  • 25
  • 46
  • I already wrote the developer on github, they couldn't reproduce either :/. By the way i could manage to boot my system in 5 s (i know by counting by myself) and grabserial says it's 15 s. I really don't have a clue. I believe it's caused by the Linux Mint I'm using. – user3085931 Jan 31 '14 at 06:56
  • 1
    @user3085931 Could it be a hardware issue? You can use an alternative method: *cat /dev/ttyUSB0 | ts [%H.%M.%.S] > ${FILENAME}* – kikeenrique Jan 31 '14 at 09:27
  • this is a good method, the results are nearly the same as when i measure the time with an oszilloscope via GPIO. – user3085931 Jan 31 '14 at 13:29