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.
Various STM32 register bits have this rule: "Reserved, must be kept at reset value." The
modifyfunction 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
1at some point (but not always!) during execution, and I was usingmodifyto update the non-reserved parts of the register. This meant I wrote1back to this reserved bit and the peripheral started to misbehave. Making sure bit 31 is always written as0magically fixed the problem.This is just one example, and now that I know about the problem, I can avoid it by using
writeor 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.