MSP430G2353: Older Lot Restart Loop Problem

Is it possible to recreate the issue through debugging?

Is it possible to reprogram a simple GPIO code to check if this problem is related to software or purely the MCU itself.

Can you check if there is any possiblity that you avoid the MCU spec. Please measure the VCC, and IO pins.

Hi Eason,

I have confirmed that the watchdog hardware is same, voltage and power is also same. Since I have replaced the old and new MSP chipset on my devices. My team ran watchdog timer code on the old chipset for 30 seconds to check if the issue was with timer logic but the timers are accurate.

Let me know what else can be done from my end. If needed we can also connect on call through teams,meet or any other platform to resolve the issue.

Thanks

Can you follow my instructions to do the test. All I want to know is to check the root cause is lies one where (The environment setup, or the device itself, or the SW?) Then we will check what to do next (Failure analysis, change the PCB or change the SW.)

Please understand that all these MSP430 will do test before shipping to end customers. Maybe, just maybe, the environment setup beyonds the limitation which is tested in the test and listed in the datasheet. It will not influence the new lot, but inlfuence the old lot.

So, please do the measurement with an oscolliscope. And try a simple example code.

Hi Eason, 

My apologies I wasnt able to clearly explain my testing process to you.

OS: Linux yocto dunfell (We are also working on a yocto 4.0 variant).

Host processor: Amlogic S905Y4.

Communication protocol: I2C.

I2C driver file loaded for MSP: NO

MSP is controlled using I2C tools like i2cget command.

Bus frequency: 400 KHz

Our use case: MSP acts as an external watchdog chipset. We initialize the time by sending command E1, and periodically send 0xFF. In case 0xFF is missed (device hang) for 4 consecutive times than the MSP sends a pulse to the processor reset pin and restarts the device.

New PCB (addressed as P1) is connected to new MSP(M1). The device works fine with no issues.

New 2nd PCB (addressed as P2) is connected to old MSP(M2). The device fails i.e sends trigger pulse infinitely unless repowered.

To address your questions: 

1. The environment setup: I removed M1 and soldered on P2. The MSP worked perfectly indicating no issues with the PCB and OS.

I removed M2 and soldered on P1. The MSP failed like before indicating no issues with the PCB and OS. This mean that there was some issue in old MSP(M2).

2. Software: I confirmed both the MSP chipset were flashed the same firmware one by one, using the same laptop and the same MSP flashing tool. I have confirmed that the library used is msp430g2353.h and built in code composer. 

I have confirmed that the issue exists with the older variants only as i have confirmed on other chips available in my office. The new chips are working fine. According to the team the MSP firmware is optimized.

Let me know what else is needed.

Thanks,

Hassan

Hi Hassan,

I know:

1. The problem happens on the old chips, but not on the new chips. 

What I want to do is to:

1. Check the root cause and find how to solve the problem. Please understand if I don't know the root cause, I can't further help you.

What I need you to do is:

1. Do you think the problem is possible to happens when the MSP430 don't receive the data correctly?

2. Check whether you can recreate this issue with old chips on debug mode. (I want to check if the device receive the I2C data correctly.)  

3. Can you catch the I2C signal with a digital analysier?

Eason

The send infinite reset pulses is the key. From your description, the code can't send a reset pulse at all until it receives that first data over I2C. So it isn't a restart loop problem.

Checking the errata (always a good idea) I don't see any differences between the three versions of the silicon. Plus, it appears that both lots are from the older rev. A.

There is probably a problem somewhere in the code. Some timing or race sort of thing.

As usual, a description of what you think the code is doing is much less useful than the actual code.

The send infinite reset pulses is the key. From your description, the code can't send a reset pulse at all until it receives that first data over I2C. So it isn't a restart loop problem.

Not exactly, after triggering a reset pulse the firmware flags are reset to base values and timer reset to 4 mins default. In this case the chipset will wait for bootup and then we send the commands. But within 5-8 seconds reset pusle is sent again while the device is still in booting up.

i can share the code, but not on a public forum, only on private forum. 

Can you help check if you can recreate this problem with MSP430 in debug mode? It will be much easy to get more information.

Please understand that it is very hard to check the code by eyes to find the possibilities that may cause the problem. 

Hi Eason, my sincere apologies for the delay.
Actually I dont know how to put MSP430 into debug mode. Can you guide me through the procedure. 
Thanks,

Also let me know if you need the firmware file. i can share it to you on private forum or official mails but not on public forum. 

I don't need the firmware, as I don't have the device that can recreate the problem.

Please make sure you can find the CCS or IAR project. Then select the project and click the debug button.

Hi Eason,
I will need more guidance on the process.
...

After clicking the debug i used to connect the MSP chip which would get flashed. So i will need more guidance on the matter.

Eason Zhou said:

2. Check whether you can recreate this issue with old chips on debug mode. (I want to check if the device receive the I2C data correctly.)  

This is what I want you to check in debug mode. Please let the MCU run and check whether the I2C data is well received. The key thing is that I want to know the difference between good device and bad device. Actually, I can only tell you how to debug. But where to debug or check, you should refer to the SW developer.

Sorry, I can't see the video. Can you directly put it on e2e?