MSP430FR2476: Information memory region write on PUC event

1.12.1.1 FRAM Write Protection
The FRAM protection allows users to protect user code and data from accidental write operation. The
write operation to main code FRAM and information FRAM are protected by the PFWP and DFWP bits,
respectively, in the SYSCFG0 register. After a PUC reset, both bits default to 1 and writes to FRAM are
disabled. User code must clear the corresponding bit before write operation. See Section 1.16.2 for
register details.

//Get previous write protection setting
uint8 u8_State = SYSCFG0_L;
uint8 u8_wp = DFWP | PFWP;

SYSCFG0 = FRWPPW | (u8_State & ~(u8_wp));

__disable_interrupt();

///< Write Data
for(uint16 i = 0; i < u16_Length; i++)
{
    pu8_InfoMemoryPointer[i] = pu8_Data[i];
}

__enable_interrupt();

//Restore previous write protection setting
SYSCFG0 = FRWPPW | u8_State;

Hi,

There is an example code writing to the information memory. Have you tried it on your board?

https://dev.ti.com/tirex/explore/node?node=A__AM6QYnBUHQT2ROMUPiKp5g__msp430ware__IOGqZri__LATEST

Best regards,

Cash Hao

In my code snippet above (reply to David), you can see I am doing that.

As I recall trying to write to write-protected FRAM doesn't generate a reset, rather it is just ignored. What is the symptom of your "crash"?

Also, are you calling this code from main() or from a _system_pre_init()?

I am calling the code from main().

As far as I can tell, the system ignores/fails to write to the FRAM.
I am writing a structure with CRC field.

By looking the info mem region in the debugger after the issue occurs,
Reason for reset reason was written to the FRAM, i.e. 16 bytes were written.
But the same code when updating the CRC field of the structure fails which has other implications on the application.

Basically FRAM was written to partially, I am not sure why it would do that.

Tejas Randeria said:

Basically FRAM was written to partially, I am not sure why it would do that.

It is impossible to know for sure without actual code to look at but it appears that the  CRC is not written along with the data but with a different call to the FRAM write code. Which opens up other possibilities.

//Calculate new crc-sum
mp_storageDrv->Read(static_cast<uint32>(u16_StorageLoc), &buffer[0], u16_StructLengthNV);
memcpy(&buffer[u16_offset], pv_data, u16_size);
// recompute crc based on the new value
u16_crc = crc16_Compute(CRC_INITIAL_VALUE, &buffer[sizeof(ST_Header::u16_crc_sum)], u16_StructLengthNV - sizeof(ST_Header::u16_crc_sum));

// Write new data to eeprom
en_error = EC_ResWriteConstrainConflict;
if ((mp_storageDrv->Write(static_cast<uint32>(u16_StorageLoc) + u16_offset, pv_data, u16_size) == u16_size) &&
    (mp_storageDrv->Write(static_cast<uint32>(u16_StorageLoc), &u16_crc, sizeof(u16_crc)) == sizeof(u16_crc))) 
{
    en_error = EC_NoError;
}

Do you guys have any updates for me?
Have you tried reproducing it on your end?

Hi,

Sorry for the late response. I think this issue has been solved somehow. 

Back to this issue, in the UG chapter 1.9.3. "any write access to the protected FRAM causes an invalid write operation but does not generate an interrupt or reset". So, if you still getting PUC event, it should not caused by writing to the FRAM. It should be something else causes the PUC event. 

And for writing the CRC to the FRAM doesn't work functionally, Have you tried testing the example code first? 

Cash Hao11 said:

There is an example code writing to the information memory. Have you tried it on your board?

https://dev.ti.com/tirex/explore/node?node=A__AM6QYnBUHQT2ROMUPiKp5g__msp430ware__IOGqZri__LATEST

Best regards,

Cash Hao

It looks like you guys don't want to understand the issue I am pointing out and don't want to help me.
I've explained myself very well and also gave you the code snippets I am using.

As this point I can only say this forum is deliberately choosing not to answer my question and give me a reasonable explanation for the issue at hand.

Giving me the same standard response is not helping me or you.
Thank you for nothing.

You provide incomplete information and then get annoyed when we can't guess what the problem is.

I particularly like how you ask if anyone has recreated it when you haven't provided a complete code example which exhibits the problem.

I am getting annoyed because I answered all your questions and you're giving me standard responses thinking I don't know how to work with Microcontrollers and I have no experience coding.

Simple experiment to perform on your end,
Perform a PUC event on your msp430fr2476 HW and verify you can write to FRAM multiple times on bootup.

I have explained myself above multiple times.
I'll type it again for your amusement.

//Calculate new crc-sum
mp_storageDrv->Read(static_cast<uint32>(u16_StorageLoc), &buffer[0], u16_StructLengthNV);
memcpy(&buffer[u16_offset], pv_data, u16_size);
// recompute crc based on the new value
u16_crc = crc16_Compute(CRC_INITIAL_VALUE, &buffer[sizeof(ST_Header::u16_crc_sum)], u16_StructLengthNV - sizeof(ST_Header::u16_crc_sum));

// Write new data to eeprom
en_error = EC_ResWriteConstrainConflict;
if ((mp_storageDrv->Write(static_cast<uint32>(u16_StorageLoc) + u16_offset, pv_data, u16_size) == u16_size) &&
    (mp_storageDrv->Write(static_cast<uint32>(u16_StorageLoc), &u16_crc, sizeof(u16_crc)) == sizeof(u16_crc))) 
{
    en_error = EC_NoError;
}

mp_storageDrv->Write

//Get previous write protection setting
uint8 u8_State = SYSCFG0_L;
uint8 u8_wp = DFWP | PFWP;

SYSCFG0 = FRWPPW | (u8_State & ~(u8_wp));

__disable_interrupt();

///< Write Data
for(uint16 i = 0; i < u16_Length; i++)
{
    pu8_InfoMemoryPointer[i] = pu8_Data[i];
}

__enable_interrupt();

//Restore previous write protection setting
SYSCFG0 = FRWPPW | u8_State;

(mp_storageDrv->Write(static_cast<uint32>(u16_StorageLoc) + u16_offset, pv_data, u16_size)

mp_storageDrv->Write(static_cast<uint32>(u16_StorageLoc), &u16_crc, sizeof(u16_crc))

I have told you multiple times already, the code Ihave is writing to the information memory. 
So the code snippet, I pasted above is working.

And Yes I know how to write to information memory.

Don't patronize me with your standard responses.

A complete example could be compiled and run as is. All you provided is fragments.

Basically

- You want me to create a new workspace in IAR IDE
- Implement the code causing me the issue
- Then give it to you so that you can test it and give me feedback.

I see, that's just perfect.

Why didn't you tell me this earlier, I wouldn't have spent my energy and time explaining it words assuming you would do the same on your end rather than me giving it to you.

I guess that's how you'll take my issue seriously.