MSP432E401Y: Connect To Target Fails without External Crystal

Hi Stuart,

  I think you are referring to this post which is not yet resolved. https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1306547/msp432e411y-swd-communication-error-though-msp432e411y-jtag-pin. I have yet to understand why it does not connect without the MOSC. 

Stuart Baker said:

I'm working with a customer that has a custom board using the MSP432E4 device. They intentionally did not use an external crystal connected to OSC0/OSC1. Our documentation states that this is okay as long as OSC0 is connected to ground, as it is on the customer's custom board. The device is factory new without having been programmed previously

That is correct. Unused OSC0 can be tied to GND. 

Stuart Baker said:

In suspicion that this may have had something to do with not having a crystal, I took the MSP0ESP432E401Y development kit to try and reproduce the issue. I started with a working configuration, which worked with both SWD and 4-wire JTAG mode. Next I removed the crystal from the board and tied OSC0 to ground. Now I can fully reproduce the issue my customer is facing. It doesn't matter if I use SWD or 4-wire JTAG mode.

Can you run a test connection? What does it show? Below is my scan-test log. 

[Start: Texas Instruments XDS110 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\a0321879\AppData\Local\TEXASI~1\
    CCS\ccs1200\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Jun 17 2022'.
The library build time was '22:30:41'.
The library package version is '9.8.0.00235'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller to enter SWD mode.

-----[Print the reset-command hardware log-file]-----------------------------

This emulator does not create a reset log-file.

-----[Perform the SWD Mode Integrity test]-----------------------------------

This test will read the IDCODE register 1 time.

The IDCODE register value is 0x2ba01477.

The SWD Mode Integrity test has succeeded.

[End: Texas Instruments XDS110 USB Debug Probe_0]

Stuart Baker said:

How can we get CCS to successfully "Connect to Target" when not providing an external crystal on OSC0/OSC1 and connecting OSC0 to ground?

By default, the device starts with the internal PIOSC. MOSC is not needed. 

5.2.5.1 Fundamental Clock Sources
There are multiple clock sources for use in the microcontroller. The Run and Sleep Mode
Configuration Register (RSCLKCFG) can be used to configure the required clock source for the
device after Power-On Reset, as well as the system clock divisor encodings. The available clock
sources are as follows:
■ Precision Internal Oscillator (PIOSC). The precision internal oscillator is an on-chip clock
source that the microcontroller uses during and following POR. It is the clock source in effect at
the start of reset vector fetch and the start of code application execution. It does not require the
use of any external components and provides a clock that is 16 MHz ±FPIOSC across temperature
(see Table 27-19 on page 1837). The PIOSC allows for a reduced system cost in applications that
require an accurate enough clock source.

Hi Stuart,

  I find this post that was confirmed by Amit as well as the customer that without the crystal, the LaunchPad can be connected by the debug probe. The customer was initially having connection issue without the crystal but he later confirmed that a solid GND is needed on OSC0 if the crystal is not used. Don't just use a jumper wire to ground OSC0.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/376258/tm4c123-launchpad-without-crystal-does-not-jtag-debug

Charles,

As indicated in my original post, we have already connected OSC0 to ground and it still does not work. In fact, the customer board was designed this way, with the OSC0 pad being directly connected to the ground plane with negligible routing distance.

This is a different result than Amit's posting, where connecting OSC0 to ground got it working. Keep in mind that Amit's post is for the TM4C123 series where this is for the TM4C129/MSP432E4 series. These two different series have at a minimum different boot loaders, as well as other possible differences. BTW, I already reached out to Amit for his suggestions, since I know he as a lot of history here. He is also stumped and agrees that according to our documentation it should work without a crystal.

To answer your previous suggestion, both the customer and I have already run the "Test Connection" It is always successful in both SWD and 4-wire JTAG mode:

[Start: Texas Instruments XDS110 USB Debug Probe_0]

Execute the command:

%ccs_base%/common/uscif/dbgjtag -f %boarddatafile% -rv -o -S integrity

[Result]


-----[Print the board config pathname(s)]------------------------------------

C:\Users\a0221026\AppData\Local\TEXASI~1\
    CCS\TI123~1.0\0\0\BrdDat\testBoard.dat

-----[Print the reset-command software log-file]-----------------------------

This utility has selected a 100/110/510 class product.
This utility will load the adapter 'jioxds110.dll'.
The library build date was 'Mar 10 2023'.
The library build time was '17:27:27'.
The library package version is '9.11.0.00128'.
The library component version is '35.35.0.0'.
The controller does not use a programmable FPGA.
The controller has a version number of '5' (0x00000005).
The controller has an insertion length of '0' (0x00000000).
This utility will attempt to reset the controller to enter SWD mode.

-----[Print the reset-command hardware log-file]-----------------------------

This emulator does not create a reset log-file.

-----[Perform the SWD Mode Integrity test]-----------------------------------

This test will read the IDCODE register 1 time.

The IDCODE register value is 0x2ba01477.

The SWD Mode Integrity test has succeeded.

[End: Texas Instruments XDS110 USB Debug Probe_0]

Thanks,

Stuart

Hi Stuart,

  Although TM4C123 and TM4C129/MSP432E are two different MCUs, I think the architecture of the clock system is similar. Both uses PIOSC to startup the device. Both states in the datasheet that if crystal is not used, OSC0 can be tied to GND. 

  What is your TCK frequency? Can you try lowering the TCK frequency and does it make a difference?

Can you also show the customer's schematic for the JTAG interface?

Charles,

I tried 100kHz, 500kHz, and 1MHz in both SWD and 4-wire JTAG mode. The results are exactly the same, with exactly the same error messages, it does not connect.

The difference that Amit pointed out is that there is extra bootloader logic in the TM4C129/MSP432E4 device for the Ethernet, and because of that, it might be relying on the external crystal without the proper fail over to internal clock logic if it is not there. The bootloader always runs in a blank device.

The fact that "Test Connection" always succeeds makes me wonder if there may be some kind of custom GEL magic in the reset/connect sequence that can be added to prevent the bootloader from running ahead of the "Connect to Target" completion.

Thanks,

Stuart

Hi Stuart,

  You brought up a good point about the Ethernet ROM bootloader. The Ethernet ROM bootloader will need the 25Mhz MOSC in order to run the integrated PHY. Perhaps without the 25Mhz MOSC, the PHY is not running and causes the Ethernet ROM bootloader to get stuck. In the TM4C129 errata, a 4.7k resistor is recommended for RBIAS connection to GND. However, the schematic shown by the customer was using 4.87k as if Ethernet is to be used. I don't know if that makes a difference. Perhaps, worth swapping out 4.87k for 4.7k with 10% tolerance to see if that makes a difference. 

Replacing the 4.87K/1% resistor with 4.7K/10% is not going to make any difference.

• 4.7K - 10% = 4.23K
• 4.7K + 10% = 5.17K
• 4.87K + 1% = 4.92K and is already in the 4.7K +/- 10% range

furthermore, the 1% precision is due to the PHY's analog tolerance. If the PHY is unused, the purpose of the resistor is keep the PHY hardware happy, but not necessarily needing to be in tight analog spec. Allows the use of cheaper resistor when Ethernet is not in use.

Thanks,

Stuart

Charles,

Is there any way we can kick this over to the CCS tools team to weigh in? I'm wondering if some different order of operations during the connect procedure could be successful here.

Thanks,

Stuart

Stuart,

  Could you ask the customer to try adding MOSC just to prove/disapprove a MOSC is needed or not. I'm afraid CCS team may not be able to help here. 

Charles,

Unfortunately, it is not possible for them to add the MOSC to their custom board. This is because they used the BGA package, and the balls are not exposed. We happen to be testing with the TQFP package (same die) on the launchpad because it is fully reproducible on the LaunchPad when modified to match their board, exactly as the customer is experiencing it. We can use the LaunchPad continue troubleshooting this.

The LaunchPad modification is quite easy to do if you would like to try and reproduce it for yourself. Just pull off the main oscillator Y1 and ground OSC0. It took me all of 5 minutes.

Thanks,

Stuart

Stuart,

  I can reproduce the issue by connecting OSC0 pin on the crystal to GND on a TM4C129 LaunchPad with a empty flash. But if I first load a program (e.g. blinky) and then short OSC0 to GND, I will be able to connect while OSC0 is still grounded. I'm not clear as to what is going on to explain the root cause yet. But I don't think this customer is the first customer to not use external crystal. TM4C129/MSP432E has been out for 10+ years. There must be customers reporting the issue if they tie OSC0 to GND. I just don't know the root cause. BTW, I tie the crystal pin 3 to GND with the remaining trace and component still connect to the MCU OSC0 pin though. This will not be exactly the same setting as the customer. 

Stuart,

  This post will be an interesting read with Amit helping a customer who was having problem with his BGA TM4C129x device. The result reported by the customer is quite opposite to the current customer. The two different customers (Steve and Kevin) on the referenced post indicate that they must have the OSC0 grounded in addition to proper grounding on the RBIAS pin in order to connect and program the device. It is just opposite of what the current customer faces. 

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/390131/error--2062-when-programming-a-tm4c129xnczad-processor-what-does-it-mean#pifragment-323257=1

Charles,

I agree that this thread is an interesting find. I'm traveling today, but will try some of the suggestions with RBIAS in that thread tomorrow.

Thanks,

Stuart

Charles,

I have some positive news to report. With no crystal, I have SWD working simply by removing RBIAS, as suggested by the E2E thread you have pointed me to. It even works at the "default" 5.5MHz frequency. I will see if my customer can reproduce these results.

Thanks,

Stuart

Stuart,

 Glad it is working somehow. I suppose you remove the crystal and tie OSC0 to GND solidly. 

Charles,

Yes, this is the configuration I have on the development board, and also on the custom customer board. I've asked the customer to try and replicated the results.

Thanks,

Stuart