Problems flashing a TI LP MSPM0G3507 via XDS110

[davidjohnsummers]

Hi, I've a new Texas Instruments LP MSPM0G3507 board, that uses the XDS110 chip to program the M0+.

I'm using pyocd 0.35.1 it write the first 35% of the code OK, but then barfs

pyocd flash ./mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex --pack=TexasInstruments.MSPM0G_DFP.1.1.0.pack -t mspm0g3507 -u MG350001
0004561 I Loading /home/summers/ti/mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex [load_cmd]
[=================                                 ]  35%Exception in thread Thread-2 (rx_task):
Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.11/threading.py", line 975, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.11/site-packages/pyocd/probe/pydapaccess/interface/pyusb_backend.py", line 156, in rx_task
    read_data = self.ep_in.read(self.ep_in.wMaxPacketSize,
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
0015462 E Error during board uninit: [session]
  File "/usr/lib/python3.11/site-packages/usb/core.py", line 423, in read
    return self.device.read(self, size_or_buffer, timeout)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/usb/core.py", line 1029, in read
    ret = fn(
          ^^^
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 864, in intr_read
    return self.__read(self.lib.libusb_interrupt_transfer,
0015466 E Probe error during disconnect: [session]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 954, in __read
    _check(retval)
  File "/usr/lib/python3.11/site-packages/usb/backend/libusb1.py", line 602, in _check
    raise USBTimeoutError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBTimeoutError: [Errno 110] Operation timed out
0015481 C Device MG350001 read thread exited [__main__]

Now the Texas Instruments command for flash via uniflash come line also produces and error, but does flash the device

/home/summers/ti/uniflash_8.3.0/deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite flash --config=MSPM0G3507.ccxml ../mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex --verbose
DSLite version 12.3.0.3041
Configuring Debugger (may take a few minutes on first launch)...
	Initializing Register Database...
	Initializing: CS_DAP_0
	Executing Startup Scripts: CS_DAP_0
	Initializing: CORTEX_M0P
	Executing Startup Scripts: CORTEX_M0P
	Initializing: SEC_AP
	Executing Startup Scripts: SEC_AP
Connecting...
CORTEX_M0P: GEL Output: Memory Map Initialization Complete
Loading Program: ../mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex
	Preparing ... 
	0 of 1280 at 0x0
error: CORTEX_M0P: Flash Programmer: Device init failed
	Finished
	Setting PC to entry point.
Success

[flit]

That's a USB transfer error. For some reason, reading from the XDS110 probe fails with a USB timeout.

What host are you running on? If it's a Raspberry Pi, people have reported various issues with the RPi USB stack (not just with pyocd).

Also, I think I remember someone reporting a previous issue with XDS110 USB communication?

To really debug this would require a USB bus trace. Unfortunately, I don't have an MSP dev board with an XDS110, so I can't debug it myself.

[davidjohnsummers]

I'm running it on a 15 year old computer AMD E350 device - so yes its an old low powered machine. But it programs an NXP LPC845-BRK device via pyocd fine. So its only the XDS110 device that has problems.

Yes TI only seems to have started using the XDS110 programming chips on the new Cortex M0+ chips they are moving to. The development boards have only started becoming available a few weeks ago, that means you can get an XDS110 program device for $15 or so, whereas for an external XDS110 programming device, its over $100 IIRC.

Is there any way of increasing the USB timeout? As a whole I prefer the pyocd programming a device than the TI version, although that isn't bad.

[davidjohnsummers]

If it helps here is the usbmon output when the timeout happens. What is the best program to read it with for the information you require.
5.mon.out.gz

[flit]

I just ordered an LP-MSPM0G3507 board, so hopefully it will be here within a week or so.

For usbmon, it seems Wireshark might be able to read the output? You should also be able to record directly within Wireshark. Although, I've never tried this for USB. If I have a chance this weekend, I'll try to review it, but there are several other issues I'm working on, too.

It's not possible to change the USB timeout from the command line, though there is a constant in the code.

pyOCD/pyocd/probe/pydapaccess/interface/interface.py

Line 25 in dc9f2c0

DEFAULT_USB_TIMEOUT_S = 10

However, it's already set to 10 seconds… If the probe isn't responding within this time, then there's something seriously wrong.

[flit]

Something to try: you can set the cmsis_dap.limit_packets session option to prevent multiple outstanding commands (eg via -Ocmsis_dap.limit_packets). This is sometimes required in a VM.

[davidjohnsummers]

Thanks Chris, I'll try those. A timeout of 10s is huge! I've never known anything to take that time! But still when pyocd gives an error, it is at least several second - I didn't think it as long as 10s, but I change that to test.

Thanks for ordering the Ti MSPM0G3507 LP board, like all TI launch pads, its a nice little development board, with plenty of pin outs etc. The one unusual bit is going to the XDS110 programming chip - it means the programming chip is twice as large as the cortex M0+ (guess the XDS110 is a QFP 144 pin, and the M0+ a QFP 48 pin). Guess you ordered direct from TI (seems only place available right now) - for me it meant the board was delivered from Singapore (board made in China) so shipping was five days or so, but very hassle free.

Just tried the -Ocmsis_dap.limit_packets option - that ran immediately, and without error - but didn't seem to write anything!

pyocd flash ./mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex --pack=TexasInstruments.MSPM0G_DFP.1.1.0.pack -t mspm0g3507 -u MG350001 -Ocmsis_dap.limit_packets
0006691 I Loading /home/summers/ti/mspm0_sdk_1_00_00_04/examples/nortos/LP_MSPM0G3507/cookbooks/pwm_led_driver/gcc/pwm_led_driver.hex [load_cmd]
[==================================================] 100%
0007764 I Erased 0 bytes (0 sectors), programmed 0 bytes (0 pages), skipped 2048 bytes (2 pages) at 1.96 kB/s [loader]

[flit]

The timeout is used in this case mostly to prevent hangs from a stuck device. It could very well be that the Linux kernel has a shorter timeout for USB than 10 seconds.

By default, pyocd will read the target's memory and compare with the data being programmed to prevent unnecessary flash erase/write cycles. In this case, you were reprogramming the same image so it didn't need to do anything. That's why it says "skipped 2048 bytes".

To force it to always program flash, pass -Osmart_flash=0.

[davidjohnsummers]

Bingo! And yes the -Osmart_flash=0 worked! Yes I was passing the same .hex file that I had flashed before, so I could compare the TI software to pyocd!

So problem was the multiple outstanding commands. Oh yes looked at the XDS110 part of the card closer yesterday, its just an MSP432 chip, so an older TI arm processor. If it helps the software on the XDS11/MSP432 device is the 03.00.00.25 CMSIS-DAP software; so I guess that is where the issue lies.

[flit]

Wow, I'm somewhat surprised that worked! I'll add a note to the docs.

Is this ok?

XDS110 firmware version 03.00.00.25 is known to have an issue when using multiple outstanding packets (the default setting). To work around this, set the cmsis_dap.limit_packets session option, e.g. -Ocmsis_dap.limit_packets=1 on the command line. Earlier firmware versions most likely exhibit the issue; it is unknown whether it is fixed in more recent versions.

Also, is it ok to close this issue now? Thanks!

[davidjohnsummers]

Yes - happy for you to close the issue, as you found the cause of the problem, and have a work around. So yes its a fault with XDS110, I wonder if we should escale the problem with Texas Instruments, so they know the issue - and will maybe solve with a future update?

Don't know, maybe it caused by the MSP432 chip that provides the XDS110 connection, maybe its just under powered?

[davidjohnsummers]

And Closing the ticket

[flit]

Thanks for closing.

There's no reason the MSP432 can't handle the task. We are able to run DAPLink (our open source CMSIS-DAP implementation) on far less powerful chips. Someone even has a custom CMSIS-DAP implementation running on an ultra cheap 8-bit 8051-compatible MCU! So it's almost certainly just a software bug.

Reporting the issue would be good, even if they don't take action. When I get my board, I'll try to find time to write a simple reproducer script that sends a valid command sequence which causes the device to hang.