You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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 usingmodify
to update the non-reserved parts of the register. This meant I wrote1
back to this reserved bit and the peripheral started to misbehave. Making sure bit 31 is always written as0
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.The text was updated successfully, but these errors were encountered: