Printf UART usage issues

[Joel Sherrill]

As you suspect, you should not use printf() before the open on /dev/console
that actually opens stdin, out, and error. Before that point, you can use
printk() but on some BSPs, that doesn't work until the console
initialization
method is invoked. I suspect it will work on the Leon2 if you have grmon
since you can rely on that initialization.

You also should not invoke printf() from interrupt handlers.

If the console device is polled on this BSP (and in this configuration since
it is often a BSP option), then it could be periodically filling out the
TX buffer on the UART and then hanging until all the output is gone.
I don't know the buffer depth on the UART. But short prints at the
right rate could go into the TX buffer and out without  you
delaying.

--joel

On Tue, Apr 25, 2017 at 2:34 AM, Chris Coppens <
Chris.Coppens at topicproducts.com> wrote:

> Hello,
>
> I am developing an RTEMS 4.11 driver. The environment we are using is a
> LEON2 CPU with GRMON debug tool connected to UART debug link.
> We load the driver, by defining it in a “system.h” file that includes
> “confdefs.h”. System configuration looks like this:
>
> …
> // our driver:
> #define CONFIGURE_APPLICATION_EXTRA_DRIVERS DYPLO_DRIVER_TABLE_ENTRY
> #define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
> #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
>
> #define CONFIGURE_EXECUTIVE_RAM_SIZE    (64*1024*1024)
> #define CONFIGURE_STACK_SPACE_SIZE      (1024*1024)
> #define CONFIGURE_MAXIMUM_TASKS             5
> #define CONFIGURE_MAXIMUM_SEMAPHORES    64
> #define CONFIGURE_MINIMUM_TASK_STACK_SIZE 512
> #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
> #define CONFIGURE_MICROSECONDS_PER_TICK 1000
> #define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK
> #define CONFIGURE_INTERRUPT_STACK_SIZE 8192*4
> #define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 64
> #define CONFIGURE_USE_IMFS_AS_BASE_FILESYSTEM
>
> #include <rtems/confdefs.h>
> …
>
> We do many printf’s, both in Driver initialize context(thread), but also
> in Application tasks. We did not change the console driver configuration,
> so I’m guessing the console driver in “Polled mode” (correct me if I'm
> wrong).  The printf’s we are doing during driver initialization we are not
> seeing. Probably because I read that the /dev/console file is created after
> loading all drivers (post_bsp hook).
>
> The problem we are encountering is that sometimes during printf the UART
> (debug) communication link seems to fail and the application does not
> respond anymore. Has someone else had issues using printf from different
> contexts? Are there any guidelines for the point in time when we can
> actually start using printf? Any idea what may be the issue with the UART
> stability using printfs?
>
> Thanks for any help.
>
> Kind regards,
> Chris
>
>
>
>
>
>
> Kind regards,
>
> Chris Coppens
> Software Designer
>
> TOPIC Products
> Materiaalweg 4, NL-5681 RJ Best
> Postbus 440, NL-5680 AK Best
> Telefoon: +31 (0) 499 33 69 79
> E-mail: Chris.Coppens at TopicProducts.com
> Website: www.topicproducts.com
>
> Please consider the environment before printing this e-mail
>
>
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20170425/a01d9102/attachment-0002.html>