Open rei-vilo opened 6 years ago
The FR2433 has an updated FRAM controller where the FRAM is per default write protected. This can be disabled by // Open FRAM for write access -> clear DFWP and PFWP bits SYSCFG0 = FRWPPW;
I am not sure it we should add this to the initialization part of the device inside Energia so that this would work out of the box and make it compatible to the existing devices or leave it as is and document it. In this case we would have protection of the data in FRAM in case of pointer going crazy and is overwriting data in the program area. Thoughts ?
Thank for the prompt answer. I was reluctant to go through the 661 pages of the MSP430FR4xx and MSP430FR2xx Family User's Guide (slau445g) document but I should have done it. I would have found sections
Table 1-32 differentiates DFWP
Data FRAM write protection from PFWP
Program FRAM write protection. Does DFWP
protect the program area?
@StefanSch If write protected FRAM is the new standard, I would recommend keeping it out of the initialisation process and adding 2 functions, one for enabling FRAM write and another for disabling it. Those two functions would call a nop
for previous generation of MCUs.
For example, ENABLE_FRAM_WRITE
and DISABLE_FRAM_WRITE
, to be consistent with PLACE_IN_FRAM
.
Using the implementation of
PLACE_IN_FRAM
defined at #31, compiling against the MSP430FR2433 raises an error.Sketch is
Sketch can be uploaded and run, but the variable placed in RAM can only be read, not written, so the red LED doesn't blink.