Bugzilla – Bug 16363
MSP430 does not respond to i2c commands during power up
Last modified: 2010-11-09 13:36:54 UTC
MSP430 is initialized using one of the msp430-000?.txt files. The NAND flash on MSP439 is used to persist the firmware, so this firmware should never need any initialization after the first installation. There are times that after a power up sequence the MSP430 does not respond to i2c request and we reinitialize the MSP430. This should never happen. (This used to be part of Bug 16279 - Wireless not working after power on (AC)) The MSP430 is used to keep the date/time and initialization it causes the date/time to be lost.
From: Maurice Alou When leaving the low power mode in function enter_low_power_mode(), the function i2c_init(void) is called without checking if both i2c lines are in their idle state (high). If both lines are still low and the i2c is initialized, the i2c state machine of the msp430 may not be initialized properly and its behavior may depends on which lines rises first. I would recommend to wait for both i2c lines to be idle (or timeout after 100ms) in i2c_init(void) before clearing the reset bit of the i2c module. I would avoid waiting just a long time before clearing the reset bit as we may miss some transactions from the MX253. PS: function pins_state_on() already set pin SHUTDOWN and waiting for 10ms before doing anything else. So BIS(P2OUT, ...) and mdelay(50); should be deleted from enter_low_power_mode() as too much delay may create more harm than good: void enter_low_power_mode() { ........ BIS(P2OUT, PIN_P2_SHUTDOWN); // power up. mdelay(50); // Wait for 50 ms pins_state_on(); // put all the pins back into normal operation mode. i2c_init(); ........... } in several locations there is a sequence like this in power.c: pins_state_on(); mdelay(POWER_ON_DELAY); i2c_init(); as mention earlier, mdelay(POWER_ON_DELAY) should be removed and i2c_init() should wait for i2c line to go idle (high). PPPS: volatile int j = 0; seems to do nothing in i2c_init(void)
The battery is supposed to hold the MSP430 for two days at least, but with latest tests done by Maurice, the battery is depleted in almost 1/2 hour. This explains why if we unplug/plug the power in 1/2 hour the MSP430 has to be reset. There are two issues: 1. Why does the battery gets depleted so fast: One explanation is that we do not manage the A2D properly once the MSP430 goes to low power mode. 2. Why does reset does not bring up the MSP430 properly and eventually the MSP430's NAND flash should get programmed for it to function properly.
The MSP430 is taking a lot more current than it should be while we put it in the Low Power Mode 3, which basically disables the CPU, and everything else except the real time clock. Not sure what is causing this yet.
We are dealing in fact with two bugs: #1: msp430 draining 180uA instead of 2uA when powered from the super cap, #2: msp430 fails to respond to i2c after msp430 got a hardware reset. Note: bug #1 put the msp430 in limbo mode after 30 minutes and when power is applied to the device (DC jack or battery pack), the msp430 remains in limbo mode and fails to respond to i2c -> msp430 gets a hardware reset -> msp430 still fails to respond to i2c -> msp430 gets reprogrammed -> ok The bug #1 is caused by a faulty power down sequence of the ADC in adc_close(). The bit ENC of ADC10CTL0 must be cleared before changing some of the bits of ADC10CTL0 and ADC10CTL1. The current sequence does not respect this. The bug #2 is caused by testing the right bit in the wrong register to know if the ADC is busy in adc_read_one(). This leads to unpredictable results from the ADC and the code in the msp430 goes in low power mode thinking there is no power. Note: adc_read_one() is just used during boot of the msp430 and when in low power mode. In normal running mode, adc_read() is used instead. Some other inconsistencies have been cleaned up in the initialization of the ADC. Sanity testing is in progress.