This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3200-LAUNCHXL: FTDI Reading ACK Signal Failed (MacOS and Windows)

Part Number: CC3200-LAUNCHXL
Other Parts Discussed in Thread: UNIFLASH, CC3200, , CC3100

Hi there,

I've only seen this issue on E2E a couple times, with no actual resolution.

In attempting to connect to the CC3200 using UniFlash (3.4.1), I am getting the following:

[17:25:14] Begin ServicePackProgramming operation.
[17:25:15] INFO: > Executing Operation: Connect
[17:25:15] FATAL: --- Can't connect to device !! ---
[17:25:18] FATAL: Error connecting to the device. Please check your COM port settings. Error code: 1
[17:25:18] INFO: > Executing Operation: Disconnect
[17:25:18] Operation ServicePackProgramming returned.
[17:25:51] Begin ServicePackProgramming operation.
[17:25:52] INFO: > Executing Operation: Connect
[17:25:54] INFO: setting break signal
[17:25:55] INFO: detecting FTDI for device reset
[17:26:11] ERROR: ---reading ACK signal failed---
...
[17:52:46] WARNING: ---seting break signal to false failed---
[17:52:48] INFO: setting break signal
[17:52:49] INFO: detecting FTDI for device reset
[17:53:05] ERROR: ---reading ACK signal failed---
[17:53:05] WARNING: ---seting break signal to false failed---
[17:53:05] FATAL: --- Can't connect to device !! ---
[18:06:06] FATAL: Error connecting to the device. Please check your COM port settings. Error code: -3
[18:06:06] INFO: > Executing Operation: Disconnect
[18:06:06] Operation ServicePackProgramming returned.

I've tried resetting the launchpad, with and without SOP2 Jumper, with and without J8-J11. 

I have successfully connected to the device on MacOS in the past as well, but the failed ACK is occurring there now too as the CCS debugger is no longer connecting. I've also tried using cc3200tool but ACK failed there too.

Can anyone describe what's happening? I suspect something is wrong with the FTDI device on the Launchpad, but can't find enough information in the documentation to figure it out.

Thank you!

  • Hi,

    Basically, SOP2 should be connected and the COM port should be free.

    Are you sure the COM port is not taken? do you see the COM port on device manager?

    If you see the COM port on the device manager with no errors, SOP2 is connected and still get this error, something got broken.

    It can be the FTDI chipset or the CC3200 itself.

    Can you also share a picture of the launchpad?

    Regards,

    Shlomi

  • I don't think COM port is taken, since I can open a serial connection on it (with putty for example). 

    SOP2 is on.

    It had been working the night before, and I left it plugged in overnight. the next day, after unplugging and replugging it, the connection issue started.

    Any idea on what might've occurred so I can avoid this happening again? Or any steps I can take to figure out if its the FTDI device or the CC3200 itself?

  • Another datapoint: Attempting to use CCS (12.5.0) to connect to the launchpad and debug a project appears successful from CCS, but is not reflected on the board. (It had been working prior)

    For instance, when I attempt to build and debug the example blinky program, CCS doesn't throw any complaints and happily allows me to step through and run code. However, the LEDs on the board remain unchanged from their startup state.

  • Update: I tried to connect to a different CC3200-LAUNCHXL and got the same error, so now I'm thinking there's a driver issue somewhere. I will attempt a reinstall of Uniflash and the sdk and hopefully the drivers will reinstall.

    Nope, I was just dumb and left the SOP2 jumper off that time.

    The original problematic Launchpad is was then also able to connect to UniFlash with SOP2 on. 

    I then tried to connect from macOS using the cc3200tool, with initial success at connection.

    However, when I attempted to read the /sys/servicepack.ucf file, it failed. After that, the "reading ACK signal failed"  message returned on both MacOS and Windows.

    Repeating the Uniflash and sdk reinstall did not help.

    I am planning to try connecting the other board to Mac to see if it's actually Mac causing the connection problem.

    I found this old thread:

    https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/470385/cc3200-reading-ack-signal-failed-with-uniflash

    Manual reset did nothing.

    Loopback test passed (J6 -> J7)

    Anything else I could try?

  • Hi,

    So with SOP2 connected you are able to communicate with the boot loader. You can double check by getting a success when trying to click the 'Get Version' from Uniflash main screen.

    How did you try to read the ServicePack? Basically this specific file cannot be read but Uniflash also doesn't have this option. Can you show me how you tried it?

    Shlomi

  • So with SOP2 connected you are able to communicate with the boot loader. You can double check by getting a success when trying to click the 'Get Version' from Uniflash main screen.

    I left the board in my lab and won't be able to try this until later this week, but I will attempt that and get back to you.

    How did you try to read the ServicePack? Basically this specific file cannot be read but Uniflash also doesn't have this option. Can you show me how you tried it?

    Well that explains why it couldn't be read when I tried at first then. I don't have the logs anymore, but I basically noted on uniflash that when I did the servicepack update, the log says it wrote the bin file to /sys/servicepack.ucf so I assumed that it was present. I was using the cc3200tool to try to read that out when I was on Mac, but if it's write-only then that failing makes sense. 

    As to why I need it on mac, it's because I'm a TA for an embedded systems course and the course was originally designed for windows (since ti tooling had only been for windows at the time) so now our students who have mac machines would otherwise have to obtain an expensive windows license that our university no longer provides. 

  • Hi,

    I don't know this tool (don't think it is a TI tool). Anyway, the servicepack is 'public write' meaning you can update it but not read it. This is why it fails.

    You can try a user file just to make sure read operation works.

    Let me know if you need anything else.

    Regards,

    Shlomi

  • Reading the servicepack was not the original problem, the original issue was the lack of ACK signal. 

    My understanding about this as of now is that I have SOP2 on, and the COM port is not occupied, then something is wrong with the FTDI chip or the CC3200 itself. 

    Given that the loopback test succeeds per a previous thread, am I to assume that the FTDI chip is working, but the CC3200 is faulty? 

    I suppose I can attempt to set a GPIO pin on the FTDI chip manually to confirm that the FTDI chip is ok. I'll try it later this week.

    Otherwise, is there any way to verify that the CC3200 IC is functional?

  • Hi,

    The loopback by itself means the UART TX and RX are operational but there is the nReset line that is also controlled over the FTDI to reset the device when needed. This is not covered in your test but you can also manually reset.

    Best to debug would be to have NWP log from the devices but since it is CC3200 and not CC3100, you nned to program it as part of the mcu image application which is not possible at the moment.

    Another way is to record the UART lines.

    If you have another Launchpad that works, you can always use its FTDI and blue-wire the working FTDI with the CC3200 (and vice-versa) and eliminate what is broken.

    Regards,

    Shlomi