MSP430F6659: EMI/EMC susceptibility, Flash Corruption Issues

Hello Britta,
I did not recieve any reply even though I was directed to this thread for the answer to my question from my mail

Hi,

thank you for posting this question!

Please let me ask a couple of questions to further clarify your issue:

1) Are you refering to the MSP430F47187 or to the MSP430F6659?

2) You only refer to SW considerations to reduce EMI. I assume you've taken the HW considerations described in the device User's Guide section: Connection of Unused Pins. Depending on which device you'll use please have a look at the MSP430F47187 User's Guide or MSP430F6659 User's Guide respectively.

3) Could you give some more information about your application? Especially on writing the external memory and the timer usage.

With regards to power loss: Take a look at the TI Design: Intelligent System State Restoration after Power Failure with Compute Through Power Loss Utility to see if this would help in your application scenario.

Please share those information pieces with me so that I can further help you to solve your issues.

Thanks also for your patience!

Best regards,

Britta

Sorry, it took me some time to actually respond.

Hello Britta,
Thank you for the reply. I must admit that by mistake the part no mentioned in my thread title is MSP430F47187 as I had referred a previous thread of the part no mentioned in the title. The part no that I am using is MSP430f6659. We have been using this microcontroller previously for one of our application for the last 8 years but no SW consideration was taken to protect the microcontroller from any EMI issues or issues caused by power turning OFF while external SPI memory is being written. We write into this memory our diagnostic information of our instrument and the time at which this has occurred. We don't have any RTC or battery. Therefore these diagnostic information is stored as per device run time. Whenever device is ON a timer is used to count total no of minutes that the device was on. If there is any error the data is logged into memory every 15 minutes along with the time elapsed for device run. We haven't faced any problem till now as the device was used in loop applications(pneumatic positioners in valve based applications) where there is very low current(between 4 - 20mA) but now we are working in 3 phase applications(electro hydraulic actuators) where the possibility of noise disturbing our instrument increases and therefore as a preventive measure I want to take care the EMI issues using SW. The HW considerations have been taken by my HW engineer and the board is already ready. I wanted to know what precautions in SW can be taken further so that the possibility of EMI related failures can be reduced further.

With best regards,
Dhiren Shetty

Hello Britta,
I would also like to add in addition to storing data into SPI memory every 5 minutes we also need to turn ON/OFF outputs for coils, for actuator motors,for turning ON/OFF contactors for fault indications for which around 10 outputs from different ports are used which is another major reason for EMI/EMC consideration. Again these were never used in our earlier applications
With warm regards,
Dhiren

P.S.: This message has been added as per your suggestion from another post that I had made for better readability

Hi Dhiren,

thanks for adding your comment here.

SW considerations to reduce EMI:

- make use of low power modes

- avoid floating pins by initializing all pins. you can use the ULP Advisor integrated into both CCS and IAR to help you identify power optimization gaps such as the low power modes and uninitialized ports.

- if applicable conduct data sampling in lowest power mode possible

- also reduce clock frequency as applicable.

Writing external memory via SPI:

Please confirm your actual issue: you suspect that the power supplying the MSP430 and the external memory could be turned OFF while writing to the external memory and that this could corrupt the memory. Is this right? That way I understand you are looking for a way to savely shut down the devices until power returns?

ON/OFF output for coils

You can to use a Timer (or whatever event triggers the need for ON/OFF) to switch the according pins to high/ low output when needed and return to the default in the meantime.

Please let me know if I understood your questions correctly or clarify them for me.

Best regards,

Britta

Hello Britta,

Thank you very much for your response. From your suggestions I am concluding the following:

1) Working on Low power mode would reduce EMI related issues. As mentioned I would be working on the ULP advisor.

2) Also I had said that I am using ports to give output to coils and contactor, it was just to indicate that while giving such output there is a possibility of voltage spikes being generated which might affect my system. It might disturb my supply lines and in the worst case cause flash corruption which I have endured in my earlier applications. The events to trigger such outputs are user keys to turn ON and OFF outputs or some events that can occur due to some faults detected by temperature, pressure or position sensor available in the system. Since these events are intermittent and random there could be a possibilty that there be sudden changes in output in random fashion. As you have mentioned you have suggested to use a timer for this purpose. I conclude that a delayed response for any event could help in reducing the spikes being generated in the system.

3) Also related to external memory being written randomly, I feel there is absolutely no control as even though event to write  is fixed at certain time intervals, you don't know when the power would turn OFF causing the write operation to go bad due to signal not remaining stable during power getting OFF or due to power fluctuation that can happen. Even if enough care has been taken to keep the power stable via hardware, is there any scheme to guarantee a situation where SPI memory is written only when supply is healthy?

With warm regards,

Dhiren

Hi Dhiren,

thanks for the clarification.

2) Before your clarification I didn't know what would trigger the desired ON/OFF output state. As you said those are triggered by user keys, then of course using a timer wouldn't make any sense. My suggestion would be to also take care of staying in the according low power modes whenever applicable, this might include setting flags during ISR handling and returning to a low power mode for task execution (if your application allows, I do not have all application details).

Please check the Software Coding Techniques for MSP430 MCU's Application report for some additional helpful hints.

3) I understand that you have a split power supply between the MSP430 and the external memory which could cause the external memory to endure a power down while the MSP430 is still fully functioning, right? Do you have the possibility to use the MSP430 integrated A/D converter to actually monitor the power supply at the external memory? That way you could decide per software, if the power supply at the external memory is ok and only then go ahead and write via SPI. If both devices are powered by the same power supply, make sure that the MSP430 would power down properly during this event and no write would occur. In both cases it would be crucial for the MCU to be aware of the power down at the external memory, otherwise I don't see any countermeasure via software. You could check the data sheet of the external memory and see if they advise for your case.

Did you take a look at the material about MSP430 with FRAM memory, that I shared with you before? Could this also be an option for you, using the integrated FRAM as memory to log the data you need?

Best regards,

Britta

Hi Dhiren,

do you have any update? Are there any more pending questions which I didn't answer yet?
Please let me know if your issues have been solved or if you'd need any more help from my side.

Note that I'll be closing this thread in case I don't hear from you. You can always re-open the discussion by posting again.

Thanks and best regards,
Britta

Hi, Bretta,

I have implemented the steps as mentioned by you and also followed ULP advisor. Now I would be implementing the suggestions as mentioned in SW coding techniques for oscillator and flash integrity check. We will be sending the device on field and based on the response I can conclude that whether the issue is resolved . Thanks for your suggestions and if there is any  issue or if the issue is resolved I will surely inform

With warm regards,

Dhiren