CC3100MOD Production Line Guide

Production Line Overview

Texas Instruments provides a number of resources to assist manufacturers using CC3100 modules 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 modules 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 Module in the Production Line

Production with CC3100 modules requires files to be written to the internal serial flash 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 module serial flash:

• Uniflash - A PC based utility can be used for programming 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 Modules must have their internal serial flash devices formatted with the SimpleLink file system before files can be written. If the serial flash needs to be reformatted for any reason, this can be accomplished by the following:

• Uniflash - Make a PC connection to the CC3100 module 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 module, and use host code to send a format command to the device.

After the serial flash has been formatted, there is the option to use Uniflash to load files on to the serial flash via the CC3100 UART interface. In this case, the CC3100 module reads the files sent over UART, and loads them onto the serial flash. Because the host can load files on to the serial flash through the host interface as well, there are additional options to load files to the serial flash after the host has been programmed:

• Use the host code to programmatically add files using the SimpleLink file system API.
• Over-the-Air programming can be incorporated into the host code. This will enable the downloading of content from the internet or from a local connection.

Given the above options for 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 module 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 over UART

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

• 46 - UART1 TX
• 47 - UART1 RX
• 4 - nHIB

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 module datasheet under Electrical Characteristics: http://www.ti.com/lit/ds/symlink/cc3100mod.pdf

Programming Using Uniflash

Using the Uniflash CLI

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

• 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 module via UART. Therefore, it is necessary to supply Uniflash with a COM port number for the USB to CC3100 module 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 module 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 module and begin the flashing process. At this point the CC3100 module must be reset by pulling down the nHIB line. When the nHIB 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 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 module 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 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 module should come pre-formatted. If another format of the internal serial flash is required for any reason, this can be done by the host processor if the host has the required UART connection with the CC3100 module. A reset of the CC3100 module with the transmission of a specific command sequence over UART will trigger the formatting process. Formatting the CC3100 module using the host processor instead of a PC will reduce the number of connections made between the product and the PC. The serial flash of the CC3100 module cannot be formatted by using SimpleLink API functions.

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.

4. Upon reception of the acknowledgement indication from the CC3100 device, the MCU should stop sending the break signal and flush the UART lines.

5. 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.

6. 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

7. 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 module through the host interface by using the SimpleLink file system API. 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 module 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. 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/CC3200 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 module 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 module from a PC. This would require the CC3100 module to be temporarily disconnected from the host, and connected to the PC through a UART to USB connection.
• The CC3100 module could be controlled by interfacing with a dedicated RF tester. This would require the CC3100 module to be temporarily disconnected from the host.

Testing Software options

MCU Controlled RF Testing

SimpleLink API functions are available that can put the CC3100 module 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 module. This will require access to the CC3100 module 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/CC31xx_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 module, the Radio Tool CLI communicates directly through the host interface of the CC3100 module. 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 module and the PC. Refer to the Radio Tool Wiki page for more information: http://processors.wiki.ti.com/index.php/CC31xx_%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 }}