Why does the printf debug only print weird symbols?

you usually call it screen when you use printf

No - not on a microcontroller!

It could be a UART, or an LCD, or ...

I have little experience with microcontrollers or RTOSs and am supposed to fix someone else's code, that I obviously can't debug. 

Oh dear.

Hope you can sort out with management to either get someone appropriately skilled to do it, or to help you with it.

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!