<div dir="ltr">As you suspect, you should not use printf() before the open on /dev/console<div>that actually opens stdin, out, and error. Before that point, you can use</div><div>printk() but on some BSPs, that doesn't work until the console initialization</div><div>method is invoked. I suspect it will work on the Leon2 if you have grmon</div><div>since you can rely on that initialization.</div><div><br></div><div>You also should not invoke printf() from interrupt handlers.</div><div><br></div><div>If the console device is polled on this BSP (and in this configuration since</div><div>it is often a BSP option), then it could be periodically filling out the</div><div>TX buffer on the UART and then hanging until all the output is gone.</div><div>I don't know the buffer depth on the UART. But short prints at the</div><div>right rate could go into the TX buffer and out without  you </div><div>delaying.</div><div><br></div><div>--joel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 25, 2017 at 2:34 AM, Chris Coppens <span dir="ltr"><<a href="mailto:Chris.Coppens@topicproducts.com" target="_blank">Chris.Coppens@topicproducts.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
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.<br>
We load the driver, by defining it in a “system.h” file that includes “confdefs.h”. System configuration looks like this:<br>
<br>
…<br>
// our driver:<br>
#define CONFIGURE_APPLICATION_EXTRA_<wbr>DRIVERS DYPLO_DRIVER_TABLE_ENTRY<br>
#define CONFIGURE_APPLICATION_NEEDS_<wbr>CONSOLE_DRIVER<br>
#define CONFIGURE_APPLICATION_NEEDS_<wbr>CLOCK_DRIVER<br>
<br>
#define CONFIGURE_EXECUTIVE_RAM_SIZE    (64*1024*1024)<br>
#define CONFIGURE_STACK_SPACE_SIZE      (1024*1024)<br>
#define CONFIGURE_MAXIMUM_TASKS             5<br>
#define CONFIGURE_MAXIMUM_SEMAPHORES    64<br>
#define CONFIGURE_MINIMUM_TASK_STACK_<wbr>SIZE 512<br>
#define CONFIGURE_RTEMS_INIT_TASKS_<wbr>TABLE<br>
#define CONFIGURE_MICROSECONDS_PER_<wbr>TICK 1000<br>
#define CONFIGURE_APPLICATION_NEEDS_<wbr>LIBBLOCK<br>
#define CONFIGURE_INTERRUPT_STACK_SIZE 8192*4<br>
#define CONFIGURE_LIBIO_MAXIMUM_FILE_<wbr>DESCRIPTORS 64<br>
#define CONFIGURE_USE_IMFS_AS_BASE_<wbr>FILESYSTEM<br>
<br>
#include <rtems/confdefs.h><br>
…<br>
<br>
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).<br>
<br>
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?<br>
<br>
Thanks for any help.<br>
<br>
Kind regards,<br>
Chris<br>
<br>
<br>
<br>
<br>
<br>
<br>
Kind regards,<br>
<br>
Chris Coppens<br>
Software Designer<br>
<br>
TOPIC Products<br>
Materiaalweg 4, NL-5681 RJ Best<br>
Postbus 440, NL-5680 AK Best<br>
Telefoon: +31 (0) 499 33 69 79<br>
E-mail: Chris.Coppens@TopicProducts.<wbr>com<br>
Website: <a href="http://www.topicproducts.com" rel="noreferrer" target="_blank">www.topicproducts.com</a><br>
<br>
Please consider the environment before printing this e-mail<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a></blockquote></div><br></div>