Closed crosswick closed 8 months ago
The delay should be about as accurate as the time clock. It uses the SysClk to setup interrupts every one millisecond, which decrements a global variable. The delay loop then simply waits for that variable to be zero again. So it should be accurate to about 1 millisecond.
Can you post which exact environment ([env:xxxx]
) you are using in the project, and what exact board you have (Microcontroller, quartz crystal's speed if present)?
It's a GD32E103CBT6 on this board with a 8.000 (GHz?) crystal:
using the genericGD32E103CB environment.
I see. so it has an 8MHz crystal on it. Per default clock settings, that should match, since that expects a 8MHz crystall and PLL-boosts the clock rate to 120MHz (div by 2, mul by 30).
Can you do the following:
SystemCoreClock
. Is it 120000000?Ah, time to get my debug setup working then I guess :) thanks, I'll investigate and get back
If that is too complicated, simply try adding
build_flags = -D__SYSTEM_CLOCK_120M_PLL_IRC8M
to the platformio.ini
and reupload. That should make it use the internal oscillator instead of relying on the quartz.
If that is too complicated, simply try adding
build_flags = -D__SYSTEM_CLOCK_120M_PLL_IRC8M
to the
platformio.ini
and reupload. That should make it use the internal oscillator instead of relying on the quartz.
this makes the LED not blink at all anymore
little video of the current blink speed
Ah, I've started debugging and although I can't find the SystemCoreClock
value, it does then blink way faster
edit: and I do measure it as 200 ms
You should be able to press the "Pause" button in the debugger and then add SystemCoreClock
to the "Watches" section in the left side to see the variable's current value.
I will shortly test this on my own board.
build_flags = -D__SYSTEM_CLOCK_120M_PLL_IRC8M
That should also not be happening. Will investigate why.
I see... when I add SystemCoreClock
though it says it's not available , also after pressing Continue in the debugger
Not sure if this is relevant, but just so you know: I’m using PlatformIO within a fork of VS Code called Cursor
I see... when I add SystemCoreClock though it says it's not available
Default optimization level (-Og) might be too aggressive. Add
debug_build_flags = -O0 -g3 -ggdb
to the platformio.ini
and debug again. It should now not optimize away anything.
I see - then I do get a value of 120000000
. The LED does not blink anymore btw, either in Pause or Continue state
...and when I stop the debugging sessing the LED blinks with 200ms interval
and when I then again upload the firmware it's back to 900ms again
I have a commercial GD32E103C8 board with 8MHz quartz (so very close to your CB one) and I can say the following:
build_flags = -D__SYSTEM_CLOCK_120M_PLL_IRC8M
indeed makes the LED stop but that's because it expects the macro's value to be the clock speed. So, it has to be build_flags = -D__SYSTEM_CLOCK_120M_PLL_IRC8M=120000000UL
. I tested that to work and blinks at the same rate as before.build_type = debug
and build_type = release
. It did not make a difference, the same blink rate is output in both release and debug optimization.Signal when using internal clock (variants expected):
Signal when using external clock (default settings, accurate to under one 1ms as expected):
Can you please provide the following info:
My board:
Thanks, my OS is macOS Monterey 12.6.6.
I can test the 4 variations later if needed, but I think I've found the culprit: the missing BOOT jumper on my board... perhaps you know why this would make this difference? With it present on the 0 position the timing is normal.
Well if you don't have the jumper in place, the BOOT0 pin of the MCU might float, so you might randomly go into bootloader mode.. But it would be too much of a coincidence if the bootloader also had a blinky 900ms code.
Right :) but perhaps this floating causes some condition where the basic system timing is thrown off...
Thanks again for the super swift assistance Max! So great to have all this GD32-related support.
Hi, I was wondering whether the blink speed is supposed to be accurate? From the code it seems like the LED is toggled off and on with a combined period of 200 ms; in reality I measure about 900 ms.
GPT-4 says this about it, perhaps useful: