Thanks Greg, this helps me understand better how it all hangs together. Regards,
Tim. > On 17 Aug 2023, at 21:33, Gregory Nutt <spudan...@gmail.com> wrote: > > >> On 8/17/2023 10:34 AM, Tim Hardisty wrote: >> I have concluded that CDC/ACM will NOT play alongside SYSLOG - most likely >> on the SAMA5D2 device, or possibly just on my board for some reason. >> >> Whatever I choose as the SYSLOG output (/dev/ttyS0, ttyS1, ttyFC0 and ttyFC1 >> all of which are working fine, or even /dev/null) it just ends up garbling >> received data from the USB. >> >> I have left CONFIG_CDCACM_NRDREQ=1, disabled SYSLOG and can move forward as >> this is only needed for the board test jig, so I don't need a TTL->USB >> converter cable to see output. >> >> Can return to it if anyone has any ideas but, if not, will log both as >> issues for someone to pick up at some point in the future, maybe. >> >>> On 17/08/2023 16:06, Tim Hardisty wrote: >>> OK...progress. >>> >>> CDC/ACM console behaves like this if CONFIG_CDCACM_NRDREQS is left at the >>> default 4. It needs a given keyboard key to be pressed 4 times to work, >>> and/or garbles the text sent. I also found that usbserial example app >>> misbehaves in the same way - I thought it was working since random >>> characters were being pressed by me to test it...and received as garbled >>> random characters and I didn't notice. >>> >>> If set to 1 it works. I do not know why this is. >>> >>> If this is a bug not some configuration error/mismatch I've not spotted >>> then I will raise it as an issue. >>> >>> But it doesn't play nicely with syslog...I'm investigating that now. >>> > Certainly you cannot use the console device for syslog because it there is no > console device when you use USB for the console output. Non-console TTYs are > not available at power up. Only the console serial device (if there is one) > is initialized in that case. They do become available later, but after > syslog is already been initialized. So there may be some initialization > issue in the way you use it. > > I think there is an option to force late syslog initialization, but I can't > remember now (and this has probably been redesigned since I wrote it anyway). > > When I use a USB console, I normally output syslog to a circular buffer (I > forget all of the Kconfig options, but they should not be to hard to find). > Then I enable the NSH dmesg command. That will dump the output of the > syslog data from the circular buffer to the USB console, clearing the buffer. > Since buffering is available immediately after power up, no boot-up data is > lost. You just have to remember to enter the dmesg NSH command periodically. > You can do that with an NSH script running in the background. > >
