Please note that E2E has undergone a major upgrade. Before logging in, please clear ALL your browser's cache and cookies.

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.

MSP430I2031: Information on JTAG/SBW input sequence mode + JTAG Fuse

Part Number: MSP430I2031

Hello Champs,

One of my customers has made a design with MSP430i2031. During their testing of the product, they found that Application is hanging.During debugging, we found that in frequent ac mains on off , TEST and RESET pin expose to noise and suddenly clock output on P1.0 and P1.1 (MCLK and SMCLK) gets stopped while we have configured these pins for clock output. When we grounded Test pins, It worked absolutely fine so we concluded that MSP430i2031 is executing some test mode due to noise on TEST-RESET pin. We are making hardware provisions for this condition, however in their application customer will blow its programmable JTAG fuse. I couldn't find much details of this in user guide except that in startup code of examples, Program looks for two location in Flash and if it is different than 0xFF and 0x00 then it disable JTAG by below instruction:

SYSJTAGDIS = JTAGDISKEY

My query is that even if there is noise on test pin (which executes entry sequence of JTAG/SBW) and we disable JTAG by blowing this programmable Fuse,  what will happen? Will MCU ignore this sequence and keep continue application OR Clock module stop similary as today & core will wait for something? Appreciate your inputs on the same...

Regards,

Vikas Chola

 

  • Hello Vikas,

    It's possible that the noise is invoking SBW control through the RST/TEST pins which will be resolved through locking the JTAG/SBW interface. This process is further described in Section 2.2.4 of SLAA685: www.ti.com/.../slaa685.pdf

    You will need to make sure that the noise does not cause false resets by pulling the RST pin low, to this effect your customer might consider even changing the pin to NMI functionality.

    Regards,
    Ryan
  • Hello Ryan,
    In customer application, RESET pi is pulled low with 2.2nF and connected to external SVS (MAX809). I couldn't see any noise on this pin but Test pin is pulled low by 4.7K resistor now (earlier with 47K). Still we have reproduced the same condition 2 days back. We couldn't reproduce this condition when we shorted TEST pin with ground so we are sure that TEST pin is culprit for this issue.

    I have gone through SLAA685 but before that I also have gone through SLAA320ab. So I have one confusion:
    After going through section 1.3.1.1 of SLAA320ab, My understanding is that even if device is entered in JTAG/SBW mode, it should come back from the same as there is no JTAG tool connected with the device and TEST/SBWTCK is low for more than 100uS. But on customer board, I am seeing that device Clock (MCLK and SMCLK) is not coming and RESET/NMI pin functionality is not working. MSP430i20xx doesn’t have BSL so device will not go in BSL . So I wish to know If there is any other test points implemented on MSP430i20xx in place of BSL where RESET/NMI pin stop working as RESET and device clock gets stopped.

    If it is JTAG/SPW mode only, Can you explain me what is the sequence after entering in JTAG/SPW mode. Does EEM looks for JTAG fuse first and if it is locked then comes out from this mode? If JTAG fuse is not locked why MCU stuck up in this mode? as per me it should time out and start working in due to TEST pin status as low but MCU doesn't work even if I make RESET pin Low by connecting it with Ground and release the same manually.

    Regards,
    Vikas Chola
  • Even without BSL, some SBW-capable MSP430 device's TEST/SBWTCK line is very sensitive to rising signal edges that can cause the test logic to enter a state where an entry sequence (either 2- wire or 4-wire) is not recognized correctly. e2e.ti.com/.../

    Edit: This thread has been closed as the issue is being resolved offline.

    Regards,
    Ryan