WICED Application Framework

Topics
	App management
	DCT
	Wiced Resource Management API's

Detailed Description

WICED functions for managing applications and non-volatile data. The WICED Application framework provides an interface for application configuration data, settings and operational modes.

Concept: WICED supports a fixed number of applications to be written on it. The word applications may be a bit confusing, it is binary files. Some of These files are applications that can be loaded, while other are files used for other purposes, these include file system image, wifi firmware, BT firm ware, etc. Following is a description of the very tiny file system that can handle these binaries and yet allow them to be updated.

Operations supported: Erase App: An app (or binary file in general) needs to be erased before it can be rewritten.

Write File: Once an app is erased it can be written, a new file can be uploaded to the location of the file. The new file doesn't need to be the same size, it can be bigger size (details on how to handle this will come later)

Close File: Once a file is written, it must be closed. This will update the entries in the app file system to use the new file.

Read File: An app can always be read.

Design: App header locations: The DCT contains a list of the application locations that WICED will support. At this point, it includes 8 blobs (Factory reset App, OTA upgrade app, APP0, resources file system, Wifi firmware, APP1, APP2, APP3). Each entry in the DCT points not the app location, but to the location of its description within a log block (this is 1 block assigned for logging the apps).

Log Block: The log block stores the apps locations. Apps are located with a granulaity of a block. each app location has the following data:

• Number of entry for the app
• Entries : Each entry is a start block and count, indicated a consequetive list of blocks with for the app. As long as the new file is covered by these entries, no update is needed for the app header. Once a new block is needed to be written A new header will be added at the ended of the log block and the DCT location for the app header will be updated. This is done in the close operation.

Erasing a file: Once an erase command is issued, the header address is obtained from the DCT, the header is read and all entries are erase.

Writing to a file: Before a file is written it has to be erased. As long as the writing offset and size is within the entries of the app, the writing is done with no change. Once the writing exceeds the already assigned sizes, the next empty block is going to be written wiht the new data. Writing will continue to the next blocks as required (the number of the first block and the count of blocks will be stored in ram for update)

Closing a file: When closing a file, if no new entries is added, then nothing to be done. If however a new entry was needed, then the program header is read and updated with a new entry and written as the end of the log block, DCT app locations is updated to point to the new app header location.

Reading of a file: When a file is read, the offset is mapped to the actual address in the flash: Physical address = entry physical adddress + (offset - entry file offset) Entry file offset = Count of previous blocks * size of block Entry physical address = Entry * size of block