stm32: ticks() function is returning incorrect value

[deadprogram]

I have been testing the blinky2 on nrf (PCA100400), stm32 (bluepill), and samd21 (itsybity-m0).

My results:

• nrf both go routines work perfectly
• stm32 often runs each goroutine once, then freezes. When it does start it "stutters" and then each stops after a little while.
• samd21 both go routines freeze the first call of time.Sleep()

[aykevl]

This can be debugged by setting schedulerDebug = true in src/runtime/scheduler.go. it will print lots of messages that may help figure out what goes wrong.

Other than that, I would need to take a closer look to see what the problem is.

[aykevl]

I tried to debug this on the bluepill board but I haven't been able to connect a programmer for some reason. I also don't see anything obviously wrong with the code.
It's weird that this is an issue on these devices as it works fine on at least nrf, Linux, and WebAssembly.

[aykevl]

If I remember correctly, time.Now().Unix() works except that it does not return the current time. Can you check whether it returns sensible values (with epoch equaling the start time)?

[deadprogram]

So you were correct that the root cause was incorrect implementation of the ticks() runtime function, actually on both the STM32 and on the SAMD21.

I have a fix for the SAMD21 runtime that I will submit as a PR. Have not had a chance to go back to the STM32 yet.

[deadprogram]

Just submitted the PR for the SAMD21 fix.

[deadprogram]

This functionality is now working correctly for the SAMD21, still needs to be corrected for STM32.

[deadprogram]

PR #225 corrects this functionality for the STM32. We can close this issue once the code makes it into the next release.