UNIFLASH: ioctl error when flashing CC32xx devices via UART

Hi,

Sorry for the delay. We will get back to you as soon as possible.

Thanks

Hi Hans,

It is anyway goes through the XDS (and then connects to the CC3235 over the UART), but without specifying the port, the software automatically detects the com port.

I still need to check with our tools team what is the problem with the --port option.

I assume you are using this on Linux.

Br,

Kobi

Hi Kobi

I use a mac for flashing the CC3235SF launchpad. I tried the same command on a windows and I can successfully flash the launchpad with the --port option specified (and also without).

I also tried it using a ttl-usb converter (TTL-234X-3V3). I disconnected the RXD and TXD jumpers on the launchpad and connected the CC3235SF side to the RXD and TXD of the ttl-usb converter respectively.

After executing following command:

.\dslite.bat --mode cc32xx device info --port COM5

I got an error saying that the COM port could not be opened

When executing the same command with the same setup on a mac, the ImageCreator still fails on setting the break signal and I got the same error if using the XDS on the launchpad

When using a ttl-usb converter, I need to manual reset the CC3235SF, so that it can register the break signal and set to programming mode (when SOP is set to 100). I have found another post on this forum (https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/885825?CC3220SF-stop-UniFlash-SLImageCreator-from-driving-the-RTS-pin-while-programming-via-UART ) explaining how we can modify the RTS line of an UART connection to reset the CC3235SF by adding the power_on.py and power_off.py scripts. Is this still the preferred way for automating a reset when using a custom ttl-usb converter? Or is there a better solution?

Thanks

Hans

Hi Hans,

What is the reason you want to bypass the XDS110?

The auto detection of the port will work only when using XDS110.

Br,

Kobi

Hey Kobi

Currently, we are designing/testing a custom board based on the CC3235SF. We want to flash it by using a generic ttl-usb converter (TTL-234X-3V3). When I try to flash (or request device information) using the ttl-usb converter. I got the 'Inappropriate ioctl for device' error whit specifying the --port option: ./dslite.sh --mode cc32xx device info --port /dev/cu.usbserial-FT3QSLVC. If I leave out the --port option, the commando fails because it is trying to connect to a XDS110 probe. (which is logical because there is no XDS110 attached to it).

When I connect the XDS110 on the CC3235SF-launchpad to our custom board (only using TxD and Rxd, I manual reset the device so RST is not needed) and using the --port option. I got the same error. When omitting the --port option, it all works because imageCreator can detect a XDS110.

This is the reason why I posted this question and why I wanted to try to flash the CC3235SF on the CC3235SF-launchpad without using the XDS110, because this gives us a more realistic scenario of what we want to accomplish.

To give you a recap:

MAC pc --> XDS110 (on CC3235SF-launchpad) --> CC3235SF (on CC3235SF-launchpad), leave out --port option ------> WORKS

MAC pc --> XDS110 (on CC3235SF-launchpad) --> CC3235SF (on CC3235SF-launchpad), with --port option ------> FAILS (Inappropriate ioctl for device)

MAC pc --> generic ttl-usb converter --> CC3235SF (on CC3235SF-launchpad), leave out --port option -------> FAILS (cannot detect XDS110)

MAC pc --> generic ttl-usb converter --> CC3235SF (on CC3235SF-launchpad), with --port option -------> FAILS (Inappropriate ioctl for device)

MAC pc --> XDS110 (on CC3235SF-launchpad) --> CC3235SF (on our custom board), leave out --port option -------> WORKS

MAC pc --> XDS110 (on CC3235SF-launchpad) --> CC3235SF (on our custom board), with --port option -------> FAILS (Inappropriate ioctl for device)

MAC pc --> generic ttl-usb converter --> CC3235SF (on our custom board), leave out --port option -------> FAILS (cannot detect XDS110)

MAC pc --> generic ttl-usb converter --> CC3235SF (on our custom board), with --port option -------> FAILS (Inappropriate ioctl for device)

Commando that I used: ./dslite.sh --mode cc32xx device info

Hopefully this gives you a beter insight on what we want to accomplish.

Thanks

Hans

It looks like the ttl-usb converter doesn't support the “break signal” ioctl which is required for our bootloader connection.

XDS does implement it and usually the UART drivers should contain it.

Hi Kobi

Honestly, I find it hard to believe that the ttl-usb converter is the problem.

As RogerMonk answered in this post: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/635118/2344247#2344247. It is possible to use a generic FTDI ttl-usb converter to flash the microchip.

I have also tried requesting the device info from our custom board using a generic FTDI ttl-usb converter on a windows pc. The ttl-usb converter can set the break signal, but then at the 'receive storage list' step I got the error: Could not open port com5.

So this means that the ttl-sub converter is able to set the 'break signal' on windows.

Is it possible that there is a bug in the uniflash software on mac? Also, do you know why I get the 'Could not open port com5' on a windows pc? 

I very appreciate all you help so far!

Greetings

Hans

Update:

I tried requesting the device info from (& flashing) our custom board on ubuntu with the ttl-usb converter from FTDI and the —port option specified. This works like expected. And it also works through the XDS110 on the CC3235SF launchpad.

Ubuntu —> generic ttl-usb —> custom board

Ubuntu —> XDS110 on CC3235SF launchpad —> custom board

I used Ubuntu 18.04.4 LTS and the latest version of uniflash (version: 6.0.0).

Do I miss some required setting or driver on a mac pc? Is it possible that you can recreate this issue on your end to debug it further?

It is mandatory for use that we can flash our custom board through a mac computer.

Thanks in advance!

Hans

EDIT:

We solved flashing on a windows machine. The problem was due the fact that I used a company laptop and there was a policy active that prohibit writing to a com port. 

The issue on macos still exists. The 'inappropiate iotl for device' comes from pyserial, because it cannot set the break signal. I have found an issue on the github page of pyserial explaining that some tweaks need to be made to successfully set the break signal on macos https://github.com/pyserial/pyserial/issues/103. Is it possible that your tools team could have a look at this, because I think there is a bug or misconfiguration in the uniflash software for macos.

I have tested this on macos catalina (10.15) and mojave (10.14)

Thanks

so just to clarify:

Does the issue exist on mac os even with XDS when using the "--port" option?

Sorry for my late reply...

Yes, that is correct.

When using the XDS on macos and specifying the --port option, it returns the 'inappropiate iotl for device'. Using the same setup on a Windows or Linux machine it all works