MSP430FR2673: IIC upgrade exception

Hi,

May I know is there any update?

Thanks,

Cherry

Hi Cherry

Sorry for the late response. I don't know how customer invoke the BSL. And customer mentioned timeout occurs during the communication. Could you help let customer to capture the waves of SCL, SDA and TEST REST pin if they use hardware invoke, if they use software invoke please use a GPIO toggle signal to show the invoke point and capture it at the same time.

Hi Gary,

Thanks for your response.

Using the software-entered BSL, the reset pin to the 430 is not used. The jump code is as follows:

  if(reg_data == CMD_UPDATE)    //Jump upgrade
    {
        __disable_interrupt();      // disable interrupts
        ((void (*)())0x1000)();     // jump to BSL
    }

The following are the waveforms captured at slow upgrade communication speed (1 second delay after each write), starting with this packet, and following are abnormal:

The above exception is that the card is stuck in the download firmware address is 0xc07c, and the upgrade is always stuck here:

The figure on the left shows the problematic communication waveform, which is written successfully to the IIC slave address and only one data byte, and the subsequent SCL level is continuously pulled low. The figure on the right is a detail of the figure on the left. The current communication frequency of 200k, with a 50ms write delay, is still a sudden exception while communicating in boot.

And they've tried to extend the IIC communication timeout, but the issue remains.

Since the instruction for firmware checking is 12 bytes, they tried to upgrade the firmware again at 200 kHz, 3 bytes per package. The same failure occurred, but the situation was different. This packet is captured on an exception as follows:

There was a data error in this abnormal transfer, 0xA1 was transferred as 0xA0 0x01. But the bus level is good after the error, so the customer tries to retransmit in one byte after the error and the transfer is successful. So again, the following logic is tried: The firmware is transferred in 3 bytes per packet at the time of the upgrade, and in the case of a transmission error, it is retransmitted in 1 byte per packet; after the retransmission is successful, the transfer resumes in 3 bytes per packet. The result is a second error at address 0xc560 and a 1-byte retransmission fails, checking the bus level, the SDA line is pulled low and waiting for more than 8 minutes for no recovery (no auto-recovery).

Thanks and regards,

Cherry

Could you show me the link the China E2E, I can response there directly.