mykhailosopiha commented on PR #20144: URL: https://github.com/apache/nuttx/pull/20144#issuecomment-5668894548
The main idea behind locking the entire block after write was mostly dictated by this restriction in a reference manual: on page 289 (section 7.3.9) is it clearly stated that an attempt to overwrite already written block may lead to data errors. Thus, there is no other way to make sure we are not corrupting our data. There is a thread in a forum already, proving that the concern is real: https://community.st.com/stm32-mcus-products-25/stm32h503-otp-bug-150915 Block is an only proper way to prevent double write and possible data corruption. So the problem effectively boils down to this: - how to make sure that driver does not corrupt memory if double write attempt happens? This is not theoretical question: it has proven to be an issue already - usually OTP burning is only used during provision phase. The provisioning phase is not only "write to OTP" - often it is way more complex process, and in these cases - provisioning happens on factory-ready devices, before shipping those. If the provisioning fails at some phase - a manufacturer must monitor if OTP write status: did that already happen? If yes - we should skip the OTP write phase. That adds complexity on all levels, and instead of "Just relaunch provisioning" - the manufacturer want to make sure they are not trying to burn through already written memory twice by introducing complex error-handling machinery to prevent a fully manufacturead sample from bricking. I understand you concern here: locking an entire block after writing a single word may be a resource waste, though taking into account the nature of this operation - it is not the highest price for making sure device is not bricked. IT becomes programmer's task to make less commits to the OTP memory, but that is pretty straightforward and native approach. As an option - we may introduce a separate "blind" write-unsafe function that will not be checking the lock, just a blind "write word by given address", and does not lock. We may want to add a comment "use it if you know what you are doing". Adding a "locked" check to reading function is not recommended: it may hit back once already provisioned (and non-locked) devices start using this api. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
