AN-00139 ViSi Updating the CC3000 Firmware

Description This application note shows how to update the driver and firmware of the CC3000 WiFi chip. This application note comes with a project specially made to perform the update.
Supported Processor DIABLO16
Supported Environment

ViSi

Difficulty Difficult

 

File Downloads
Documentation
Files

Description

This application note shows how to update the driver and firmware of the CC3000 WiFi chip. This application note comes with a project specially made to perform the update.

** Updates must only be done if the user fully understands the process and only if deemed necessary. For more information on TI CC3000 please refer to the link below.

http://processors.wiki.ti.com/index.php/CC3000

 

Before getting started, the following are required:

Visit www.4dsystems.com.au/products to see the latest display module products that use the Diablo16 processor.

When downloading an application note, a list of recommended application notes is shown. It is assumed that the user has read or has a working knowledge of the topics presented in these recommended application notes.

 

Application Overview

Updates are provided for so many devices to pave the way for loading modification, enhancements, or patches to a device. This application note shows how to update the Texas Instrument CC3000 WiFi chip.

 

Setup Procedure

For instructions on how to launch Workshop 4, how to open a ViSi project, and how to change the target display, kindly refer to the section “Setup Procedure” of the application note

ViSi Getting Started - First Project for Picaso and Diablo16

 

Design of the Project

Layout of the Project

In this project couple of objects were used to provide a simple user interface form for the CC3000. The user interface have buttons that are used to check current firmware version and also to initiate the update.

 

The ViSi-based CC3000 Firmware Update Program

In this part of the application note statements that were written in 4DGL will be shown.  These statements are used to produce the functionality desired for this project application.

 

The sub-routines

The statements presented here are called upon in the main function later in this document. It is best to present the purpose of each sub-routine for us to be able to easily understand the main program statements.

 

startPage() sub-routine

To initially display the ViSi project objects is the purpose of this sub-routine. It also contains the statements that clear the attributes for the objects there enabling the object to be valid for touch feature of the display. In these set of statements the touch attributes of objects not included in the page is cleared so as to avoid conflict of detection with the objects included in this routine.

 

updatePage() sub-routine

This sub-routine is made to initially display the buttons for the updatePage form and also disable the touch related attributes of the other objects not belonging to this form.

 

 

disableTouch() sub-routine

This routine was written to simply manage the setting and clearing of touch related attributes. When working with touch feature on objects, it is always best to disable this feature on non-members of a form to avoid detection problems to occur.

 

drive() sub-routine

This sub-routine is dedicated to processing the driver.HEX file that is saved on the microSD. In the later parts of this application note, this HEX file will be descrbibed in detail.

 

The process starts with processing the information related to the internal EEPROM of the CC3000. This section of the program updates the File Allocation Table (FAT) of the EEPROM according to the data included in the following image.

 

The arrays above shows two sets of FAT arrays. These are parallel arrays that define the start location of a particular length of memory space. Also included in this segment of the project codes is the RM array. The RM array is a special set of data that are parameters to the CC3000 radio.

 

** The MAC address specified on this section must first be known to the user and be changed accordingly.

 

This section of the project reads the information saved on the driver.HEX file. The information is then transferred to the CC3000 according to the specified number of bytes.  The entire sub-routine will write the data chunks-by-chunks at a speed compatible to the CC3000.  Each time a segment of the driver is written to the CC3000 the numerical indication of successful writes is updated. At the end of writing the driver file, a notification is posted on the screen informing the user that is has ended. After the successful write of the driver, next will be the firmware update.

 

** THE CC3000 REQUIRES THAT THE DRIVER MUST FIRST BE LOADED BE SUCCESSFULLY LOADED BEFORE THE FIRMWARE UPDATE.

 

firmware() subroutine

This sub-routine contains a set of statements that execute the updating of the firmware for the CC3000.

 

The update statements starts with specifying the source of the HEX file. Seen in the set of statements above that the firmware data is contained on a file named – FWARE. It is important to name all the files same as the names specified on the project or to names that has at most 8 charactes for the filename and and extension of either TXT or HEX.

During the course of the update, a notification of successful writes is displayed on the screen. After the firmware update has finished the user will again receive a notification that the process completed successfully and shall return to the main start page of the project.

 

The DRIVER.HEX and FWARE.HEX files

The files specified in this application note was derived from the CC3000 Service Pack version 1.33. This update project will result to a firmware version that is identified as 1.24.

For further details on this information please refer to the link specified below.

http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads_1.12_and_1.13

 

Please note that the driver information and the firmware information must first be saved on two separate files – DRIVER.HEX and FWARE.HEX. Copy the supplied array from the service pack being used.  When a new service pack version is available the user will have to create the files manually and should follow the same format for the content of the files.

 

Share: