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.

MSP430FR2673: Self-write boot for 430 upgrade, IIC read timeout on upgrade to last firmware size location, cannot be restored

Part Number: MSP430FR2673

Hi Team,

There's an issue from the customer need your help:

I've placed two apps inside the 2673 chip, one as an upgrade boot and the other as an app, and the upgrade boot is written refer to BSL. When the newly upgraded firmware is smaller than the chip's own app firmware, the upgrade will not be unusual and will function normally after the upgrade. However, when the new firmware is larger than the size of the app firmware already present on the chip, a bus error occurs when upgrading to the end address of the existing firmware size (IIC communication timeout or address not acknowledge). From the scope, when IIC tries to read the packet reply after writing the packet, boot does not respond and SCLK and SDI are pulled low and cannot be recovered. When I power cycle the device, the new firmware is upgraded normally, or the boot is upgraded in debug mode with no problem. 

The firmware size that already exists on the chip is 5502, the app program starts at 0xc800, so the end address is 0xdd7e, and the self-written boot is a packet of 200 bytes, and the problem occurs when a new firmware attempt is made to write to the 0xdd18 to 0xdde0 area. Contains the end of the old firmware. 

I tried to replace the program on the chip, but whenever I wanted to update a firmware larger than the original firmware, the same problem would occur, and every time I had a problem with this package at the end of the old firmware; when I upgraded, I immediately wrote the new firmware to the end of the old firmware. The problem immediately occurs. 

Here's what I configured in my own boot: 

Turn off all interrupts __disable_interrupt(); before jump boot, jump used ((void (*)())*(uint16_t *)(0xFFFE))();

Is there any way to solve this problem? Or what could be the cause of that? 

Could you help check this case? Thanks.

Best Regards,

Ben

**Attention** This is a public forum