MSP430FR5043: software hang

Hi,

Behnam Madadnia said:

when I disconnect the battery connector from the board and reconnect it, the software hangs and nothing works again unless I reset the board or re-flash the chip.

Few questions from my side. What does the software hangs mean? Do you connect to the GUI and does it mean the GUI will not show the data/waveform? If so what is the current connection status of the GUI? Could you please describe in more details about the behavior of this software hangs?

Best Regards,
Peter

Hi Behnam,

Thanks for the info, do you use resonator or crystal in your custom board, could you please share the schematic here? 

Best Regards,
Peter

Thank you peter for the reply, in fact we have used "AWSCR-8.00CV-T", which is a ceramic resonator as it is in the reference design "TIDM-02005". Please let me know which part of the schematic you need, then I can add it here, for now a I added the crystal part. Let me know of you need more info.

Regards,

Behnam,

Hi Behnam,

The crystal part looks fine to me because it is the same as the TI reference design, one initial suspicion is that it may be caused by the not enough settling time for the crystal, but since you use the resonator and follow the TI design I think it should be fine, but you can also increase a little bit of the XTAL Settling count as shown below to see whether it do help with the issue.

In addition, according to what you mentioned, this issue only occur when repower the whole system with cold start, but then reset or reprogram the system can be resolved, so another suspicion is the unstable initial power supply or any other over-spec risk in the hardware that will cause FRAM corruption which described in the datasheet, so I would suggest you to test below items to see if there is any pulse spikes or over-spec when power up.

• Check all pins (including AVCC/DVCC/GPIO/ADC Input…) to see if exceeding the DS specified limits.
• Check the voltage difference between AVCC and DVCC to see if exceeding the DS specified limits.
• Check the power on sequence, make sure there is no external input voltage on the pin before DVCC/AVCC is stably powered on.

And I noticed that you use battery to power the system, you can try to perform a test with connecting the system to a more clean digital power supply outside to see if the issue still occurred.

Best Regards,
Peter

Dear Peter,

Thank you very much for the detailed explanations, I really appreciate your help. I’ll adjust the crystal settling time and update you with the results.
Regarding the power‑supply sequencing: I wrote a very basic LED‑blinker firmware, and I do not observe the issue with that hardware/firmware combination. If there were a sequencing problem on the PCB, I would expect it to appear in that firmware as well.
I’m trying to narrow down the possibilities, so do you think this is most likely related to the resonator start‑up and/or the USS library?

There is one more piece of hardware information that may be helpful: initially, I was powering the MCU directly from the battery at 3.6 V, meaning I was not using any regulator for low‑power considerations on the PCB to reduce 3.6V to 3.3V (AVCC and DVCC =3.6V). To rule out any supply‑related issues, I also tested the system using an external regulated 3.3 V power supply, but the issue still occurred.

Best regards,
Behnam

Hi Behnam,

I don't think it is related to the USS library, because you can use it normally and issue only occur when first power on, and many customers also use the library with repeatedly power on to perform the pressure testing and have no similar issue found yet, so from these perspective, I would prefer suspecting that it will most likely caused by some hardware issue, especially the power supply part. 

One thing need to double confirm, can you always recover the system by pressing the reset button or sometimes must reflash the board to recover? You can perform more tests to confirm it. This question matters because it can help us decide whether can rule out the suspicion of the FRAM corruption, if causing the FRAM corruption, it will result in some code FRAM region to be changed and may get the whole system stuck.

In addition, for why it only influence USS library but not the simple led-blink code, if caused by the FRAM corruption, one possible reason is that the code size of the USS library is much more bigger than the led test code you used, since the corruption will happen in random region of the whole FRAM, so that it will more possibly affect the USS project code region than the led-blink project.

But in general, I still recommend to test the hardware items in the previous reply, and also you can use oscilloscope to capture the VCC waveform when first power on to see if any pulse spikes that exceed much more than the VCC absolute spec in the datasheet.

Moreover, could you please share with me the schematic part of power supply part and MCU related part, I want to check if there is any potential concern.

Best Regards,
Peter

Dear Peter,

Please find the schematic and layout attached.

Please let me know if you have any questions.

MSP430FR5043IPM.pdf

Hi Behnam,

For the Power part, please try to replace the L6 with a 0Ω resister and increase the C24 to the 47uF to see if it can do help with the issue, and please note to use VDD as the stable 3.3V for the test.

Best Regards,
Peter