stm32: use stm32-rs SVDs which are of much higher quality #1557

aykevl · 2021-01-04T16:51:40Z

I have not yet tested this on an actual stm32 device, because I can't seem to flash the only device I have (a bluepill).

There are a few changes that might affect behavior, both are bugfixes:

The OTYPER register only has single bit wide fields while they were treated as two bit wide fields. This could affect I2C on stm32f4/stm32f7 devices. I have fixed this issue but haven't tested whether I2C still works.
The constant stm32.FLASH_ACR_LATENCY_2 (value 4) was incorrect, it is now replaced with the correct value of stm32.FLASH_ACR_LATENCY_WS2 (value 2). I suspect there was a confusion between values and bit fields somewhere (2 vs 1 << 2).

If you work with a local checkout of TinyGo, you will need to remove all existing stm32 files (rm src/device/stm32/*) and generate the updated versions (make gen-device-stm32).

deadprogram · 2021-01-04T20:15:03Z

Tested blinky1, serial, and mpu6050 examples on my bluepill and it worked.

I did have to hold the reset button and release right after running tinygo flash in order to get my st-link v2 clone to work.

deadprogram · 2021-01-04T20:23:20Z

Correction: mpu6050 does not work, seems like you were correct about i2c problem with this change, @aykevl

aykevl · 2021-01-05T12:11:46Z

@deadprogram the I2C change is only for other stm32 chips, not for the stm32f103. I'm surprised it stopped working. Can you maybe test whether this PR is really to blame by testing the parent commit as well?

deadprogram · 2021-01-05T15:50:54Z

I did test i2c against the dev branch, which did work. Hence why I made the second comment.

aykevl · 2021-01-05T16:47:22Z

Huh, strange. Can you post the code you use for testing? I should be able to figure out where it differs.

deadprogram · 2021-01-05T16:50:31Z

https://github.com/tinygo-org/drivers/blob/release/examples/mpu6050/main.go

aykevl · 2021-01-05T20:16:27Z

Thank you, I see two differences in runtime.initCLK.

aykevl · 2021-01-05T20:33:30Z

I hope I have fixed the issue. I found a bug when configuring the PLL, this should fix it:

  	stm32.RCC.CFGR.SetBits(stm32.RCC_CFGR_SW_PLL) // set clock source to pll
 
 	// wait for PLL to be CLK
-	for !stm32.RCC.CFGR.HasBits(stm32.RCC_CFGR_SWS_PLL) {
+	for !stm32.RCC.CFGR.HasBits(stm32.RCC_CFGR_SWS_PLL << stm32.RCC_CFGR_SWS_Pos) {
 	}
 }

This PR changes the value of RCC_CFGR_SWS_PLL from one that doesn't need shifting to one that does. But because the value exists under the same name in the generated Go file, it didn't result in a compiler error and I didn't check it manually.

(Sidenote: this is even more reason to come up with an alternative to SetBits / ClearBits / HasBits which are too easy to misuse).

kenbell · 2021-01-06T03:23:54Z

I've verified on the nucleo-f722ze with blinky1 and echo - both worked fine

kenbell · 2021-01-06T03:47:44Z

I've also verified on STM32F407G-DISCO1 - blinky1 and echo

deadprogram · 2021-01-06T18:29:37Z

Still does not work as expected with this branch on bluepill mpu6050 program. dev branch still works.

aykevl · 2021-01-06T23:03:14Z

Okay thanks again for testing, will check again soon what this difference is.

aykevl · 2021-01-06T23:24:51Z

This is all very strange. The only difference I can find (that should matter) is the flash latency.

To rule that out, can you try this patch (on the stm32-rs branch)?

diff --git a/src/runtime/runtime_stm32f103.go b/src/runtime/runtime_stm32f103.go
index 9ecfcfd1..52a6d614 100644
--- a/src/runtime/runtime_stm32f103.go
+++ b/src/runtime/runtime_stm32f103.go
@@ -23,7 +23,7 @@ func putchar(c byte) {
 
 // initCLK sets clock to 72MHz using HSE 8MHz crystal w/ PLL X 9 (8MHz x 9 = 72MHz).
 func initCLK() {
-       stm32.FLASH.ACR.SetBits(stm32.FLASH_ACR_LATENCY_WS2)                          // Two wait states, per datasheet
+       stm32.FLASH.ACR.SetBits(4)                                                    // Two wait states, per datasheet
        stm32.RCC.CFGR.SetBits(stm32.RCC_CFGR_PPRE1_Div2 << stm32.RCC_CFGR_PPRE1_Pos) // prescale PCLK1 = HCLK/2
        stm32.RCC.CFGR.SetBits(stm32.RCC_CFGR_PPRE2_Div1 << stm32.RCC_CFGR_PPRE2_Pos) // prescale PCLK2 = HCLK/1
        stm32.RCC.CR.SetBits(stm32.RCC_CR_HSEON)                                      // enable HSE clock

The only other change I can find is related to IRQ_DMA2_Channel3, I'm not sure what's going on there but we shouldn't be using that interrupt.

deadprogram · 2021-01-08T07:28:41Z

The patch for stm32.FLASH.ACR worked. Seems like stm32.FLASH_ACR_LATENCY_WS2 is not a valid value here for some reason?

aykevl · 2021-01-08T12:43:22Z

Figured out the problem and fixed it (i2cTimeout for the stm32f103). This PR should now work correctly with the stm32f103.

deadprogram · 2021-01-08T12:52:13Z

OK, confirmed that does indeed fix the problem. Thanks @aykevl will merge after CI build.

aykevl · 2021-01-08T13:05:32Z

Maybe #1561 should be merged first? After which this PR should be updated.

(Haven't yet looked since my review)

deadprogram · 2021-01-08T13:17:33Z

@aykevl if you can please give a quick lookover of #1561 seems like everything has been addressed now and we can squash/merge it first as you suggest.

deadprogram · 2021-01-09T10:22:15Z

Was trying to resolve the merge conflict, and seems like I must have done something wrong. Trying to fix the CI build now 😿

deadprogram · 2021-01-09T16:12:33Z

Seems like some difference in the names generated for the STM32L0x wrapper vs. the other STM32 boards we support:

Here is the code generated in src/device/stm32/stm32f407.go

	GPIO_MODER_MODER0_Pos        = 0x0        // Position of MODER0 field.
	GPIO_MODER_MODER0_Msk        = 0x3        // Bit mask of MODER0 field.
	GPIO_MODER_MODER0_Input      = 0x0        // Input mode (reset state)
	GPIO_MODER_MODER0_Output     = 0x1        // General purpose output mode
	GPIO_MODER_MODER0_Alternate  = 0x2        // Alternate function mode
	GPIO_MODER_MODER0_Analog     = 0x3        // Analog mode

vs. the code generated in src/device/stm32/stm32l0x1.go:

	GPIO_MODER_MODE0_Pos        = 0x0        // Position of MODE0 field.
	GPIO_MODER_MODE0_Msk        = 0x3        // Bit mask of MODE0 field.
	GPIO_MODER_MODE0_Input      = 0x0        // Input mode (reset state)
	GPIO_MODER_MODE0_Output     = 0x1        // General purpose output mode
	GPIO_MODER_MODE0_Alternate  = 0x2        // Alternate function mode
	GPIO_MODER_MODE0_Analog     = 0x3        // Analog mode

This is one of the const values that is causing the build to fail. @aykevl what do you think?

aykevl · 2021-01-09T16:16:44Z

Yes, that's the exact kind of thing I had to fix to use the new SVD files.

aykevl · 2021-01-09T17:20:31Z

It was a bit more complicated than I thought, in the end I just redefined all the MODER/OSPEEDR/PUPDR bitifields.

This commit changes the number of wait states for the stm32f103 chip to 2 instead of 4. This gets it back in line with the datasheet, but it also has the side effect of breaking I2C. Therefore, another (seemingly unrelated) change is needed: the i2cTimeout constant must be increased to a higher value to adjust to the lower flash wait states - presumably because the lower number of wait states allows the chip to run code faster.

aykevl · 2021-01-09T17:32:23Z

@ofauchon can you test the LGT92 with this branch? You will need to run git submodule update --init and make gen-device-stm32 after checking out this branch.

ofauchon · 2021-01-09T20:19:07Z

I checked out this branch and regenerate everything from the svds.

Then I built a couple of sample applications and ran them on the LGT92 device.

Everything seems OK for me !

deadprogram · 2021-01-09T20:44:54Z

Awesome! Now merging.

aykevl mentioned this pull request Jan 5, 2021

Move to Rust SVD library for STM32 #1551

Closed

aykevl force-pushed the stm32-rs branch from ee675e7 to 38558cd Compare January 5, 2021 20:29

kenbell mentioned this pull request Jan 6, 2021

Use rust SVD library for STM32 #1550

Closed

aykevl force-pushed the stm32-rs branch from 38558cd to 9b4323f Compare January 8, 2021 12:42

deadprogram force-pushed the stm32-rs branch from 9b4323f to 473be18 Compare January 8, 2021 22:35

aykevl force-pushed the stm32-rs branch from 473be18 to 07bf073 Compare January 9, 2021 17:19

aykevl force-pushed the stm32-rs branch from 07bf073 to 36677ef Compare January 9, 2021 17:30

deadprogram merged commit 154c7c6 into dev Jan 9, 2021

deadprogram deleted the stm32-rs branch January 9, 2021 20:45

aykevl mentioned this pull request Jan 10, 2021

feather-stm32f405: I2C not working #1568

Closed

stm32: use stm32-rs SVDs which are of much higher quality #1557

stm32: use stm32-rs SVDs which are of much higher quality #1557

Uh oh!

Conversation

aykevl commented Jan 4, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

deadprogram commented Jan 4, 2021

Uh oh!

deadprogram commented Jan 4, 2021

Uh oh!

aykevl commented Jan 5, 2021

Uh oh!

deadprogram commented Jan 5, 2021

Uh oh!

aykevl commented Jan 5, 2021

Uh oh!

deadprogram commented Jan 5, 2021

Uh oh!

aykevl commented Jan 5, 2021

Uh oh!

aykevl commented Jan 5, 2021

Uh oh!

kenbell commented Jan 6, 2021

Uh oh!

kenbell commented Jan 6, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

deadprogram commented Jan 6, 2021

Uh oh!

aykevl commented Jan 6, 2021

Uh oh!

aykevl commented Jan 6, 2021

Uh oh!

deadprogram commented Jan 8, 2021

Uh oh!

aykevl commented Jan 8, 2021

Uh oh!

deadprogram commented Jan 8, 2021

Uh oh!

aykevl commented Jan 8, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

deadprogram commented Jan 8, 2021

Uh oh!

deadprogram commented Jan 9, 2021

Uh oh!

deadprogram commented Jan 9, 2021

Uh oh!

aykevl commented Jan 9, 2021

Uh oh!

aykevl commented Jan 9, 2021

Uh oh!

aykevl commented Jan 9, 2021

Uh oh!

ofauchon commented Jan 9, 2021

Uh oh!

deadprogram commented Jan 9, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

aykevl commented Jan 4, 2021 •

edited

Loading

kenbell commented Jan 6, 2021 •

edited

Loading

aykevl commented Jan 8, 2021 •

edited

Loading