USART1 connects to PCLK1. #260
Conversation
Thanks! I'll take a deeper look later today and will try to reproduce it :) |
src/serial.rs
Outdated
| feature = "mem-4", | ||
| feature = "mem-6", | ||
| feature = "mem-8", |
There was a problem hiding this comment.
Is this feature constraint not describable via the svd-* features? I mean the mem-* features do work, but are rather intended to distinguish memory differences and this seems not related.
There was a problem hiding this comment.
I used them because, for example f302x6/8 are affected, while f302xb/c/d/e are not. (Fig 12+13 vs. Fig 14 of RM0365)
There was a problem hiding this comment.
Hm. Yeah, this is not representable with the svd-*-features. But I would suggest to use stm32f303xb, stm32f303xc ... so that it is more obvious, when reading it :)
There was a problem hiding this comment.
(Fig 12+13 vs. Fig 14 of RM0365)
Thanks for that info! I can see the difference. So I think the implementation is fine. Will still look at it later today :)
|
As this is a bugfix effecting |
|
I didn't mention #109 in the changelog, because I'm unsure whether this is a fix to that bug. |
That's okay. I'll have to invest a bit more time on that issue anyway, and as it might not be related, let's ignore it for now. |
That reminds me, that I probably should change the processor clock to 32 MHz or above instead of the default 8 Mhz for the uart tests |
Co-authored-by: Fabian <f.vioel@gmail.com>
This is to potentially better catch erros like described in stm32-rs#260 ealier.
|
I have not run a local test to verify this behavior nor check the erroneous old behavior, but I'll trust you and the datasheet on that one. Thanks for the catch and this contribution. Much appreciated! 👍 |
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
This is to potentially better catch erros like described in stm32-rs#260 ealier.
The clock tree figures of RM0366, RM0365, RM0364, RM0316, and RM0313 show that the default setting of RCC::CFGR3::USART1SW will, for some variants, make the port use PCLK1 for reference, and not PCLK2 where port is resident.
The affected variants are stm32f3xxx4/6/8, except stm32f37xxx.
This is consistent with my observations on stm32f344r8, which fails to produce the correct baud rate:
This might be related to #109, although I don't see why the discussed code snippet should cause different pclk's.