Support for XDS110 on arm64?

Ed,

There are no plans for supporting CCS running on a Windows Arm host at this time.  CCS runs on M1(Arm) based macs thanks to the Rosetta layer that Apple provides. Eventually, we will need to provide an M1 native application but today the only M1 native code is in the installer, Rosetta handles the rest.

As an alternative to Flash Programmer 2 you could use UniFlash on macOS.  https://www.ti.com/tool/UNIFLASH

Note that regardless of the status of XDS110 drivers Flash Programmer 2 and Sensor Controller Studio are not supported Windows for Arm, those packages would include binaries built for x86.

I will see if I can loop in someone to comment on the availability of Sensor Controller Studio for macOS.

Regards,

John

Hi Ed,

Unfortunately, a large volume of effort that would be required to change the Sensor Controller Studio source code (based on Visual Studio) so that it could support MacOS machines.  Such development efforts have never been prioritized and the general recommendation is that MacOS developers use a Windows or Linux VM.

Regards,
Ryan

Hi John,

Thanks for the reply. Quite impressed that CCS runs under Rosetta - and I can confirm that this allows debugging through XDS110 on the MacOS platform. Some good architecture choices there.

Thanks for the tip about UniFlash. For some reason I'd not spotted that this was also available as an OSX App. I think that covers that piece of the puzzle.

Whilst not supported - and I can see why not, Sensor Controller Studio 2.9.0.208 does run well on Windows11arm64 under Parallels. It allows projects to be created, edited and the Code Generator seems to work just fine. The only missing piece is Task Testing which cannot connect to the target without the arm64 native xds110 device driver.

Obviously, I'd be very happy if a macOS version of SensorControllerStudio were to appear. This would make for a very nice development suite. ...but maybe recompiling the device driver might be a simple short term fix?

Ed

Hi Ryan,

Thanks for your reply. Yes, I can see why this would not have made it up the priority stack when MacOS was running on x86 and a Windows or Linux VM was a freely available way of working. Developing on Windows10 as a VM in Parallels has been my go to solution for some time now.

What is new now is that there is no way, as far as I can tell, to develop Sensor Controller code on an M1 MacBook. Whilst the MacBook can execute x86 code through Rosetta, it cannot run an x86 VM because the VMHost vendors are only offering arm64 VM support. This appears to be a reasonable choice for them because there are fully supported arm64 versions of both Windows11 and Linux available

Funnily enough though Window11arm64 does run CCS, the Simplelink build chain that I'm using and SensorControllerStudio. I think this is because the OS includes automatic emulation of x86 application code. Certainly I can compile binaries with this setup. What Windows11arm64 does not do is support x86 device drivers, and this is where using a VM on M1 MacBook comes unstuck - you cannot connect to the hardware to debug or test SensorController code.

Would this be solved with an arm64 compile of the XDS110 driver? I'm not sure, but I'd be keen to help you test it ;-)

Kind regards

Ed

Ed,

So you are able to run CCS on Windows 11 Arm64? I am surprised that works.  If you are able to build your projects that means that Microsoft has some sort of emulation layer as our compilers on windows are all built for x86/64.  I assume you get some sort of error message when you attempt to start a debug session?

John

Hi John,

So far I've only attempted builds on arm64 Win11, no debug sessions. Without the driver there didn't seem much point.  The build results are binary identical to those produced with CCS on OSX on M1 silicon. I too was a bit surprised by this, but reading into arm64 Win11, there are a bunch of settings related to x86 emulation in Windows11arm64. I assume from this that the OS is performing on-the-fly emulation where it needs to for application code. Certainly CCS builds done like this are a bit slower than done in CCS OSX which uses Rosetta for translation rather than emulation.

Now trying a debug session, perhaps as expected it barfs trying to initialise the XDS110:

Error initializing emulator:

(Error -260 @ 0x0)

An attempt to connect to the XDS110 failed.

The cause may be one or more of: no XDS110 is connected, invalid

firmware update, invalid XDS110 serial number, or faulty USB

cable. The firmware and serial number may be updated using the

xdsdfu utility found in the .../ccs_base/common/uscif/xds110

directory of your installation. View the XDS110SupportReadMe.pdf

file there for instructions.

(Emulation package 9.7.0.00213)

XDS110 enumerates, but cannot find a valid device driver:

Reading the Windows logs the driver install fails because it doesn't have a valid arm64 binary.

Ed

Some helpful reading:
Why x86 drivers don't run in arm64 Win:

docs.microsoft.com/.../apps-on-arm-troubleshooting-x86

Recompiling drivers for arm64 Win:

https://docs.microsoft.com/en-us/windows-hardware/drivers/develop/building-arm64-drivers

Now if only I had the XDS110 driver source code...

Noticed that TI created the xds110.c file for OpenOCD, where that OpenOCD source file appears to run in user space and use libusb to communicate with the XDS110 rather than requiring a specific driver.

Not sure it you could get CCS with OpenOCD + GDB to debug using a XDS110 without needing an ARM64 XDS110 driver.

Hi Chester,

Thanks the suggestion.

I did find the xds110.c file and wondered whether there was an open-source version of the full driver, and of course OpenOCD looks great.

Unfortunately I don't think that this moves me forward. The TI team have done a great job of getting CCS running on OSX and because M1 OSX can run the OSX XDS110 driver that toolchain does work well.

The immediate issue is actually with SensorControllerStudio and the other utilities that TI are unlikely to port to OSX. Whilst these are happy running in emulation under the arm Windows11, the device driver that they need cannot.

Big thanks for considering my problem though.

Ed

For our "driver" we are actually just using a standard driver that is already present.  We install configuration data (inf) in a signed package.  The installer uses an old Windows driver framework.  That last part is likely what is failing.  Sorry that does not help much.  We would need to rebuild the installer using a newer windows driver framework.

Hi John,

Thanks for this comment. It's the basis of a solution. Happy days!

It is possible to install unsigned driver packages under Windows11 using a boot option:

https://gearupwindows.com/how-to-disable-driver-signature-enforcement-on-windows-11-10/

this makes it possible to modify the .INF files supplied with CCS for the XDS110 to add sections to specify an install under arm64. The install does depend on a couple of coinstaller DLLs but Win11 seems happy to execute these under emulation.

I have some modified versions of the standard .INF files that seemed to have worked for me. Is the right thing to do to upload them here?

So far I've tested this with SensorController Studio and a LaunchPad, and launching a debug session in CCS11.

One word of caution though, Windows11 doesn't automatically install the device drivers for the XDS110 DFU firmware upgrade process and so the upgrade can fail half way through. This can lead to a need to de-brick the Launchpad.