This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR5972: EMF Issue with LoRa module

Part Number: MSP430FR5972

I am working on a project with MSP430FR5972. For wireless data transmission there is a high power LoRa module (433MHz,1W) some cm away from the MSP. When I adjust the power above 13 (range 0..20) I get permanent resets (radio module terminated with 50ohms resistor). It is not the power supply breaking down, must be EMF issue. What could i do? All io-pins have blocking c´s. Putting a grounded shield on the MSP? What is the most possible way the EMF get´t into the MSP?

  • Hello Andre,

    EMI related topics are unfortunately never easy. You have stated it's not the supply voltage. Can I ask you for more details on this? Did you monitor the supply voltage with the scope in the very moment when the reset happens?

    To be able to make proposals how to address these issues, first we need to find out, what the real failure mechanism is in very detail. Also because the behavior might change in the field. Keep in mind the loading and disturbance to the system due to RF activities might fundamentally change based on the radiation and loading of the antenna, which is always dependent on the ambience, the RF application is operated in.

    So apart from the above question, please let me ask a few additional ones and make suggestions, what to look into and test. In case you see issues with privacy, as we probably will have to go into quite some details, there is a way of sharing data privately. To do so, you need to request my friendship in the E2E system. After my acceptance you could share data with me privately.

    Questions:

    1. What are the operating conditions of the MSP430. (Supply voltage, clocking of the MSP430 (source, frequency), is the MSP430 in active or LPM mode)?

    2. Do you use the SVS functionality of the MSP430, if so, what are the settings?

    3. Have you checked on the reset vector content after such an even did occur? What kind of reset root cause is it showing?

    4. What else have you tried to debug the behavior (code, settings modifications, e.g. lowering CPU clock frequency, changing the clock frequency, what are the used clock frequency relations in the system, e.g. MSP430 clocking frequency versus any other system clocks)?

    5. Could you also provide more information on the design, schematics, layout?

    Suggestions:

    1. Please try to look further into details of the reset.

    a) When exactly is it occurring?

    b) Is it always exactly at the same time point? (possible ways to look deeper are, monitoring of the RST vector, monitoring the clocks on the MSP430. Here not checking the oscillators themselves, if crystal or ceramic resonators, but always switch the respective clocks to GPIOs, outputting the internal digital clock. The MSP430FR5972 allows MCLK, SMCLK and ACLK monitoring). You could also generate auxiliary GPIO signals showing what code sequence is executed and when the code execution terminates.

    c) As mentioned, monitor at the same time the supply voltage of the MSP430 by a scope. Not only a break down of the supply could generate a reset, but also fast transients on the supply pins of the MSP430 might trigger a reset.

    2. If not already done, please try to change the CPU clocking (speed, source..).

    3. Could you try to control the RF device activities by another MSP430, or whatever device and disconnect the MSP430 on the PCB (assume you're using the MSP to drive/control the RF device).? This way we could see, whether it is the radiation or conducted effects. e.g. disturbance coupling into the MSP430 through the RF device interface. You could also try inserting serial resistors into these lines if possible from the PCB design perspective (e.g. small 0402, cutting the traces)

    I think this should be enough for now to get us started.

    Best regards

    Peter

  • Hello Andre,

    based on the assumption, your questions have been answered sufficiently, I am closing this thread. In case you should need additional support on this, please let us know.

    Best regards

    Peter

  • Thank you for your suggestions. It is interesting that the issue went away the moment we started to read out the reset vector. Maybe the code change was enough to change frequencies or interferences. We will take this all in consideration in further development.