Why does the printf debug only print weird symbols?

Well, yes I want to print the UART stream and certain events. Where do you set the baudrate then? I haven’t really found an option.

Setting the baudrate is part of configuring the UART.

See your chip documentation for how to configure its UART(s)

You can do it wherever you like - but it has to be done before you start using the UART!

Yes there are UART config files, but no matter which baudrate I set, I don't get clear text. I was playing around a little and used the simulator for debugging. With the simulated debugger I get clear text, so it must be some settings. I also just have a 10 pin connector and a ULINK2 ME. I believe it has reduced debugging capabilites, doesn't it?

Where do you connect the oscilloscope to check this? I am a total newbie. 

I know how UART works. I already tried to measure at the pins. I don't see anything on the oscilloscope.

if you know how a UART works, you should understand that it sends data out on its TX pin, and receives data in from its RX pin.

So those are the pins that you need to look at with your scope to see if there's any activity:

• If there's no activity on the TX pin, then nothing is getting out from the UART;
• If there's no activity on the RX pin, then nothing is arriving for the UART to receive.

But you said you see junk on your terminal - which means that something must be getting out!

I think those are just printf statements printing something to the screen. There is nothing getting out or I am on the wrong pins, but they are the ones the designer told me to use. But even when there was a device connected and I got a signal from it, nothing was visible on the scope. I give up... Thank you for your help!

A screenshot to show where (and/or how) you're looking at the output and what weird symbols look like would be helpful. You've described using the simulator and trying to use the ULINK debugger, both of which have good support for printf(). Usually, the printf() function is not redirected to a real UART unless you choose to redirect through 'User' code (which requires support functions to be written). If this hasn't been done then printf() wouldn't generate data on the physical UART, which might explain the lack of signal when using the 'scope. 

Here's an example (for an MCB1800 dev board, which uses an LPC1857) where STDIO is configured to use the EventRecorder (using the RTE Manager, under Compiler > IO):

#include <LPC18xx.h>
#include <EventRecorder.h>
#include <stdio.h>

int main(void)
{
   SystemInit();
   SystemCoreClockUpdate();
   EventRecorderInitialize(EventRecordAll, 1 );
   printf("Hello, world!\n");
}

Which leads to:

That approach Just Works(TM). Selecting ITM for STDIO output in the RTE Manager requires Trace configuration in the debug settings. (Note that my core clock is 180 MHz -- the variable SystemCoreClock holds the current clock rate, which you can inspect with the debugger.) Rebuild and run to get the same output in the debug (printf) window. 

Almost all of those settings are defaults. The ULINK link rate is much slower than the MCU core clock, so it can fall behind if you send a lot of data. The IDE will tell you when you're falling behind (MCU generating more data than the ULINK can transport) with messages in the status bar at the bottom of the screen. It can be more efficient to use EventRecorder to pass data to the PC host, and have the PC pretty-print the data.

Also: 'Xtal (MHz)' is not guaranteed to be the clock rate used by the core. Typically, the MCU's on-board PLL is configured after reset to generate a higher frequency clock derived from the external crystal. E.g., 120 MHz. Look for a function named SystemInit() in your project -- the core clock will very likely be set there. 

And don't worry about the RTC clock. It's almost certainly not relevant to what you're doing with printf().

My colleague helped me at last and we we found the problem. We had to uncheck all trace events, especially "Exception tracing". Thank you for your help!