MSP430FR5738: Incorrect level judgment after power up

Hi 

What is the value of P1IN register?

Hi Allen,

Allen Gao said:

What is the value of P1IN register?

The external resistor is pulled high, and the measured value is 3.3V. But the register still reads 0.

Thanks and regards,

Cherry

Hi Cherry,

I have checked the configuration and it is ok for me. Did you measure the voltage of PIN1.3 ( close to the device pin) when power up and after optocoupler work? Is there any difference?

I suggest that you can isolate the optocoupler or remove it and give a low level or high level voltage directly to see the input detection is normal or not at the first time power up.

Hey Allen,

Allen Gao said:

Did you measure the voltage of PIN1.3 ( close to the device pin) when power up and after optocoupler work? Is there any difference?

When power up and continuously detecting low voltage, the measured voltage at optocoupler pin connected to PIN1.3 is 3.3V.

Allen Gao said:

I suggest that you can isolate the optocoupler or remove it and give a low level or high level voltage directly to see the input detection is normal or not at the first time power up.

By removing the optocoupler, or pull up R33, there is no low level detection.

By changing R33 10k to 100k, the problem has been improved. (Previously,  every power cycle the issue will occur, now for 100 times,  1-2 times will be problematic.)

Thanks and regards,

Cherry

Hi Cherry 

 You can test different pull up resistors like 20K 30K 50K to find the law. Optocoupler circuit may be the cause. Multimeter reflect the average voltage. To find more details, you can get the waveform of the PIN1.3 through oscilloscope.  Test the waveform in different circumstance: optocoupler with different pull up resistors. There should be some difference.

Cherry Zhou said:

The low level is detected all the time after power up, and the optocoupler is not on

In the posted code, which looks to be main() function although the function name isn't shown, there is no code to clear the PM5CTL0.LOCKLPM5 bit. As a result the I/O pins could be locked.

The following from MSP430FR57xx Family User's Guide (Rev. D)  suggests the PxIN register will have it's value locked in an undervoltage event which presumably happens during power-on:

Try adding the following code (after the code which stops the watchdog timer):

 // Disable the GPIO power-on default high-impedance mode to activate
 // previously configured port settings
 PM5CTL0 &= ~LOCKLPM5;

Hello Chester,

Thanks for your help here!

The customer has tried to add the code you given, but the problem still remains. 

Also, when using a multimeter to test whether the IO port is 3.3V, the phenomenon disappears. 

Thanks and regards,

Cherry

Hi,

May i know is there any updates?

Thanks and regards,

Cherry

Hi Cherry,

How many board has this problem?  Does customer do cross check between different board? This should be the influence of the peripheral circuit of the input pin. Because the problem no longer occurs after you remove the peripheral circuit or directly pull up. 

Has the customer caught the waveform of the pin voltage when there is a problem with power-on and when the peripheral circuit is removed or the pin is directly pulled up? This is more helpful for comparative analysis of what happens when the input pin goes low when powered on under different conditions.

Cherry Zhou said:

By removing the optocoupler, or pull up R33, there is no low level detection.

By changing R33 10k to 100k, the problem has been improved. (Previously,  every power cycle the issue will occur, now for 100 times,  1-2 times will be problematic.)

Cherry Zhou said:

The P1.3 io port is configured in input mode through which the external input detection is done. The low level is detected all the time after power up, and the optocoupler is not on. The optocoupler must be on once for the input to be judged normal. The input voltage is always high after power up, but the program determines it is always low.

This might be errata PORT26 described in MSP430FR5738 Microcontroller Errata (Rev. AG) :

Can one of the workarounds be tried?

Hello Allen and Chester,

Thank you all for your support!

Chester Gillon said:

Can one of the workarounds be tried?

It is true that P1.4 was previously used as an external input, and a similar problem has occurred, and then modified the P1.4 IO port which results in P1.3 also has such problems in bulk later.

Also, dose other IO ports also have such issues? Regarding the IO ports, the customer will use more of them on input mode.

Thanks and regards,

Cherry

Hi Cherry,

Other pins don't have this problem.

Hi Allen,

Thanks! May I know what's the possible reason for these 2 ports (P1.3 and P1.4) has such issues?

Thanks and regards,

Cherry