CC3100 Production Line Guide

Production Line Overview

Texas Instruments provides a number of resources to assist manufacturers using CC3100 devices produce products quickly and efficiently. From the beginning phases of designing products using these devices, reference design collateral and application notes are available to assist in schematic level design. This includes information about any considerations manufacturers should make in their designs to facilitate efficient manufacturing. During PCB layout development, layout guidelines are given as well. Software and hardware tools have been developed for programming and testing CC3100 devices in the production line. In addition, Over-The-Air programming functionality allows for products to have their software updated periodically even after they have been deployed.

Programming the CC3100 QFN in the Production Line

Production with CC3100 devices requires files to be written to the attached serial flash device for proper operation. At the minimum, this includes the service pack that contains necessary software updates and additional features. Configuration files may also be written, which provide an initial configuration for the device upon startup. Security certificates and other content such as webpages, images, scripts, etc. can be included as well. Although most of this content is usually written during production, all content including the service pack can be continuously updated over the lifetime of the product. There are 3 basic methods of loading content onto the CC3100 serial flash:

• Uniflash – A PC based utility can be used for programming the serial flash
• Gang image – Use a special binary image that is written directly to the serial flash, that the CC3100 can use to create the desired contents of the serial flash.
• Host programming – Programming the serial flash through the host processor.
• Over-the-Air Programming (OTA) – Serial flash content can be downloaded through a network connection.

All CC3100 QFNs must have their attached serial flash devices formatted with the SimpleLink file system before files can be written. There are a few ways to accomplish this:

• Uniflash - Make a PC connection to the CC3100 UART, and use the Uniflash utility to send a format command to the device
• Host programming - Make a UART connection from the host to the CC3100, and use host code to send a format command to the device.
• Gang image - Flash a gang image to the serial flash. Have the serial flash vendor pre-program the serial flash parts with the gang image. The gang image can include a command that instructs the CC3100 to format the serial flash upon startup.

After the serial flash has been formatted there are a few options to load files onto the serial flash:

• Use Uniflash to load files via the CC3100 UART interface. The CC3100 reads the files sent over UART, and loads them onto the serial flash.
• If a gang image has been flashed, the CC3100 converts the files in the image and saves them into the file system. Therefore, an additional step for loading files is not necessary.

Because the host can load files on to the serial flash through the host interface as well, it is possible to use the host to programmatically add files using the SimpleLink file system API. After the service pack has been updated, Over-the-Air programming can be used to download content from the internet or from a local connection.

Given the above options for formatting and loading content to the serial flash there are a number of production line flows that are possible. Shown below are some possible production line flows ranked roughly in order of speed.

Regardless of which programming methods are used, it is required to bring out the CC3100 UART pins to provide a reliable backup flashing mechanism. If using headers to make the required connections to the programming interface, the manufacturer should consider using a single header assembly to accommodate the entire programming and test sequence as a cost saving measure. This would include the power supply, GND, and the lines necessary for flashing the serial flash. The lines necessary for programming the host processor should be included as well.

Programming Using a Gang Image

Using this method can result in significant time savings in the case where a large amount of information must be written to the serial flash. The gang image is generally programmed on the serial flash device by the serial flash manufacturer, and therefore before it is assembled on the board. This will result in the fastest programming time out of any other method. To program the data to the serial flash via a gang programmer, it is necessary to first create a gang image that can be programmed on the target SFLASH devices. This creation process is generally performed once per product release in order to create the target image for the gang programmer. Upon power up, the CC3100 detects the presence of a gang image, and converts it to the target file system of the device. This conversion process is performed exclusively by the SimpleLink device and does not require any inputs from external interfaces. It does however extend the duration of the first power-up. This extra time should be considered when deciding what method to use in the initial programming of the serial flash. The amount of time required for the first boot after gang programming is primarily dependent on how long it takes to erase this image after the conversion is complete. This can be estimated by considering the size of the gang image, and the amount of time it takes for the serial flash to erase data.

Uniflash is the utility used for creating gang images, and it also has the ability to flash a gang image to the serial flash through UART. Instructions for creating and using gang images with Uniflash can be found here: http://processors.wiki.ti.com/index.php/CC31xx_%26_CC32xx_UniFlash#Image_Creation_and_Programming

The gang image may be programmed to the serial flash device after assembly on the board provided some considerations are taken:

• The serial flash SPI interface pins must be brought out for physical contact with the programmer (e.g. male headers, test pads)
• The SPI lines must not be driven by any other source while programming.
• The CC3100 will be held in hibernate during programming to prevent contention.

Programming over UART

Formatting and/or writing files to the serial flash device through the CC3100 UART interface requires the use of the following CC3100 pins:

• 55 - UART1 TX
• 57 - UART1 RX
• 2 - nHIB or 32 - nRESET (either can be used)

The UART TX and RX pins are used for data transfer. RTS and CTS signals are not used. The nHIB and nRESET pins are used to reset the device. The UART data transfer occurs at 921600 bps. Because of this, other methods of writing files to the serial flash may takes less time.

The UART configuration is as follows:

• Baud rate: 921600
• Data bits: 8 bits
• Flow control: None
• Parity: None
• Stop bits: 1
• Polarity: Positive

The CMOS logic level specifications for the UART can be found in the CC3100 datasheet under Electrical Characteristics: http://www.ti.com/lit/ds/symlink/cc3100.pdf

Programming Using Uniflash

Using the Uniflash CLI

The Uniflash utility is PC software which can perform the following operations on the CC3100:

• Format the serial flash
• Add or remove files on the serial flash
• Update the service pack

These operations are accomplished by communicating with the CC3100 via UART. Therefore, it is necessary to supply Uniflash with a COM port number for the USB to CC3100 UART connection. See the chapter Programming over UART for details on the UART connection. Uniflash contains a command line interface which can be used in batch files/scripts for the purposes of programming the CC3100 devices in the production line. With a single line command, Uniflash can format the serial flash, update the service pack, and add any number of files. For example:

   uniflashCLI.bat -config "C:\ti\uniflash_3.2\cc3xxx\sessions\uniflash_template\oob.ucf" -setOptions com=50 secure=false spPath="C:\servicepack.bin" -operations format servicePackUpdate program

When Uniflash begins, it will prompt the user to restart the device. This is so it can synchronize with the CC3100 and begin the flashing process. At this point the CC3100 must be reset by pulling down either the nHIB or nRESET lines. When the nHIB or nRESET line resumes a logic high state, the flashing procedure will begin. In the production line this reset process can be realized by using a button or other mechanism which temporarily connects the line to GND. Refer to the Uniflash Wiki for complete information on how to use Uniflash.

UART Hardware Connection Using the FTDI emulation board

The CC31XXEMUBOOST can provide the required USB to UART interface for formatting and programming the serial flash via UART. The PC drivers for this board are included in the CC3100 SDK, and they should be installed during installation of the SDK. The CC31XXEMUBOOST is connected via USB from socket J6 to the PC. The jumpers on the CC31XXEMUBOOST should be connected as shown below.

The CC31XXEMUBOOST uses a logic level of 3.3 V by default, but there are level shifters on the CC31XXEMUBOOST and it can be powered in-dependently with a different IO voltage. This can be accomplished by removing the jumper from J4, and applying the external power to pin 1 of jumper J4. On the product being programmed, the relevant CC3100 pins must be brought out for physical contact with the programmer (e.g. male headers, test pads), and must be driven by no other source while programming. The nHIB or nRESET pin must be able to be temporarily pulled to GND during a reset which occurs at the beginning of Uniflash flashing procedure. The pulling down of this line can be enabled by the addition of a button or something similar to the test jig.

Programming with the Host

Formatting Using Host UART connection

The CC3100 QFN may have its serial flash formatted by the host processor if the host has the required UART connection with the CC3100. A reset of the CC3100 device with the transmission of a specific command sequence over UART will trigger the formatting process. The serial flash of the CC3100 device cannot be formatted by using SimpleLink API functions. Formatting the CC3100 serial flash using the host processor instead of a PC will reduce the number of connections made between the product and the PC. If this is the case, files will generally be written to the CC3100 serial flash either by SimpleLink API, or by using OTA.

The procedure to format the device is as follows:

1. Send a break signal (sending continuous Spacing values (no Start or Stop bits)) on the CC3100 UART RX line. The CC3100 device needs to sense this break signal during powering on.
2. Power on the CC3100 device (or reset if already up and running)
3. The CC3100 device should send an acknowledgement indication on the CC3100 UART TX line.

The acknowledgement indication is two bytes long: 0x00 0xCC

Note: At this point, the CC3100 is ready to receive commands such as format. There is a 5 second timeout for the MCU to send the format command. Failing to do so before the timeout expires would result in CC3100 device initializing normally.

1. Upon reception of the acknowledgement indication from the CC3100 device, the MCU should stop sending the break signal and flush the UART lines.
2. MCU should send the string of characters on the CC3100 UART RX line according to the capacity of the serial flash. The supported capacities are described in the table below along with their matching strings.
3. Upon completion of the format operation, the CC3100 device should acknowledge on the CC3100 UART TX line.

The acknowledgement indication is two bytes long: 0x00 0xCC

1. Invoke the sl_Start() function. The CC3100 device should initialize with the new Service Pack.

Flash Capacity [MB]	Formatting string (bytes hexadecimal)
0.5	0x00,0x17,0xAC,0x28,0x00,0x00,0x00,0x02,0x00,0x00,0x00,0x80,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02
1	0x00,0x17,0x2D,0x28,0x00,0x00,0x00,0x02,0x00,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02
2	0x00,0x17,0x2E,0x28,0x00,0x00,0x00,0x02,0x00,0x00,0x02,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02
4	0x00,0x17,0x30,0x28,0x00,0x00,0x00,0x02,0x00,0x00,0x04,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02
8	0x00,0x17,0x34,0x28,0x00,0x00,0x00,0x02,0x00,0x00,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02
16	0x00,0x17,0x3C,0x28,0x00,0x00,0x00,0x02,0x00,0x00,0x10,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02

To summarize the procedure, please see the below graphic illustration:

Writing Files to the Serial Flash from the Host

Files may be written to the CC3100 serial flash through the host interface by using the SimpleLink file system API, after the serial flash has been formatted. Data for the files could come from a number of sources:

• Files can be stored as arrays in host code. This method is simple to implement and is most practical for small amounts of data.
• Data can be read in to host memory by a serial peripheral of the host such as SPI, SDIO, or JTAG. This is more practical for larger amounts of data.
• The host can also retrieve data using a Wi-Fi connection from a remote or local server.

If the data rate of the connection from the host to the outside data source is significantly faster than that of the Uniflash UART connection (921600 bps), a time savings over programming using Uniflash can be realized. There are a small number of functions in the SimpleLink API for performing file operations:

• sl_FsOpen() - Open a file for read, write, or create
• sl_FsClose() - Close a file
• sl_FsRead() - Read block of data from a file
• sl_FsWrite() - Write block of data to a file
• sl_FsGetInfo() - Get information for a file
• sl_FsDel() - Delete a file

The complete documentation for the file system API can be found inside the CC3100 SDK folder at docs\simplelink_api\programmers_guide.html. For details on the operation of the file system see section “Serial Flash File System” in the Network Processor Subsystem Programmer’s Guide: http://www.ti.com/lit/ug/swru368/swru368.pdf.

Given that all files can be written to the serial flash by using the SimpleLink API, the service pack can be updated by this method as well. The service pack binary image contains a set of patches on top of the ROM version. Each service pack must be authenticated by the CC3100 device as part of its secured file system. Thus a service pack includes two files: one is the binary image itself and the other is the image digital signature. The service pack can be downloaded from: http://www.ti.com/tool/cc3100sdk

This package contains 2 formats of binaries:

1. Firmware binary used by Uniflash tool.
2. OTA binary along with its signature file. The OTA version can be used by the host MCU and can be programmed into the serial flash using the file system API. These OTA binaries are used for over the air updates but can also be used for host programming.

After successfully installing the package (in this case for service pack v1.0.0.1.2), the following two files can be found:

• OTA_1.0.0.1.2.ucf.ucf – this is the service pack binary
• OTA_1.0.0.1.2.ucf.signed.bin – this is the signature of the service pack

The procedure to program the service pack is as follows:

1. Make sure the service pack image and its 256 byte signature are converted to C-arrays and stored on your host MCU memory
2. Open the service pack file with the following configuration:
   1. Open to write/create (if not exists)
   2. Maximum size should be set to 128KB
   3. Flags:
      1. Commit
      2. Secured
      3. Public write
3. Write the service pack image

Note: It is mandatory to write the files in 16 byte aligned chunks.

1. Close the file. Upon closing a file, its signature must be provided as well. The certificate should be left NULL.

The following is a code snippet illustrating the procedure:

   /* create/open the servicepack file for 128KB with rollback, secured and public write */
   retVal = sl_FsOpen("/sys/servicepack.ucf", FS_MODE_OPEN_CREATE(131072,_FS_FILE_OPEN_FLAG_SECURE|_FS_FILE_OPEN_FLAG_COMMIT|_FS_FILE_PUBLIC_WRITE), &Token, &fileHandle);
   
   if(retVal < 0)
   {
       /* cannot open Service Pack file */
       return -1;
   }

   /* program the service pack */
   remainingLen = sizeof(servicePackImage);
   movingOffset = 0;
   chunkLen = (_u32)find_min(1024 /*CHUNK_LEN*/, remainingLen);
   /* Flashing is done in 1024 bytes chunks because of a bug resolved in later patches */
   
   do
   {
   retVal = sl_FsWrite(fileHandle, movingOffset, (_u8 *)&servicePackImage[movingOffset], chunkLen);
   
       if (retVal < 0)
       {
           /* cannot program ServicePack file */
           return -1;
       }
   
       remainingLen -= chunkLen;
       movingOffset += chunkLen;
       chunkLen = (_u32)find_min(1024 /*CHUNK_LEN*/, remainingLen);
   
   }while (chunkLen > 0);
   
   /* close the servicepack file */
   retVal = sl_FsClose(fileHandle, 0, (_u8 *)servicePackImageSig, sizeof(servicePackImageSig));
   
   if (retVal < 0)
   {
       /* cannot close Service Pack file */
       return -1;
   }

An example for programming the service pack via host is available in the CC3100 SDK: http://www.ti.com/tool/cc3100sdk

Over the Air Programming

The CC3100 has the capability for Over-the-Air programming which allows for files to be written and updated over a network connection. An OTA programming library is available in the CC3100 SDK. The OTA update scheme relies on a subroutine that periodically checks with a remote OTA server to see if there are any available file updates. The OTA server will respond to such requests with a list of resources to update, and will also respond to requests for locations of those resources on the internet. The OTA client that runs on the MCU will download the listed resources from the locations specified by the OTA server. In the field, the resources will typically reside on a Content Delivery Network (CDN). The MCU can test the validity of the files before committing them. The committing of the new version of the file causes it to be used in place of the old one already stored in serial flash.

Using OTA in the production line can enable faster data transfer over other methods. For using OTA in the production line, a PC on the local network can run the OTA server, and can also run the content delivery server for the resources as well. The service pack should be updated before doing OTA or using any wireless functionality. For the fastest transfer of data using OTA, it is recommended to minimize RF congestion in the production environment. The OTA User’s Guide can be found in the CC3100 SDK folder at docs/CC3100 Simplelink OTA Extlib API User's Guide.chm.

Production Line RF Testing

Testing of hardware and software functionality is highly specific to each product, but there are some tools Texas Instruments has made available to assist with testing RF performance. The CC3100 can be instructed to perform RF testing operations in a number of ways:

• The host code may have a built in subroutine that is dedicated to RF testing. This could be run once upon first power-up, or could be triggered using a special external command.
• A SimpleLink Studio program or a script using the Radio Tool CLI could control the CC3100 from a PC. This would require the CC3100 to be temporarily disconnected from the host, and connected to the PC through a UART to USB connection.
• The CC3100 could be controlled by interfacing with a dedicated RF tester. This would require the CC3100 to be temporarily disconnected from the host.

Testing Software options

MCU Controlled RF Testing

SimpleLink API functions are available that can put the CC3100 device into modes used for RF testing. This allows for:

• Transmission of packets at specified channels, modulations, etc.
• Receipt of packets while gathering statistics for RSSI, modulation, etc.
• Carrier wave transmission

See the Transceiver Mode page for information on how to use these features. For comprehensive information about the SimpleLink API, see the Programmer’s Guide in the CC3100 SDK at: docs\simplelink_api\programmers_guide.html.

The Radio Tool library provides a set of convenience functions for RF testing, and can be ported to any MCU:

• RadioToolOpen() - Initializes the device in preparation for RF testing
• RadioToolClose() - Stops the device
• RadioStartTX() - Transmit packets
• RadioStopTX() - Stop transmission
• RadioStartRX() - Start receiver
• RadioStopRX() - Stop receiver
• RadioGetStats() - Get statistics regarding received packets
• RadioGetMacAddr() - Retrieve MAC address of device
• RadioGetDeviceVersion() - Retrieve device Firmware version numbers

Refer to the Radio Tool wiki page for Radio Tool library source code, and for information on how to incorporate RF testing functionality into an MCU application.

PC Controlled RF Testing

SimpleLink Studio

SimpleLink Studio can be used to run a PC application to perform any function with the CC3100. This will require access to the CC3100 host interface, and thus it will need to be disconnected from the host to prevent contention. Usually this is combined with the CC31XXEMUBOOST to assist with development of software independently of hardware, but it may be used for testing purposes as well. It may be useful especially in cases where the host code cannot implement testing routines itself. SimpleLink Studio can be run on Microsoft Visual Studio, or Eclipse environments. Refer to the SimpleLink Studio Wiki page for more information: http://processors.wiki.ti.com/index.php/CC3100_SimpleLink_Studio

Radio Tool CLI

The Radio Tool command line interface is a PC based tool that can be used to perform RF tests on CC3200/CC3100 devices. Generally, it will be incorporated into in scripts or batch files used for production line testing. When used with the CC3100, the Radio Tool CLI communicates directly through the host interface of the CC3100. Because of this, the host interface will need to be temporarily disconnected from the host to prevent contention. This tool requires use of the CC31XXEMUBOOST for communication between the CC3100 and the PC. Refer to the Radio Tool Wiki page for more information: http://processors.wiki.ti.com/index.php/CC3100_%26_CC32xx_Radio_Tool

Testing with an Access Point

A straightforward method of checking for acceptable RF performance is to put the device being tested through a trial run in an RF environment with worst case conditions. Such a trial run would begin with the device under test connecting to an access point, and then communicating with either a PC on the local network or with a remote cloud server. The communication between the device under test and its peer can be monitored for reliability and speed. In order to get consistent and relevant results for all devices being tested, some actions may be taken with respect to the controlling RF environment for this type of testing:

• Minimize unintentional RF congestion in the test area. This can be accomplished by turning off other nearby 2.4 GHz band devices, and/or performing the testing in an RF shielded enclosure.
• Introduce controlled RF congestion. This can involve something such as having another device connected to the same access point, which transmits a steady stream of packets to the access point.
• Introduce attenuation in the antenna path for the access point, or place at a distance from the device being tested.
• Set the access point to communicate only on a specific channel, modulation, etc.

Board to Board RF Testing

For performing RF tests, it is possible to use one CC3100/CC3200 device to test the RF performance of another. One CC3100/CC3200 device in this case will be designated as a “golden device”: where the device is proven to have good RF characteristics, and will be used to measure the performance of devices under test. These devices would generally put into modes allowing for direct control of TX parameters, and measurement of RX statistics. This can be accomplished through using the Radio Tool CLI, the Radio Tool library, or the SimpleLink API directly. Due to limitations in the FTDI driver, 2 computers must be used to do board to board testing if using the Radio Tool for both the DUT and the golden device. One computer will control the golden device, and the other will control the DUT.

Synchronization between the DUT and the golden device may be achieved by having them communicate through a different channel of communication (other than Wi-Fi), or by using an algorithm similar to the following:

DUT algorithm:

   1. Send packets to Golden board for 4 seconds
   2. Start receiver
   3. Wait 4 seconds
   4. Measure PER and/or RSSI of received packets
   5. Stop receiver
   6. If PER and/or RSSI is acceptable
         Return success
      else
         Return failure

Golden board algorithm:

   1. Start receiver
   2. Wait 2 seconds
   3. Measure PER and/or RSSI of received packets
   4. Stop receiver
   5. If >=1000 packets received, and PER and/or RSSI is acceptable
         Send packets to DUT for 4 seconds
   6. Go to 1

Note that for this algorithm, the Golden board continues its routine indefinitely so that no intervention is required for it to function with a continuous supply of DUTs. The basis of this algorithm is that receipt of packets of an acceptable quality by the Golden board will result in a reply by the Golden board with its own packets, which will then be judged for quality by the DUT.

Please note that the DUT and the golden device must be shielded from outside RF signals. This is necessary to ensure one device is reporting statistics only for packets sent from the other. This means that if performing radiated tests, both devices should be in a single shielded enclosure. If performing conducted tests, the DUT and the golden device should be in separate shielded enclosures with an attenuation system connecting them. This is because any PER measurements will be invalidated by RF leakage from the surface of one board to the other. If the DUT and the golden device synchronize with each other through a separate communication channel, steps should be taken to ensure the physical path for that channel does not carry any RF energy that would interfere with the measurements.

Dedicated Wireless Test equipment

Using dedicated wireless testing equipment can be used if RF performance measurements with a high level of accuracy are required. Typically this will also require the use of an RF probe connector (e.g. U.FL, Murata UMC) for conducted tests, but in a carefully controlled environment radiated tests could be performed as well.

Testing with Litepoint

In collaboration with Litepoint, Texas Instruments provides support of testing CC3100/CC3200 devices with Litepoint testers. The computer that is performing the testing would be connected to the Litepoint tester via an Ethernet connection and to the DUT using a UART connection. Litepoint’s console based test tool would run on the PC, and be incorporated into the production line test script. Visit www.litepoint.com for more details.

Links

{{#invoke: Navbox | navbox }} {{#invoke: Navbox | navbox }}