I am trying to debug a programm written by someone else using the printf debug function, but I only get weird symbols. Is it possible that the baudrate is not correct?
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?
no matter which baudrate I set, I don't get clear text
So think about what that tells you: there must be some systematic flaw in your setup.
Check your clock source!
Have you used an oscilloscope or analyser to check what baud rate you are actually getting?
With the simulated debugger I get clear text,
That's because the simulator just uses the PC's COM port - it's not actually simulating the operation of the UART.
A uLink-ME is fine for this.
Where do you connect the oscilloscope to check this? I am a total newbie.
Maybe start here: https://learn.sparkfun.com/tutorials/serial-communication
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:
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!
the screen
What "screen" ?
Remember that we can't see your setup, or what you're doing - we have no idea what you're looking at!
the designer told me
So can't you get this person to help you? Or some other colleague(s) ?
It's far better to get someone who can actually sit with you and see what you're doing and what's happening than for a complete stranger with no idea of your setup to try to do it remotely!
Andy Neil said:What "screen" ?
Well, you usually call it screen when you use printf. In this case it is the debug window of course.
Andy Neil said:Remember that we can't see your setup
Yes, of course. Thank you for trying though!
Andy Neil said:So can't you get this person to help you? Or some other colleague(s) ?
I've asked for it multiple times. He doesn't want to help me or doesn't have the time. I have little experience with microcontrollers or RTOSs and am supposed to fix someone else's code, that I obviously can't debug.
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.
Andy Neil said:It could be a UART, or an LCD
Alright, thank you for pointing that out.
Andy Neil said:Hope you can sort out with management to either get someone appropriately skilled to do it, or to help you with it.
Well, I guess for now I will have to keep trying. I have been playing around with the clock rates now. So in µVision there is the
* Xtal (Mhz) - I assume this is the clock rate that the µC is running with, which is supplied by the quartz.
* JTAG Max Clock - Probably the clock rate the JTAG is flashing with, so not relevant
* Trace Core Clock - I assume the clock rate that the traces are recorded with
The tutorials say in order to get printf debug to work you have to set the trace clock to the same rate as the µC clock. But no matter which clock rate I use, I get garbage on the terminal. The LPC1769 supports clock rates up to 120 MHz, but the connected quartz on this board runs with 12Mhz. There is also an oscillator for the RTC of 32kHz. Don't know if I have to consider this.
So the µC is set to 12 MHz and the trace core clock is initially set to 10 MHz. If I set the core clock to 12 MHz as well, it does not improve the output. The prescaler in "Timestamps" is set to 1 and the one in "PC Sampling" is set to 1024*16. My UART connections are initially set to 1MBd, but can be set to 9600 Bd, 115200 Bd and 2 MBd. I can not set a baud rate in the Keil terminal, so there is no way to match them. I have been playing around a lot with clock rates and the prescaler (don't know if that matters here). Does this provide any useful information to you, where the mistake could lie?
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!