CC3120MOD: UniFLASH 5.1.0 -> "Timed out waiting for ack"

Hi TI,

Is there any update on why we are getting the timeout errors.?? We need to ship this hardware.!!

The screen shot below shows we can successfully connect to the CC3120:

Then we get the timeout message.

Any Help, Thanks.

I have attached a Saleae Logic capture of the entire process from start when nReset is pulled low, through to the time I get the "timed out waiting for ACK" message.

In the capture RX is Rx into the CC3120 and TX is Tx from the CC3120.

You can see that UniFLASH Stops Transmitting at about the 6 second mark. Maybe it is waiting for an ACK from the CC3120?

Any help please?

Thanks,

cc3120_error.zip

Hi,

We faced a similar issue with XDS reset but it was fixed.

What is the OS you use? what is the uniflash version?

We couldn't recreate this on windows10  and Uniflash 5.1.

Sometimes switching cable or USB port solves the problem.

Br,

Kobi

Hi Kobi,

We are on Windows 10 + UniFLASH 5.1 (Latest download).

I've been using a launchpad as the serial gateway, also switched to a FTDI USB Serial bridge and have the same problem.

TI really need to open-source these tools so as we can fix these problems. We can't ship hardware because the tools crash, same problem happened a few weeks ago with a TI Bluetooth Tool. :(

I guess the only options I have is to try another PC.

Thanks.

Hi TI / Kobi,

I found a link to this thread : https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/590187?CC3220-Protocol-for-image-programming-over-UART-

And this tool: http://www.ti.com/tool/embedded-programming

Posted By @Shlomi Itzhak

I have run the tool and I have the following LOG output (Note: I have removed some unimportant things)

Image Programming v2.0.0
-----------------------------
This utility programs a binary image to a serial flash connected to CC3120/CC3220 device
Only production devices are supported (i.e. no pre-production devices)
The binary image needs to be prepared in advance using Uniflash utility

Step #1 --> connect to target device
port opened
connection succeeded
get storage list

Step #2 --> Reading version info
Reading version info completed
Bootloader version is (3, 0, 1, 1)
It's a CC3120 device
NWP bootloader already running
RawStorageWrite

Step #4/8 --> Get SRAM/SFLASH storage info

Step #5/9 --> Erasing 3 blocks from SRAM/SFLASH starting from block #0
The process of erasing blocks takes several seconds
Erasing completed

Step #6/10 --> Program image[0:10531] to SRAM/SFLASH
Image programming completed

Step #7 --> Execute bootloader patches from SRAM
enter get storage info
RawStorageWrite

Step #4/8 --> Get SRAM/SFLASH storage info

Step #5/9 --> Erasing 2 blocks from SRAM/SFLASH starting from block #33
Erasing completed

Step #6/10 --> Program image[135176:141157] to SRAM/SFLASH
Image programming completed

Step #11 --> Image programming
port opened
Programming chunk ,offset = 0, ChunkSize= 4096
wait for ack
receive ack
Data received
Received error : error number = -10275 , extended error = 3904
Programming progress = 0 %
Total programming duration = 0 seconds
Step #12 --> Reset the target device

During Image Programming, the CC3120MOD returns an error code and will not program.

Can you please tell me what the error codes are and how we can resolve this, we have to ship hardware!!

Thanks.

After some attempts I also get the device hanging at this point.

Step #11 --> Image programming
port opened
Programming chunk ,offset = 0, ChunkSize= 4096
wait for ack

It never completed the ACK

Hi,

You have error -10275 during programming. This error means SL_ERROR_FS_PROGRAMMING_ILLEGAL_FILE. What exact file do you use by Embedded programming? It is a *.ucf file?

Jan

Yes its a .UCF file generated by UniFLASH 5.1.0.

I tried many different options, including not having a service pack, etc I did notice at sometimes UniFLASH produces a .bin file of about 2048 or 4096 KB in size, but the .UCF file was only about 90 KB in size.

My main problem is that I can't use UniFLASH GUI or SlImageCreator Command Line or EmbeddedProgramming tools to program the latest batch of boards. In almost all cases it hangs on "waiting for ack" or "timeout waiting for ack"

Anything come to mind?

Thanks.

Hi,

For EmbeddedProgramming you need to use UCF file. BIN or HEX files are intended for gang programming (programming sFlash by the 3rd party SPI flash programmer). It is normal that BIN file is bigger.

Issue which you have is a pretty interesting. I suppose when you was able to connect by Uniflash GUI properly, than programming from GUI should work properly as well. But not in your case. Please try following steps:

• download CC3XXXRADIOTEST. This radio tool package includes already prepared UCF file. You can use this file for a test. Use this UCF file for test of your Embedded programming.
• in case you will not be able successfully program that UCF file by XDS, please test with USB converter like a FT232RL

Jan

Hi Jan,

Just a recap:

A. We made some sample hardware a few months ago, we were able to flash our CC3120MOD devices no problems and develop our application.

B. We have made a new production batch of hardware for customer samples and we can't program these CC3120MOD devices.

C. We CAN connect to the devices using the UART and SOP2, but we can't program any image into them as the image programming step fails when the CC3120MOD device fails to respond with an ACK on the first programming chunk.

D. The device we could program (and have shipped) had the following markings:

CC3120MODRNMM0B
LTC76000TZ 05K0
2202027391-06L0

E: One of the devices we cannot program is:

CC3120MODRNMM0B
LTC78000TZ 00JH
2372000197-06L0

To answer your questions:

1. Understood about the .UCF file.

2. I found a old version of CCS UniFLASH Version 3.4, I was able to connect to my device and I found the following information that may help:

Bootloader version: 3.0.1.1
NWP Patch 2.2.0.2
MAC Patch 1.2.0.2
PHY Patch 1.0.3.23

However when I attempted any operation such as Formatting, Programming, etc. I received a failure (which is probably expected)

Perhaps interesting, but maybe somewhat irrelevant given the age of UniFLASH 3.4 was the detected device version:

[11:37:29] INFO: > Executing Operation: Init
[11:37:29] INFO: reading version info
[11:37:29] INFO: DEVICE CC3100 ES1.21

3. The CC3XXXRADIOTEST includes the CC3120 device image UCF file. When I try and program this I get the same result:

Step #11 --> Image programming
port opened
Programming chunk ,offset = 0, ChunkSize= 4096
wait for ack

4. When I try from UniFLASH GUI V5.1.0 I get "Operation Failed, Timed out waiting for ACK"

5. I have tried all sorts of combinations of serial port adapters (Launchpads, XDS110 and FDTI USB Bridges) as well as different computers.

The only thing that seems relevant here to me is the "BTL_ram.ptc" that is included with EmbeddedProgramming does not work, or the device locks up during the image programming phase.

I don't know about what UniFLASH does behind the scenes, but I assume it has to program some bootloader too?

However as reported the CC3120MOD device is already programmed with BL 3.0.1.1 and the Manifest says the BL version is 33.0.1.1.

What do I do TI? We are loosing so much money on this its not funny any more. We need to ship our hardware, we need to program these devices.

PLEASE HELP!

Thanks.

Hi,

Thank you for a detailed description of your issue. But it would be better if you wrote that detail description at your first question. Uniflash 3.4 does not support CC3x20 devices, from this reason are any attempts with this version irrelevant.

Did you made any changes at your hardware (PCB) between your samples and 2nd production batch?

According my experiences it looks to one of this issues, if you not made any changes between your your samples and 2nd batch:

1. manufacturing (assembling) issue
   1. soldering/reflow issue under module
   2. damaged module due to non proper reflow profile
   3. wrong assembling of other parts of PCB
2. wrong module from the manufacturing
   

I think most likely is a reflow issue under module. I did not seen this kind of issue with this symptoms. But wrong reflow may produce many weird intermittent faults. Please use X-ray or BGA inspection cam and inspect soldering of module at your PCB.

Jan

Hi,

It unfortunately took 2 weeks to get a full picture developed.

The hardware has not changed between builds. Indeed we've done about 12 months of development work with CC3120MOD and CC3220MOD devices. There is not much on the CC3120MOD device to get wrong as far as connections. We have stable power supplies, good signal integrity, good bypassing, etc. on a 6 layer PCB. The only thing that has changed is the batch of CC3120 devices.

There is a third option from your list, and that is a fault in the TI software that causes the CC3120 mod to stop responding with ACK's during programming, or some other deficiency that prevents it from handling what-ever error case is occurring.

I've designed a piece of code, shown below that has allowed me to program the device under firmware control. During calls to sl_Start() on the devices we can't program with UniFLASH we get the error SL_ERROR_FS_CORRUPTED_ERR;

There are two problems with this approach.

1. I have to make a new firmware binary to suit each CC3120MOD device by reading the device using UniFLASH, generating the UCF and then embedding the UCF in code.

2. I am making calls to sl_FsProgram with 4096 byte chunks. Given the size of the UCF, I have about 3KB of remainder data. sl_FsProgram returns 0 (programming success) before all off the data has been sent. I'll start a new post about this.

Once the device is programmed under firmware control, if I attempt to program it using UniFLASH, the file system gets corrupted. I've had the CC3120MOD running our continuous integration tests for the last 48hrs, including power cycling and file writing without a fault. If it was a PCB issue, I think it would have shown up.

Cheers

Code for firmware flashing:

void vCC3X20_SM__LoadImage(void)
{

	// Default chunk size
	#define PROGRAMMING_CHUNK_SIZE 4096

	Luint32 u32UCFSize;
	Luint32 u32ProgramChunkSize;
	Luint8 *pu8DataBuffer;
	Lint32 slRetVal;
	Luint8 u8ExitFlag;

	// Pointer to the programming image
	pu8DataBuffer = &lpcba486r0_Programming[0];
	u32UCFSize = 60592;

	// Initial conditions
	slRetVal = 0;
	u8ExitFlag = 0;

	// Initial chunk size, this will change with the remainder chunk
	u32ProgramChunkSize = 4096;

	do
	{
		// When the remaining buffer size is zero, program the last chunk and exit.
		if(u32UCFSize == 0)
		{
			// Set the exit flag such that after we have programmed the last chunk we exit this loop.
			u8ExitFlag = 1U;
		}

		// Do a program, do not use a key.
		slRetVal =  sl_FsProgram(pu8DataBuffer, u32ProgramChunkSize, NULL,  0);
		if(slRetVal ==  SL_API_ABORTED)
		{
			// error, exit
			break;
		}
		else if(slRetVal == 0)
		{
			// In this case FsProgram returned 0, indicating that all of the data was programmed
			if(u32UCFSize != 0)
			{
				// This is a big error, it means that FsProgram returned 0 = Success, but we have not programmed then entire file.
				// WHY is this happening? What is wrong with the last 3KB of data, why does it not need to be programmed?

				// For now just exit, now sure why there would be remainder data to send.
				break;
			}
			else
			{
				// Exit anyhow, now
			break;
			}

		}
		else
		{
			// We were good, the value of slRetVal is incremnting with the size of the programming.
			// It does NOT return the size of the last chunk programmed, but rather an accumulated value.

			// Inc the data buffer pointer
			pu8DataBuffer += 4096;

			// Check the image size
			if(u32UCFSize >= 4096)
			{
				// Subtract the next chunk.
				u32UCFSize -= 4096;

				// Maintain our chunk size
				u32ProgramChunkSize = 4096;
			}
			else
			{
				// We have the remainder, handle it
				u32ProgramChunkSize = u32UCFSize;

				// Clear the file size now, this will be used to detect an exit.
				u32UCFSize = 0;
			}

		}

	}while(u8ExitFlag == 0U);

}

Hi,

I still believe that best explanation of your problems is a soldering issue. But because I never seen such kind of issue, I may to be wrong. Uniflash programming is done by the ROM bootloader. ROM is part of QFN chip inside module and was not changed. Maybe guys from TI support will have additional idea what may to be wrong in your case.

Meantime please provide some statistical data about your issue.

• How many devices you have manufactured at your 2nd production batch?
• How many devices was not functional (was not able program by Uniflash) and how many was functional?
• Lot numbers of modules which you was/was not able program at your 2nd manufacturing batch.

Jan

Hi Jan,

Sorry for the delays in getting back to you. 

Where would I find the lot number on the CC3120 device.?

We've also had a second design populated yesterday, totally different board design, still using CC3120MOD. Hopefully I can power that up this week and see if it has the same problems.

Thanks.

Hi stomp,

The fact that you used to be able to program boards and now can't definitely seems to point toward a HW issue.

Here are all of my thoughts though based on what I've seen throughout this thread:

1) If you want to try to decouple the issue from the version of UniFlash being used (assuming you used a version prior to v5.1 successfully), you can download a previous version of the tool here:

http://processors.wiki.ti.com/index.php/Category:CCS_UniFlash_Release_Notes_Archive

2) Your original Saleae from ImageCreator capture looks okay up to the point of getting the storage information of the device. It looks like instead of seeing a 0x31 command, the device gets a 0x3A. Seems to cause an issue where the device responds, but the response doesn't make sense. The tool ACKs the response, but goes back to the "Get Version" info command. However, the device doesn't recover.  Note that what you see on the UART lines should follow the bootloader protocol described in the Embedded Programming Guide. Refer to section 5.3 (http://www.ti.com/lit/swpa230).  

I'm not sure if the apparent error here is the source of the issues, but it seems to be where the ImageCreator tool is hung up. Again, maybe you can go back to an older version of the tool and see if you get the same behavior on the UART with your PC.

3) Looking at the results from the embedded programming attempt, it seems there could be an issue with how the data is being sent to the SimpleLink device. The error you receive is:

Received error : error number = -10275 , extended error = 3904

Which indicates that there is a problem parsing the table at the beginning of the UCF file. If you look between offset 0x00000000 and 0x00000040 in your UCF file (with a tool like hxd), you should see data that includes the pattern D4 C3 B2 A1 at the beginning and 1A 2B 3C 4D at the end. The bootloader is looking for these markers and will throw the error above if they aren't where the device expects them.

It might be helpful to see a logic capture of the host sending this data. I believe you could also pull logs from the device while trying to run this process to verify where the error occurs. http://processors.wiki.ti.com/index.php/CC3120_%26_CC3220_Capture_NWP_Logs

4) Lastly, regarding tests with the HW to try to see if there is an issue with the specific devices in the latest batch, it would be helpful if you could do an ABA swap. Take a good board, remove the device and replace the device on a failing board. Then take the device from the failing board and put it on the good one. See if the issue follows the device or the board. Of course, this requires you to have a good board left on hand. Getting one of those would probably be very helpful for isolating the issue anyway if you could still program it with ImageCreator 5.1.

Best Regards,

Ben M

Thanks Ben,

1. We can connect with UniFLASH or EmbeddedProgramming. When we try and burn the image, the tools lock up and erases the file system. I have tried every version of UniFLASH available, and have also used EmbeddedProgramming as well as some custom python. In the custom python I don't get the expected ACK either. 

2. I can program the devices from within my host CPU, we have sent our customer samples out using this method for now.

3. As mentioned we are doing new boards for a new product. I will try and get you decent Logic Captures, NWP logs and any other information you need.

4. We have one good device here, and we did swap the devices across to another board. The fault moved with the device.

It may very well be a hardware issue, but the interface is quite simple, two serial port lines, a ground and SOP2 shorted. To try and rule that out, including signal integrity issues, we've used everything from a launchpad almost directly soldered to the board, to FTDI-USB converters, to an old-school PC serial port adapter.

I don't have a time frame on the captures yet, hopefully later this week or next.

Thanks.

Hi,

Have you made any progress (or captured the NWP logs)?

Br,

Kobi