In case user flashed other SDK applications and need to download the out of box content again, follow below steps Open examplesoutofboxhtmloutofbox.ucf session file in Uniflash. Flash the files to the device. Detailed instructions at Uniflash User Guide. The ccs is running on mac, just the sdk files and projects are from a drive mounted by the virtual machine since the sdk cannot be installed on mac os x. The jumper configuration is as shown in the tutorial, all projects compile without errors, some generate a couple warning messages with paths like.
CC3200 HTTP Client Project
http-client C-source code
Project on Hackaday
http_client_demo project - remotely view your CC3200 data and control LED at http://cnktechlabs.com/webapp_pub/grid.php
I have developed a simple web application for the CC3200 development board, an AK9753 Human Presence Sensor Breakout board , and an on-board TMP006 sensor.
The web application displays data collected from all sensors and allows to switch (ON/OFF) the on-board Red LED. I am planning to add more functions to the web application.
Show below is the image of my current circuit wiring diagram. The MB1212 Maxbotix sensors will be used as motion sensors in the project.
The CC3200 LaunchPad development board has an on-board temperature sensor (TMP006-Infrared Thermopile Sensor in Chip-Scale Package) and an accelerometer. Both sensors use I2C bus for data transfer.
A note on the AK9753 sensor
The AK9753 is a low power and compact infrared-ray (IR) sensor module. It is composed of four quantum IR sensors and an integrated circuit (IC) for characteristic compensation. The four IR sensors' offset and gain variations are calibrated at shipment. An integral analog-to-digital converter provides 16-bits data outputs. The AK9753 is suitable for several feet human detector by using external lens.
The AK9753 datasheet link.
Click on the image below to view the web-app:
To run a quick test of the project with your CC3200 development board:
- Download and install the CC3200 SDK on your PC.
- Download C-source code files from the Github. One of the files listed on the Github is a zip file of the CCS project (CC3200_client(CCS-project).zip).
You can download and unzip the file. - Connect CC3200 development board to a computer.
- Open a serial terminal on your PC and Set: COM PORT X, 115200 bps, 8N1, no parity, no flow control.
- I recommend (it is not required) changing the MAC address from a default one. The MAC address will be used as a unique ID number to monitor data sent by your board. To set a new MAC address enter unique values as shown below MAC_Address[0] .. MAC_Address[5]. After the board is programmed you will need to press and hold SW3 and push the Reset button while pressing SW3. Afetr a 10 - 15 seconds you see ' MAC address is set to: XX:XX:XX:XX:XX:XX' printen on a serial terminal:
- Enter your WiFi credentials (SSID name and password) in the common.h file:
- Save your project with the new credentials and compile it.
- Once the project is compiled the 'CC3200_client_web.bin' will be located in the Release folder:
- Program the CC3200 board with the CCS uniflash.
- If you want to change the MAC address from the default one, press and hold SW3 and push the reset button. Keep SW3 pressed untill the new MAC address is set and printed. This may take 15-20 sec
- Write down the number shown below. This is the ID number of your board. You will need it to display your data on the web-page. Conver the HEX value to a decimal and enter it on the web-app page as the ID number:
- Monitor and control CC3200 board from cnktechlabs.com/webapp_pub/grid.php.
- Enter the ID number in a decimal format:
The main.c file:
The buffer 'buf' is loaded below with all the information that will be sent to the cloud:
HTTP POST method is used here to send data to a server to create/update a resource.
Project Details:
The C-source code has beed updated. The new code allows remote control and monitoring of the CC3200 board with AK9753 (Qwiic) sensor connected to I2C port. The SparkFun AK9753 Human Presence Sensor Breakout is a Qwiic-enabled, 4-channel Nondispersive Infrared (NDIR) sensor. The board reports data collected from the AK9753 Human Presence sensor to the grid.php webpage, the onboard TMP006 I2C digital temperature sensor, and current status of the Red LED. The same webpage can be used to turn ON or OFF the onboard red LED. AK9753 is connected to I2C lines on the board - PIN_01 is the SCL and PIN_02 is the SDA. Compile and download CC3200_client.bin file into CC3200 development board. Connect Dev board to a PC. View USB messages on a Serial terminal on your PC. Monitor status of CC3200 sensors and Red LED as well as control the Red LED from cnktechlabs.com/webapp_pub/grid.php webpage.
How the data is transmitted and received over the web:
In the main file there are two functions:
- HTTPPostMethod_data(&httpClient);
- HTTPGetPageMethod(&httpClient);
They are used to transmit data to, and receive data from the grid.php webpage. The first function posts data to the grid.php web-page approximately once a minute.
The second function from the list receives commands from the grid.php web-page every 4-5 seconds.
The data that is sent over the web link is collected in the char buf[99] buffer:
Inside the buffer the data string looks as follows:
IR1=644 & IR2=494 & IR3=410 & IR4=562 & RoomT=22.90 & TName=controllall
The following code snippet reads current state of the Red LED and saves it in the buf buffer.
Once all data is collected it is sent over the Wi-Fi link.The HTTPPostMethod_data will send data:
static int HTTPPostMethod_data(HTTPCli_Handle httpClient);
Inside the HTTPPostMethod_data funtion HTTPCli_sendRequest will built a HTTP request:
lRetVal = HTTPCli_sendRequest(httpClient, HTTPCli_METHOD_POST, POST_REQUEST_URI, moreFlags);
lRetVal = HTTPCli_sendRequestBody(httpClient, buf, (sizeof(buf)-14)) function will send data saved in buf over the web.
The data is also streamed over the USB cabel to a local PC:
Project Start:
Recently I started tinkering with the http_client_demo CC3200 example project. The code demonstrates different HTTP web services methods: like GET, POST, PUT, and DELETE. My goal is to write a code that will connect CC3200 wireless MCU board to my website and send temperature and accelerometer data over the internet.
I am going to start with the GET method and then continue with the POST method.
The GET method
The GET method sends URL page as well as data in a single string. The page and the encoded information are separated by the ? character.
http://www.cnktechlabs.com/get.php?name1=value1&name2=value2
The text that follows the ? is the query string.
The GET method is restricted to send up to 1024 characters only.
To test the GET method I have created and uploaded /get.php PHP file to my website (www.cnktechlabs.com/get.php).
String sent by CC3200 to www.cnktechlabs.com - 'www.cnktechlabs.com/get.php?id=goodbye&mode=run'
Below is the php code for the get.php page.
To get a response from a web page with the PHP code shown above I send the following string (main.c):
This is how I send a request to www.cnktechlabs.com/get.php file:
GET(parameters) -----------------------> www.cnktechlabs.com/get.php?id=goodbye&mode=run'
The web page get.php receives the data sent by the http client (CC3200 development) board and echoes it back.
Response from www.cnktechlabs.com/get.php file:
CC3200 (the response is printed on a serial interface) <---------- www.cnktechlabs.com/get.php
Response from the server printed on a serial terminal:
As you can see from the above printout the get.php page replies with page content that includes punctuation marks and html tags.
Using the GET method from the http_client_demo.c code example:
The data is appended to the URL as a series of name/value pairs. After the URL web address has ended, we include a question mark (?) followed by the name/value pairs, each one separated by an ampersand (&).
Image below shows the response from the get.php webpage printer on 'Termite' serial terminal.
As you can see from above image the get.php responds with html tags and text inside the tags, as well as text echoed from the PHP code.POST method
A POST request passes parameters in the body of the HTTP request, leaving the URL untouched. I have uploaded the following file to my server - www.cnktechlabs.com/post.php:
post.php
The POST method implementation with CC3200 Code:
Server response:
Hi Mom
The next step is to collect and send some data to a webpage. I have created post.php and data.html webpages to collect and display data. The 'post.php' file shown below is responsible for reading data from the CC3200 board.
main.c:
HTTPPostMethod_data function, shown below, will send temperature, accelerometer, and location data to the post.php file.
Below is the result I can view on my data.html webpage.
Image of the serial print out on the Termite Terminal
Below is the result I can view on my data.html webpage.
A new hardware addition to the project - Light Sensor
Light Sensor senses ambient light and transmits messages to the web page. The data out, DO, pin of the sensor is connected to GPIO_03, PIN_58 on the development board.
Current Project Circuit Diagram
Project Source Code
Settings for the serial port: 115200, 8N1, no handshake.
Enter PASSWORD and SSID name in the 'common.h' file
Change location (strPtr = ' & loc=Los Angeles 0'; // Your location.) to your geographical location in the source code main file.
Flush the project into your CC3200 board, and view the results on the www.cnktechlabs.com/data.html. Connect CC3200 to a serial terminal on your PC.
Reset the board.
To enter password and SSID name either:
Press and hold SW2 and reset the board
On prompt 'Enter Password' enter WiFi password
On prompt 'SSID name' enter WiFi name.
Or just reset the board and the common.h credentials will be used.
NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
- 5Programming Using Uniflash
- 7Production Line RF Testing
- 7.1Testing Software options
- 7.1.2PC Controlled RF Testing
- 7.4Dedicated Wireless Test equipment
- 7.1Testing Software options
Production Line Overview[edit]
Texas Instruments provides a number of resources to assist manufacturers using CC3200 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 CC3200 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 CC3200 QFN in the Production Line[edit]
Production with CC3200 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. The host program which runs on the internal Cortex M4 is stored on the serial flash also. 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 host program and the service pack can be continuously updated over the lifetime of the product. There are 3 basic methods of loading content onto the CC3200 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 CC3200 can use to create the desired contents of the serial flash.
- Over-the-Air Programming (OTA) - Serial flash content can be downloaded through a network connection.
All CC3200 QFNs must have their attached serial flash devices formatted with the SimpleLink file system before files can be written. There are a number of ways to accomplish this:
- Uniflash - Make a PC connection to the CC3200 UART, and use the Uniflash utility 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 CC3200 to format the serial flash upon the next boot of the device.
After the serial flash has been formatted there are a couple of options to load files onto the serial flash:
- Use Uniflash to load files via the CC3200 UART interface. The CC3200 reads the files sent over UART, and loads them onto the serial flash.
- If a gang image has been flashed, the CC3200 converts the files in the image and saves them into the file system. Therefore, an additional step for loading files is not necessary.
Sketch license key crack mac.
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. If the CC3200 is flashed with a program that can do OTA programming, the entire serial flash contents can be reprogrammed using OTA programming. This will enable the downloading of content from the internet or from a local connection. This may be advantageous if using a small OTA program to load the final contents onto the serial flash.
Given the available options for formatting and loading content to the serial flash there are a couple of production line flows that are possible. Ranked roughly in order of speed are some possible production line flows shown below.
It is required to bring out the 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.
Programming Using a Gang Image[edit]
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 CC3200 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: CC31xx & 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 CC3200 will be held in reset during programming to prevent contention.
Programming over UART[edit]
Formatting and/or writing files to the serial flash device through the CC3200 UART interface requires the use of the following CC3200 pins:
- 55 - UART1 TX
- 57 - UART1 RX
- 32 - nRESET
- 21 - SOP2
The UART TX and RX pins are used for data transfer. RTS and CTS signals are not used. The nRESET pin is 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 CC3200 datasheet under Electrical Characteristics: http://www.ti.com/lit/ds/symlink/cc3200.pdf
Programming Using Uniflash[edit]
Using the Uniflash CLI[edit]
The Uniflash utility is PC software which can perform the following operations on the CC3200:
- Format the serial flash
- Add or remove files on the serial flash
- Update the service pack
These operations are accomplished by communicating with the CC3200 via UART. Therefore, it is necessary to supply Uniflash with a COM port number for the USB to CC3200 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 CC3200 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:
When Uniflash begins, it will prompt the user to restart the device. This is so it can synchronize with the CC3200 and begin the flashing process. At this point the CC3200 must be reset by pulling down the nRESET line. When the 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. The SOP2 pin must be pulled up during the reset. Refer to the Uniflash Wiki for complete information on how to use Uniflash.
UART Hardware Connection Using the FTDI emulation board[edit]
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 CC3200 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 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. Similarly the SOP2 pin must be able to be pulled up during the flashing procedure. The SOP2 pin must be pulled up during the device reset in order for the CC3200 to enter a mode for communicating with Uniflash.
Over the Air Programming[edit]
The CC3200 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 CC3200 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 CC3200 SDK folder at docs/CC3200 Simplelink OTA Extlib API User's Guide.chm.
Production Line RF Testing[edit]
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 CC3200 can be instructed to perform RF testing operations in a number of ways:
- The CC3200 program 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 script using the Radio Tool CLI could control the CC3200 from a PC. This would require the CC3200 to be connected to the PC through a UART to USB connection, and for a special Radio Tool program to be loaded as the MCU application
- The CC3200 could be controlled by interfacing with a dedicated RF tester.
Testing Software options[edit]
MCU Controlled RF Testing[edit]
SimpleLink API functions are available that can put the CC3200 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: docssimplelink_apiprogrammers_guide.html.
The Radio Tool library provides a set of convenience functions for RF testing:
- 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[edit]
Radio Tool CLI[edit]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 CC3200, the Radio Tool CLI communicates through the UART0 (pins 55 and 57) interface of the CC3200. In order for this to work, the Radio Tool MCU application needs to be loaded as the CC3200 MCU application. This application is available in the Radio Tool package. This tool requires use of the CC31XXEMUBOOST or a CC3200-LAUNCHXL for communication between the CC3200 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
Cc3200 Sdk For Mac High Sierra
Steam wargame red dragon.
Testing with an Access Point[edit]
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[edit]
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:
Golden board algorithm:
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.
Cc3200 Sdk For Mac Windows 10
Dedicated Wireless Test equipment[edit]
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.
The data is appended to the URL as a series of name/value pairs. After the URL web address has ended, we include a question mark (?) followed by the name/value pairs, each one separated by an ampersand (&).
Image below shows the response from the get.php webpage printer on 'Termite' serial terminal.
As you can see from above image the get.php responds with html tags and text inside the tags, as well as text echoed from the PHP code.POST method
A POST request passes parameters in the body of the HTTP request, leaving the URL untouched. I have uploaded the following file to my server - www.cnktechlabs.com/post.php:
post.php
The POST method implementation with CC3200 Code:
Server response:
Hi Mom
The next step is to collect and send some data to a webpage. I have created post.php and data.html webpages to collect and display data. The 'post.php' file shown below is responsible for reading data from the CC3200 board.
main.c:
HTTPPostMethod_data function, shown below, will send temperature, accelerometer, and location data to the post.php file.
Below is the result I can view on my data.html webpage.
Image of the serial print out on the Termite Terminal
Below is the result I can view on my data.html webpage.
A new hardware addition to the project - Light Sensor
Light Sensor senses ambient light and transmits messages to the web page. The data out, DO, pin of the sensor is connected to GPIO_03, PIN_58 on the development board.
Current Project Circuit Diagram
Project Source Code
Settings for the serial port: 115200, 8N1, no handshake.
Enter PASSWORD and SSID name in the 'common.h' file
Change location (strPtr = ' & loc=Los Angeles 0'; // Your location.) to your geographical location in the source code main file.
Flush the project into your CC3200 board, and view the results on the www.cnktechlabs.com/data.html. Connect CC3200 to a serial terminal on your PC.
Reset the board.
To enter password and SSID name either:
Press and hold SW2 and reset the board
On prompt 'Enter Password' enter WiFi password
On prompt 'SSID name' enter WiFi name.
Or just reset the board and the common.h credentials will be used.
NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.
- 5Programming Using Uniflash
- 7Production Line RF Testing
- 7.1Testing Software options
- 7.1.2PC Controlled RF Testing
- 7.4Dedicated Wireless Test equipment
- 7.1Testing Software options
Production Line Overview[edit]
Texas Instruments provides a number of resources to assist manufacturers using CC3200 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 CC3200 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 CC3200 QFN in the Production Line[edit]
Production with CC3200 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. The host program which runs on the internal Cortex M4 is stored on the serial flash also. 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 host program and the service pack can be continuously updated over the lifetime of the product. There are 3 basic methods of loading content onto the CC3200 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 CC3200 can use to create the desired contents of the serial flash.
- Over-the-Air Programming (OTA) - Serial flash content can be downloaded through a network connection.
All CC3200 QFNs must have their attached serial flash devices formatted with the SimpleLink file system before files can be written. There are a number of ways to accomplish this:
- Uniflash - Make a PC connection to the CC3200 UART, and use the Uniflash utility 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 CC3200 to format the serial flash upon the next boot of the device.
After the serial flash has been formatted there are a couple of options to load files onto the serial flash:
- Use Uniflash to load files via the CC3200 UART interface. The CC3200 reads the files sent over UART, and loads them onto the serial flash.
- If a gang image has been flashed, the CC3200 converts the files in the image and saves them into the file system. Therefore, an additional step for loading files is not necessary.
Sketch license key crack mac.
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. If the CC3200 is flashed with a program that can do OTA programming, the entire serial flash contents can be reprogrammed using OTA programming. This will enable the downloading of content from the internet or from a local connection. This may be advantageous if using a small OTA program to load the final contents onto the serial flash.
Given the available options for formatting and loading content to the serial flash there are a couple of production line flows that are possible. Ranked roughly in order of speed are some possible production line flows shown below.
It is required to bring out the 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.
Programming Using a Gang Image[edit]
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 CC3200 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: CC31xx & 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 CC3200 will be held in reset during programming to prevent contention.
Programming over UART[edit]
Formatting and/or writing files to the serial flash device through the CC3200 UART interface requires the use of the following CC3200 pins:
- 55 - UART1 TX
- 57 - UART1 RX
- 32 - nRESET
- 21 - SOP2
The UART TX and RX pins are used for data transfer. RTS and CTS signals are not used. The nRESET pin is 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 CC3200 datasheet under Electrical Characteristics: http://www.ti.com/lit/ds/symlink/cc3200.pdf
Programming Using Uniflash[edit]
Using the Uniflash CLI[edit]
The Uniflash utility is PC software which can perform the following operations on the CC3200:
- Format the serial flash
- Add or remove files on the serial flash
- Update the service pack
These operations are accomplished by communicating with the CC3200 via UART. Therefore, it is necessary to supply Uniflash with a COM port number for the USB to CC3200 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 CC3200 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:
When Uniflash begins, it will prompt the user to restart the device. This is so it can synchronize with the CC3200 and begin the flashing process. At this point the CC3200 must be reset by pulling down the nRESET line. When the 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. The SOP2 pin must be pulled up during the reset. Refer to the Uniflash Wiki for complete information on how to use Uniflash.
UART Hardware Connection Using the FTDI emulation board[edit]
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 CC3200 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 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. Similarly the SOP2 pin must be able to be pulled up during the flashing procedure. The SOP2 pin must be pulled up during the device reset in order for the CC3200 to enter a mode for communicating with Uniflash.
Over the Air Programming[edit]
The CC3200 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 CC3200 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 CC3200 SDK folder at docs/CC3200 Simplelink OTA Extlib API User's Guide.chm.
Production Line RF Testing[edit]
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 CC3200 can be instructed to perform RF testing operations in a number of ways:
- The CC3200 program 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 script using the Radio Tool CLI could control the CC3200 from a PC. This would require the CC3200 to be connected to the PC through a UART to USB connection, and for a special Radio Tool program to be loaded as the MCU application
- The CC3200 could be controlled by interfacing with a dedicated RF tester.
Testing Software options[edit]
MCU Controlled RF Testing[edit]
SimpleLink API functions are available that can put the CC3200 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: docssimplelink_apiprogrammers_guide.html.
The Radio Tool library provides a set of convenience functions for RF testing:
- 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[edit]
Radio Tool CLI[edit]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 CC3200, the Radio Tool CLI communicates through the UART0 (pins 55 and 57) interface of the CC3200. In order for this to work, the Radio Tool MCU application needs to be loaded as the CC3200 MCU application. This application is available in the Radio Tool package. This tool requires use of the CC31XXEMUBOOST or a CC3200-LAUNCHXL for communication between the CC3200 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
Cc3200 Sdk For Mac High Sierra
Steam wargame red dragon.
Testing with an Access Point[edit]
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[edit]
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:
Golden board algorithm:
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.
Cc3200 Sdk For Mac Windows 10
Dedicated Wireless Test equipment[edit]
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[edit]
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[edit]
{{#invoke: Navbox | navbox }}{{#invoke: Navbox | navbox }}
{{
Please post only comments related to the article CC3200 Production Line Guide here. | Keystone=
Please post only comments related to the article CC3200 Production Line Guide here. | C2000=For technical support on the C2000 please post your questions on The C2000 Forum. Please post only comments about the article CC3200 Production Line Guide here. | DaVinci=For technical support on DaVincoplease post your questions on The DaVinci Forum. Please post only comments about the article CC3200 Production Line Guide here. | MSP430=For technical support on MSP430 please post your questions on The MSP430 Forum. Please post only comments about the article CC3200 Production Line Guide here. | OMAP35x=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article CC3200 Production Line Guide here. | OMAPL1=For technical support on OMAP please post your questions on The OMAP Forum. Please post only comments about the article CC3200 Production Line Guide here. | MAVRK=For technical support on MAVRK please post your questions on The MAVRK Toolbox Forum. Please post only comments about the article CC3200 Production Line Guide here. | For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article CC3200 Production Line Guide here. }} |
| Links | |||
|
