Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PAC register modify function, and STM32 "Reserved, must be kept at reset value." #9

Open
Gekkio opened this issue Apr 18, 2022 · 0 comments

Comments

@Gekkio
Copy link

Gekkio commented Apr 18, 2022

Various STM32 register bits have this rule: "Reserved, must be kept at reset value."
The modify function in chiptool-generated PACs technically doesn't follow this rule, because it always writes back to these bits the value that was read. In 99% cases this is probably fine, but I just spent hours debugging a problem on STM32F215 where this matters.

Here's the relevant part of the reference manual:
Screenshot from 2022-04-18 17-02-29

Bit 31 is marked as reserved, and the reset value for that bit is 0. Quite interestingly the bit is also marked as "rw"...usually reserved bits don't have read/write information in the reference manuals. After debugging a strange problem for hours, I found out that bit 31 actually read 1 at some point (but not always!) during execution, and I was using modify to update the non-reserved parts of the register. This meant I wrote 1 back to this reserved bit and the peripheral started to misbehave. Making sure bit 31 is always written as 0 magically fixed the problem.

This is just one example, and now that I know about the problem, I can avoid it by using write or masking out this one bit. However, it would be better if we could automatically follow this rule, since debugging these kind of issues is a pain, and reserved bits are very common so a similar problem could in theory happen pretty much anywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant