Printf UART usage issues

Thu May 11 12:55:52 UTC 2017

Thanks for the advice Joel.
We still saw the same issues with the UART port when using printk.

After a long search we found out that our problem occurred due to the fact that we are running a Virtual Machine for our development and some of the VM’s UART drivers didn’t function properly, causing the Debug Support Unit’s UART in GRMON to fail after some time.
Switching to a Native OS fixed the issue.

From: Joel Sherrill [mailto:joel at rtems.org]
Sent: woensdag 26 april 2017 1:25
To: Chris Coppens
Cc: users at rtems.org
Subject: Re: Printf UART usage issues

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

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

Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

_______________________________________________
users mailing list
users at rtems.org
http://lists.rtems.org/mailman/listinfo/users