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.

MSPM0L1105: Unable to communicate with ROM BSL when using invoke pin

Part Number: MSPM0L1105
Other Parts Discussed in Thread: SYSCONFIG

Hello,

My company is using the MSPM0L1105 as a I2C slave device. We plan on having the ability to update the MSPM0 application code via the BSL. However, we are having issues when entering the BSL via the invoke pin.

Background:

We are using the MSPM0L1105 with the WQFN-16(RTR) package. The full product name is MSPM0L1105TRTRR. Notably, for this product, the default I2C SCL pin is on the same pin for NRST (the pin name is PA1/NRST).

The MSPM0 application blinks an LED. When the LED isn't blinking and the power is on, the MSPM0 is presumably in the BSL. The application slave address is 0x11.

The master I2C device is an ARM processor running Linux.

In the syscfg, the BSL invoke pin is PA23/PA25, and the BSL invoke pin level is high. The BSL slave address is 0x48.

In the syscfg, the NRST pin is disabled.

When the application enters the BSL with the function DL_SYSCTL_resetDevice(SYSCTL_RESETLEVEL_LEVEL_BOOTLOADERENTRY), the master able to communicate with the BSL. Running the command utility i2cdetect from the master results in the I2C driver on the master to timeout when querying for slave address 0x48. When firmware is programmed for the master device to interact with the BSL using the BSL protocol defined by TI, we are able to communicate with it just fine. The purpose of mentioning i2cdetect is to establish its behavior when we are able to communicate with the BSL.

Although it is great we can communicate with the BSL when entering it with this method, we need the ability the enter it without the application.

Problem:

When the invoke pin is set to high (invoke BSL) and the power is turned on, the LED does not blink. Presumably, this means the MSPM0 is in BSL. When the master runs i2cdetect, there is no timeout on address 0x48. Without turning off power, the invoke pin is set to low (invoke application). When i2cdetect is ran, the LED starts blinking, which means the application is running. Running i2cdetect again confirms there is a slave with the address 0x11.

I believe what is happening is that the BSL does not disable the NRST pin. Thus, when there is I2C communication, the MSPM0 is being reset. This is most clear when the invoke pin being set to invoke the application, and I2C communication results in the MSPM0 running the application.

Am I correct with my conclusion? Is there a way to fix this?

**Attention** This is a public forum