Error for PLACE_IN_FRAM on MSP430FR2433

[rei-vilo]

Using the implementation of PLACE_IN_FRAM defined at #31, compiling against the MSP430FR2433 raises an error.

• Boards package MSP430 1.0.3
• Energia 1.8.5E19.

"/Users/ReiVilo/Library/Energia15/packages/energia/tools/msp430-gcc/4.6.5/bin/msp430-g++" -c -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=msp430fr2433 -DF_CPU=8000000L -DARDUINO=10805 -DENERGIA=10805 -DENERGIA_MSP_EXP430FR2433LP -DENERGIA_ARCH_MSP430 -I/Users/ReiVilo/Library/Energia15/packages/energia/tools/msp430-gcc/4.6.5/include "-I/Users/ReiVilo/Library/Energia15/packages/energia/hardware/msp430/1.0.3/cores/msp430" "-I/Users/ReiVilo/Library/Energia15/packages/energia/hardware/msp430/1.0.3/variants/MSP-EXP430FR2433LP" "/var/folders/px/cyfvtr757lqg0yp_cv9j79jh0000gn/T/arduino_build_642383/sketch/Blink.ino.cpp" -o "/var/folders/px/cyfvtr757lqg0yp_cv9j79jh0000gn/T/arduino_build_642383/sketch/Blink.ino.cpp.o" /var/folders/px/cyfvtr757lqg0yp_cv9j79jh0000gn/T//ccHKv3sW.s: Assembler messages: /var/folders/px/cyfvtr757lqg0yp_cv9j79jh0000gn/T//ccHKv3sW.s:49: Warning: ignoring changed section attributes for .text

Sketch is

uint8_t LED PLACE_IN_FRAM;

void setup() { 
  LED = RED_LED;               
  // initialize the digital pin as an output.
  pinMode(LED, OUTPUT);     
}

void loop() {
  digitalWrite(LED, HIGH);
  delay(1000);            
  digitalWrite(LED, LOW); 
  delay(1000);            
}

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.

[StefanSch]

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 ?

[rei-vilo]

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

• 1.9.3 FRAM Write Protection,
• 1.16 System Configuration Registers,
• 1.16.3 MSP430FR2433 System Configuration Registers,
• 1.16.3.1 MSP430FR2433 SYSCFG0 Register (offset = 00h) [reset = 9603h].

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.

[rei-vilo]

Example msp430fr243x_framwrite_persistent.c from slac700b provides

SYSCFG0 = FRWPPW | DFWP;            // Program FRAM write enable
Port_event++;                       // Record the port event in FRAM
SYSCFG0 = FRWPPW | PFWP | DFWP;     // Program FRAM write protected (not writable)