Teach lesson
STM32 Mbed CodeIDE (4/8): serial debugging with printf
Students use printf serial debugging in STM32 Mbed CodeIDE to compare expected and actual behavior, then fix a mismatch with evidence.
Learning Outcomes
Use
printf()to observe what a running Mbed program is doing.Print integer values instead of relying on floating point formatting.
Use serial output to debug one controlled change at a time.
Student activity preview
Activity Content
Preview only. In a class session, students can fill in responses and submit their work to the teacher.
Why serial output matters
8 min
When a controller does not behave as expected, guessing is slow. Serial output lets you print values and checkpoints:
printf("cycle=%d led=%d\n", cycle, led_state);In these Mbed programs, printf() sends text from the running STM32 board to the serial console in CodeIDE. The %d markers are replaced by integer values, and \n starts a new line so each reading is easier to copy.
This course uses integer serial output. In this Mbed environment, floating-point printf("%f") output is not a good first debugging tool. Use integers such as milliseconds, millivolts, percentages, and degrees.
In the STM32 Mbed CodeIDE lab, serial output appears in the console panel near the bottom of the lab view. CodeIDE manages the USB serial connection and baud rate for you; just compile, upload, and read the printed lines.
Where to read serial output
After upload, read the console/status area near the bottom of CodeIDE. That is where lines printed by printf() appear.
What information would you print if an LED sequence looked wrong: the cycle number, the LED state, the delay value, or something else?
Print a running heartbeat
26 min
Open the STM32 Mbed CodeIDE lab.
Open
main.cpp.Replace the file with the program below.
Save, compile, and upload.
Open or watch the serial console area in CodeIDE.
Observe the serial lines and confirm that the cycle number increases while the LED changes.
Copy at least three serial lines before changing the program.
#include "mbed.h"
DigitalOut status_led(PB_5, 0);
int main() {
int cycle = 0;
const int delay_ms = 500;
const auto delay_time = 500ms;
printf("STM32 Mbed serial debug start\n");
while (true) {
status_led = !status_led.read();
cycle = cycle + 1;
printf("cycle=%d led=%d delay_ms=%d\n", cycle, status_led.read(), delay_ms);
ThisThread::sleep_for(delay_time);
}
}The first lines should look similar to this:
STM32 Mbed serial debug start
cycle=1 led=1 delay_ms=500
cycle=2 led=0 delay_ms=500
cycle=3 led=1 delay_ms=500Fill three table rows using three different cycle=... serial lines, not the startup line. In Console line copied, paste the full line. In Visible LED behavior, record the visible LED state that matches the printed led value, for example on or off. In What this tells me, write a short interpretation, for example "cycle increased by 1 each blink" or "printed delay matched the wait in code."
Serial evidence table
| Console line copied | Visible LED behavior | What this tells me |
|---|---|---|
Use one table row to explain how the serial output helped you connect the code to the physical LED behavior. Name the printed value and the matching visible change.
Find a serial mismatch
13 min
Make one deliberate, safe change: set delay_time to 1000ms but leave the delay_ms label at 500. Compile and upload.
Now the program will run correctly, but the serial message is misleading. Your final corrected version should use const int delay_ms = 1000; and const auto delay_time = 1000ms; so the printed label and the real wait match.
Paste one misleading serial line from the version where delay_time was 1000ms but the printed delay_ms label still said 500. Then explain why that misleading debug message is a problem and how you fixed it.
Submit your code
8 min
Attach your saved final main.cpp
Click Check saved files, confirm that main.cpp contains the corrected version, then click Attach saved code. After the code is attached, click Submit submission at the bottom of the activity.