CC3220SF: stop UniFlash (SLImageCreator) from driving the RTS pin while programming via UART

Hi Ardovm,

The UniFlash ImageCreator tool will flash a .SLI file, so the scripts will reset the device where appropriate. If you would like to program a gang image (.BIN or .HEX), you must use an external serial flash programming tool.

Best regards,

Sarah

Hello Sarah,

Thank you for your reply. I must apologize, I did not explain myself well.

I need to program a board featuring the CC3220SF using UniFlash, via UART.

It is ok that UniFlash resets the MCU, but it should do using the bootloader commands.

What is happening instead, is that UniFlash is resetting "by mistake" my MCU because it is driving the RTS signal of the RS232 port to logic zero.

My question is: could TI patch UniFlash to avoid driving the RTS line while programming a CC3220SF? According to the documentation (SWPA230, SWRA568) the only UART signals used during the communication with the bootloader should be pins 55 and 57, therefore RS232 flow control should be disabled.

Thank you in advance for your help and best regards.

Hi Ardovm,

Both documents talk about the nReset pin requirement. If you have connected nReset and RTS, what behavior do you expect here? Are your python power scripts trying to drive RTS and nReset separately?

ardovm said:

We connected the nRESET signal to a RS232 signal, RTS...

Best regards,

Sarah

Hello Sarah,

yes: both documents talk about the nReset pin requirements, and do not mention the RTS signal. That is why I expect the SLImageCreator program not to drive the RTS pin.

But SLImageCreator is driving the RTS signal, and this is causing me a problem.

I hope you (as TI) can do something about this? I suppose the problem would be solved by explicitly disallowing any RS232 control flow inside the SLImageCreator program, when accessing the serial port; I have no access to its source code, therefore I cannot "patch" the program by myself.

I hope I was clear enough. Thank you very much for your attention so far!

Best regards.

Hi Ardovm,

ImageCreator is not driving the RTS signal. You should verify that this is not controlled by the UART (by turning off hardware flow control). Can you share your power_on/power_off hooks?

Best regards,

Sarah

Hello Sarah,

ImageCreator is using the UART to communicate to the CC3220SF. We never enable hardware flow control.

Here is power_on_com.py:

#!/usr/bin/env python

import sys
import subprocess
import time

port = None
for p in sys.argv:
    if p[:5] == "/dev/":
        port = p
if port is None:
    raise Exception("Cannot detect serial port among parameters")
a = subprocess.call(["./setrts", port, "1"])
if a != 0:
    raise Exception("setrts failed")
print "RTS: 1"
time.sleep(0.5)
a = subprocess.call(["./setrts", port, "0"])
if a != 0:
    raise Exception("setrts failed")
print "RTS: 0"

Script power_off_com.py does nothing (it's a Python "pass" instruction), because in fact the script power_on_com does a power cycle.

The "setrts" program is a C program that opens the COM port and drives the RTS signal according to its command-line parameter:

int main(int argc, char **argv)
{
    int a, fd, status;
    fd = open(argv[1], O_RDWR | O_NOCTTY | O_NDELAY);
    if (fd == -1) {
        perror("open()");
        return 1;
    }
    a = ioctl(fd, TIOCMGET, &status);
    if (a != 0) {
        perror("ioctl()");
        close(fd);
        return 1;
    }
    if (argv[2][0] != '0') {
        status |= TIOCM_RTS;
    } else {
        status &= ~TIOCM_RTS;
    }
    a = ioctl(fd, TIOCMSET, &status);
    if (a != 0) {
        perror("ioctl()");
    }
    close(fd);
    return a;
}

(I took out boiler-plate code such as headers and usage information)

IMHO our code is not responsible of the reset, because our script (and program) are called before ImageCreator outputs "INFO:slbootloader.slbootloader:Connection succeeded". Something seems to happen after that moment in ImageCreator, that sets to ground the RTS line.

I hope this makes sense! Thank you for your support.

Hi Ardovm,

Attached below are python scripts that we used to test RTS as the reset. Can you try these with your setup?

Best regards,

Sarah

/cfs-file/__key/communityserver-discussions-components-files/968/power.zip

Hello Sarah,

thank you very much for your assistance!

Unfortunately, this did not solve my problem: even after adapting your scripts (more on this below), the RTS line returned to GND after SLImageCreator logged:

INFO:slbootloader.slbootloader:Power on
INFO:slbootloader.slbootloader:Clear break signal
INFO:slbootloader.slbootloader:Connection succeeded
INFO:slbootloader.slbootloader:Received storage list

Why it was necessary to adapt your scripts

Your scripts access the serial port according to the following logic:

1. if I can open the port, i.e. instance a serial.Serial, then I will use that;
2. otherwise, I use the variable self.port.

This logic is probably ok under Microsoft Windows, but it cannot work under Linux, because Linux allows multiple programs to open the same serial port at the same time.

In order to have SLImageCreator receive the initial data from the CC3220SF bootloader, I had to invert the logic: use the variable self.port because it has already been opened and I should use that. If I instanced a new serial.Serial , that would most probably ``race'' against self.port for control of the physical ttyUSB device.

Proof of this: if I use your scripts verbatim, I receive a timeout error after this line:

INFO:slbootloader.slbootloader:Power on

Now that I knew of self.port I took the occasion to print its __repr__(). It shows that the port was in fact opened with flow control disabled.

Is it possible that the self.port is destroyed (or close()-ed) and then reopened with flow control enabled?

I hope my comments and questions are clear enough. I am looking forward to your kind assistance.

Best regards.

Hi Ardovm,

We do not reopen the port after usage. Could you try without flow control (no CTS/RTS) and with DTR instead? Even if Linux can share the ports, you should be able to verify that it is not already in use and use the open port as done for Windows.

Can you test the scripts as-is on a Windows machine? This will allow us to verify that there are no hardware or connection issues before we continue debugging on Linux.

Best regards,

Sarah

Hi Ardovm,

If the script works as intended on Windows, then the source of ImageCreator would not be the issue. This seems like a problem opening the port.

Best regards,

Sarah

(Please ignore the TI Thinks Resolved flag on your previous post, I hit the wrong button while trying to reply.)

Hello Sarah,

thank you for your assistance.

I suppose that the problem is in ImageCreator because I cannot see any other causes outside of it.
The scripts you sent me, as I wrote in my previous message, seem to make assumptions that are only valid under Windows.
Maybe other parts of ImageCreator rely on the same assumptions, and that could be the reason why the procedure stops? This is why I offered my help for checking the source code.

I am looking forward to your kind directions.

Best regards.