Serial monitor outputting non recognized characters

PlatformIO IDE
1

Hello,

I’m getting started with PlatformIO and I’m getting behavior that I don’t understand at all. My serial monitor outputs garbage characters. I’ve tried to follow the similar posts on this forum to no avail. By a stroke of luck, I was able to find one configuration that outputs successfully to the monitor, and that’s by setting Serial.begin(115200) and the serial monitor baud rate at 57600 and I would really like to understand what is going on

Here is the output when using Serial.begin(9600) and monitor baud rate at 9600 as well.
image

It should not be needed for this question but just in case, here is the test code

#include <Arduino.h>

void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.println("test");
  delay(2000);
}

and here is my platformio.ini

[env:LGT8F328P]
platform = lgt8f
board = LGT8F328P
framework = arduino

Upon further testing, it appears everything works as long as the Serial.begin value is twice the value of the monitor value. I’m not sure how to interpret this, sounds like maybe a board definition issue? (Sorry if I’m saying non-sensical things, I’m very new at all this)

If anybody has some insight, that would be greatly appreciated,
Thank you.

2

Then you have proven yourself that the clock rate on the microcontroller is off by exactly factor 2.

Because 115200 / 2 = 57600.

The code on the chip thinks it is running at a certain clock frequency, but in reality the clock to the microcontroller is only half that frequency. (That’s why Serial.begin(115200) results in 57600 serial signal instead.)

Most likely, you have a LGT8F328P board with a 16MHz crystal but the board definition is set for 32MHz.

What’s the reality on your board in regards to the quartz oscillator? Is there one, and if yes, what frequency does it have?

See their clock config options

The other possibility is that you have some fuse settings burned in your chip that activate a “div clock by 2”.

3

Thank you for the answer and the very informative links maxgerhardt. No, the board does not have a crystal.

I’ve tried to change my platformio.ini to this

[env:lgt8f328p]
platform = lgt8f
board = lgt8f328p
framework = arduino

board_build.f_cpu = 16000000L
board_build.clock_source = 1

But no luck. When exactly is that ini being accessed? I’m not sure how to ensure the serial monitor is using the updated params.

4

Okay, updated my code to this and the clocks are fine now. I’ll ferret around to see if there’s a way to fix that directly in the board definition or something but I suck at this.

#include <Arduino.h>
#include <avr/power.h>

void setup() {
  Serial.begin(9600);
  clock_prescale_set(clock_div_1);
}

void loop() {
  Serial.println("test");
  delay(2000);
}
5

So you’re basically running into

Can you just do one test:

  1. Remove the clock_prescale_set(clock_div_1); call
  2. Use this platformio.ini
[env:LGT8F328P]
platform = lgt8f
board = LGT8F328P
framework = arduino
; Force divider to be 1.
build_flags = -DF_DIV=1 -DF_OSC=32000000L

(per code)

6

Worked like a charm, thank you max!

7

Great. I’ve opened an issue at

to get this resolved better.

By the way, after look at it again, with your original platformio.ini and the framework’s code, whatever clock divider the bootloader set should have survived. So the actual source of all your problems might be that bootloader on your chip is set for 16MHz, the framework code does not modify it (with F_OSC unset), and so your code also runs at 16MHz (if not counteracted against).

And given that this bootloader binary is in your chip

the 0xfc30 (decimal -976) is consistent with F_CPU = 16000000.

While the bootloader could be recompiled and reburned with F_CPU = 32MHz, I think this is more complicated than just accepting that the bootloader runs at whatever clock frequency / divider it wants to and that the Arduino core should just set the frequency divider to achieve its wanted frequency.

8

Awesome. Thank you for the issue, the answer and the insight. I’ll defer to your clearly superior knowledge as far as the bootloader goes, but for now, your ini fix suits me more than perfectly. Thank you again!

Also, come to think of it, I think this may have been by design. This MCU is meant to be an Atmega clone so maybe they were trying to avoid some potential timing issues for inplace replacements?