UNIFLASH: Flashing CC32XX over UART (using shell) results in IOError/ioctl error on MacOS

Unfortunately, the Uniflash experts are not in today.  A reply should be posted by tomorrow.

Thanks and regards,

-George

Daniel,

I am going to loop in the team that supports ImageCreater to take a look.  Which version of macOS are you running?

Regards,

John

John,

We're currently using MacOS BigSur v11.6. The version of UniFlash currently installed is v6.4.0.3394.

Regards,

Daniel

Hi Daniel,

This is a known issue using the --port command on Mac devices only. If you do not specify the port, does auto-detect work for you?

Just to be sure, what version of UniFlash are you using?

Best regards,

Sarah

Hey Sarah

Unfortunately, auto-detect doesn't work either. This because we are using a generic FTDI chip to flash our devices via UART.

Do you know if there is a timeline to fix this bug on Mac? Our can you provide us with a workaround? Currently, we are using a Windows VM on our Macs to work around this issue, but this not a sustainable solution for us.

We are using the latest version of Uniflash: v6.4.0.3394

Thanks in advance

Kind Regards

Hans Habraken

Hi Hans, Daniel,

I'm checking on this, but I may not get an answer until early next week. I will keep you updated.

Best regards,

Sarah

Hi Hans, Daniel,

While I wait on that response, can you try the ImageCreator executable released in the CC32xx SDK? It's the same command line, but a slightly newer version for use with the SysConfig tool. You can find SLImageCreator.exe in the source/ti/drivers/net/imagecreator/bin folder.

Best regards,

sarah

Hi Sarah

Still got the same issue even with the SLImageCreator tool in the latest release (5_20_00_06) of the CC32xx SDK

Have you already received a response regarding this issue?

Kind regards

Hans Habraken

Hi Hans,

I got two pieces of feedback from the tools team:

1. The auto-detect for FTDI looks at the list of TI devices, and we can expand this list by adding auto_detect_ex_ftdi.json (attached) to the imagecreator/bin folder and fill in the device properties. I'm asking for more clarification of the parameters for this json.
2. You can create a reset script for your FTDI and include it with the --script_path parameter. For example, power_on_com_xds.py (attached).

Best regards,

Sarah

Hey Sarah

We are already using the --script_path option for controlling DTR line to reset the device prior to flashing (DTR line is connected to the RST of the CC3235SF). This is also a required parameter if you use the --port option if I'am not mistaken. Regarding the configuration file, I couldn't find any reference in the uniflash documentation explaining how to configure this auto_detect_ex_ftdi.json file. Have you already heard back from the tools team for more clarification?

Kind regards

Hans Habraken

Hi Hans,

I'm still waiting for clarification, but the auto-detect option is not guaranteed to work. The reset script is the better option.

Can you share your script? Please note for Mac, the following commands are required:

serial.serialposix.TIOCSBRK = 0x2000747b
serial.serialposix.TIOCCBRK = 0x2000747a

Best regards,

Sarah

Hey Sarah,

We modified our power_off and power_on script by adding the required commands like you said and this had a positieve effect. When added, the iotctl error disappears and Uniflash is able to reset the device (power_off script), set a break signal, power on device (power_on script) and clear the break signal. We also see that Uniflash can connect to the device, but when it will receive the storage list, we now get a timeout reading data error as shown in this screenshot.

We did some further digging by connecting a logic analyzer to the RST, TxD and RxD of the generic FTDI chip. 

This diagram demonstrates that Uniflash is able to setup a communication with the device, but the moment after Uniflash clears the break signal, the RST line is pulled down and we see the timeout error. We don't see this behaviour on windows:

After the breaksignal is cleared Uniflash communicates with the device and no reset takes place.

Here are our power on and off scripts:

import time
import serial
import sys

print("[power_on_com.py] - Setting RTS(0) = high (deasserting nReset)")
self.port.setRTS(0)
serial.serialposix.TIOCCBRK = 0x2000747a


print("[power_on_com.py] - done")
print("\n")

import time
import serial
import sys


print("[power_off_com.py] - Setting RTS(1) = low (asserting nReset)")
self.port.setRTS(1)
serial.serialposix.TIOCSBRK = 0x2000747b

print("[power_off_com.py] - done")
print("\n")

Any idea why Uniflash pulls down the reset line after clearing the break signal?

Kind Regards

Hans Habraken

Hi Hans,

I am checking with the tools team, and I will have an update to you by Tuesday.

I noticed in the example script that both break commands are used. Could you check if that changes the behavior?

Best regards,

Sarah

Hi Hans,

The tools team provided both scripts for the default XDS device, hopefully they help. Please check the break commands in your own script and let me know if that resolves your issue.

power_on_com.py

power_off_com.py

Best regards,

Sarah

Hi Sarah

I tried adding both break commands in my power_off and power_on script, but I still got the same issue. I also tried your provided scripts for the default XDS device. But the problem is that we don't use a XDS device, hence we are seeing following error:

ERROR: Failed to connect to XDS110 (-260).
Check USB connection to the XDS110.

Our scripts are basically the same as yours, the only difference is that you assume the device is connected to a XDS110 probe, therefore the XDS110Reset script can be used to reset the device. We are using a custom FTDI chip, so using the XDS110 script is not an option for us. That is why we drive the RTS# pin of the FTDI chip directly to reset the device in our power_off and power_on scripts. The RTS# pin of the FTDI chip is connected to the RST pin of the CC3235SF.

It's strange that this behaviour only occurs on Mac and not on Windows, this makes me believe that there is some kind of bug on the Uniflash instance of Mac.

Do you have any other ideas on how we can get this working on Mac?

Kind Regards

Hans Habraken

Hi Hans,

Although these scripts are for a different flashing device, they were successfully tested on Mac OS.

Are you also working with the same custom scripts on the Windows PC? What is the rest of your setup?

Best regards,

Sarah

Hi Sarah,

Sorry for my late reply.

Yes, we are working with the same scripts (minus the two extra commands that are required for MAC only) on a Windows PC and this works perfect. I have created a visual presentation of our setup:

Our macbook is connected with the FTDI chip through an USB type A connection. The necessary lines of the CC3235SF chip (for flashing) are exposed and connected to the FTDI chip as visualised above.

I also created a diagram to visualise the steps performed by Uniflash:

Because we don't use a XDS chip to flash our devices, we need a way to boot the CC3235SF chip into bootloader mode. We opted to use the RTS# line of the FTDI chip to Reset the CC3235SF. As visualised, Uniflash executes the power_off_com.py script to power off the device. Here we set the RTS# pin of the FTDI chip to low with `self.port.setRTS(1)`. In step 3, Uniflash sends a break signal to let the device know to boot in bootloader mode. In step 4, we define in our power_on_com_script to set the RTS# pin of the FTDI chip to high, so the device is able to boot and detect the break signal. We can see in our logs that Uniflash is able to detect the ACK response of the device, but then the problem occurs. After step 5, Uniflash sets the RTS# pin of the FTDI chip back to low by which the device powers off and the connection to the device can not be established. This behaviour can be captured with a logic analyser:

This behaviour of setting the RTS# pin back to low only happens on MAC based machines. We don't see this on Windows based machines:

Hopefully this captures an image of our setup. If there are additional question, please let me know!

Kind Regards

Hans Habraken

Hi Hans,

One of my colleagues will be picking up support here. Due to the holiday this week, their response may be delayed.

Best regards,

Sarah

Hi Hans,

Has this issue been resolved? What is the current status?

Hi Sabeeh

No, we are still experiencing this issue on our MAC based machines

Understood, I'll reach out internally to understand why macOS is setting the RTS# line low. 

Hi Hans,

I can confirm that RTS is not manually controlled within Uniflash/ImageCreator. It appears to me that macOS is handling this line. 

One thing that might work is the following: In Windows, there is an option to "Set RTS On Close" in advanced settings. A similar option should be available for MacOS. 

Hi Sabeeh

I searched for an equivalent way for the 'Set RTS on close' UI option on MAC, but I couldn't find it.... The stty command should perhaps do the trick, but this command does not seem to be implemented properly on MAC. I have also messed around with the idea of running our setup inside a linux container, but here I quickly got stuck because mounting a serial devices inside a container is not possible with docker on MAC.