drone-os/drone-core

ITM output doesn't work when running at full speed

zackyancey opened this issue · 9 comments

zackyancey commented

I've run into this both following the book and running the bluepill-blink example. After switching to the high-speed oscillator, the ITM monitor doesn't work anymore. Taking out the raise_system_frequency call is enough to get ITM working on the example.

A logic analyzer shows that the output is still there and looks valid at the higher clock rate, but the baud rate has gone up significantly. By default the baud rate is about 115200, but running off the HSE it measures at 1066666 baud.

I tried changing bmp.uart_baudrate in drone.toml, to 1066666, but then I just get:

stty: invalid argument '1066666'

I don't know if the baud rate should be changing with the clock frequency, so I don't know if this is a problem with Drone or with the ITM monitor (or maybe it's all working as it should be, and it's my old machine's fault for not being able to handle 1066666 baud 🤷‍♂).

valff commented

ITM frequency should be constant regardless of the system clock frequency. After changing the system clock, we update the SWO prescaler here: https://github.com/drone-os/bluepill-blink/blob/bd3697b5e89220e622b5687ad4c5fc9aec53f8ec/src/tasks/root.rs#L104

SWO can be also configured in Manchester encoding, thus the reader can adapt to varying speed, but we have found this method not 100% reliable. And Drone needs a reliable channel for its heap-tracing functionality.

What MCU do you use as the target? If it is not STM32F103, the resulting frequency may be higher than expected, and the SWO prescaler will be set to a wrong value. In this case you should edit values at src/consts.rs.

And also what debug probe do you use? If you don't use BMP, which method do you use to read from the SWO pin?

zackyancey commented

I'm using a Blue Pill as the target and another one as a BMP, and I'm running the example code without modification (which includes the itm::update_prescaler call). Git shows the only difference as adding the Cargo.lock file, which I'll include in case that's helpful.

It looks like SYS_CLK is accurate, because the LED is blinking at the right speed. Is it possible that the call to itm::update_prescaler is failing?

Cargo.lock contents

valff commented

I checked a clean build of bluepill-blink and it works for me, odd. Let's try to narrow down the issue. What nightly version are you using? What is your BMP firmware version? (Printed at the beginning of just itm.)

You are not seeing periodic "sec" messages when running just itm, right? What if you comment out raise_system_frequency call at src/tasks/root.rs? Can you see "sec" messages?

zackyancey commented

I'm using rustc version 1.39.0-nightly-2019-09-05.

BMP version is 1.6.1-101-g5686550-dirty (another issue I've been having, although it doesn't seem to be a drone problem, is that I can't get BMP firmware from master onto a bluepill - it looks like the micro doesn't have enough flash.)

That's right, I don't see the "sec" messages.

  1. Clean build of bluepill-blink:
    just itm doesn't print anything after the === ITM OUTPUT === line. Light blinks twice per second as expected. Putting a logic analyzer on the ITM line I can see the data coming out at 1066666 baud (the board is outputting "sec" plus some extra data that I assume is part of the ITM protocol).

  2. Comment out raise_system_frequency:
    just itm prints out "sec" every 9 seconds, and the LED blinks at 1/9th the speed it should. A logic analyzer on the ITM line shows the same data coming out, but at ~115200 baud.

  3. Comment out raise_system_frequency and set consts::SYS_CLK to 8_000_000:
    just itm prints "sec" every second, the LED blinks twice per second (but we're only running at 8MHz).

alfredch commented

It works as expected on my bluepill with unmodified sources from github.
Is your chip different? How is it labeled? I guess not all bluepill boards have equal components depending on where they originate from.

zackyancey commented

Changing to another Blue Pill from another vendor fixed it - I should have thought of that, I've been bitten by poor qc on these boards before...

Well, back to making my way through the book. (Kudos to the developers for putting together such an easy to follow getting started guide by the way! I'm excited to see where this project goes)

valff commented

@zackyancey I'm glad it is solved! I have one suspicion, could you please check the label of the failing chip? Once, I received a counterfeit blue pill board. It was almost exactly the same except the MCU was marked as CKS32F103C8T6 instead of STM32F103C8T6.

zackyancey commented

They're both marked STM32F103C8T6, but the bad board has noticeably lower quality labeling on the chip and the info after the part number is different (bad board has CHN where the other has MYS).

valff commented

Thanks for the info! My test boards have MYS labels. I have an old one with CHN. Just tested it and it doesn't connect with the debug probe at all.