On each reset (entry into the main() function), the cubes-fw code currently reads the ASIC and HVPS configurations from NVM and applies them.
The problem is with the HVPS configuration, that this requires an "HST" command, which writes to the NVM on the HVPS on every CUBES reset. This is (1) not good practice, as too many writes to the HVPS's NVM can deem it unusable, but also (2) wrong, as any external setting of the HVPS's temperature compensation factor (from, say, the CitirocUI) would be overwritten by the CUBES reset.
This issue should be fixed by, for example, not writing the HVPS using "HST" on every reset.
To be thought about: Is a region for the HVPS configuration even necessary in the SF2 NVM?
Go back to the citiroc_intf gateware specification document to remind yourself if yes...
The NVM memory area assigned to the HVPS has been removed in commit 5a6fd1b. See the commit message for reasoning on why (in addition to what is stated above).
On each reset (entry into the
main()
function), thecubes-fw
code currently reads the ASIC and HVPS configurations from NVM and applies them.The problem is with the HVPS configuration, that this requires an "HST" command, which writes to the NVM on the HVPS on every CUBES reset. This is (1) not good practice, as too many writes to the HVPS's NVM can deem it unusable, but also (2) wrong, as any external setting of the HVPS's temperature compensation factor (from, say, the CitirocUI) would be overwritten by the CUBES reset.
This issue should be fixed by, for example, not writing the HVPS using "HST" on every reset.
To be thought about: Is a region for the HVPS configuration even necessary in the SF2 NVM?