Skip navigation
Home > All Places > WICED Studio Wi-Fi/Combo > WICED Studio Wi-Fi/Combo Forums > Blog > Authors PriyaM_16

This blog discusses debugging of the default iot_mqtt_demo(MACRO: CONFIG_MQTT_DEMO_ENABLED) application in aws_demo project in WICED Studio 6.4 using AFR. The process is very similar to debugging in WICED Studio 6.4(non AFR) with some modifications in the debug configurations.

 

Steps to debug are:

1.  Remove the run flag from the default make target given for aws_demo

demo.aws_demo-CYW954907AEVAL1F-FreeRTOS-LwIP HOST_OS=Win32 download

2. Build the application by double clicking the make target.

3. Currently RTOS thread resolve during debug is not supported for AFR in WICED Studio.  As a work-around, open <wiced_studio_path>\43xxx_Wi-Fi\tools\OpenOCD\BCM4390x.cfg in a file editor and go to the line that has:

 

$_TARGETNAME configure -rtos auto -rtos-wipe

Remove “-rtos auto” from that line and save the file.

 

4. Open Run> debug_configurations or click the drop down button next to debug on toolbar and choose debug_configurations

5. Under GDB hardware Debugging, right-click on "43xxx_Wi-Fi_Debug_Windows” and click “Duplicate”. Change the name in the top of the window to “AFR Debug” or any other name you prefer.

6. In the “Main tab”

     6.1 click Browse under Project and select “aws_demos” project.

     6.2 Next, under C/C++ Application click "Search Project", select "last_built.elf" and click OK. Make sure it points to the last_built.elf of amazon-freertos. The location  is <afr_installation_path>\amazon-freertos\vendors\cypress\WICED_SDK\build\eclipse_debug\last_built.elf

7. Go to debugger tab and make sure the GDB command is pointing to the tools directory of your WICED SDK.

8. Apply the changes in debug configurations and click on debug. If you have connected the board and everything goes well, the debugger will start up and will pause execution in the start_GCC.S file.

9. You can open main.c and put a breakpoint at the line int main(void ) by double clicking on the left of the line or by right-clicking and selecting Toggle Breakpoint. (A check in front of the breakpoint shows that its an active breakpoint)

 

Click on the resume button to resume the execution of code and stopping on the next breakpoint. You can also use step in/over commands to step through your application.

Please note that if you wait indefinitely on a breakpoint inside a thread with a network connection it has a larger chance of getting disconnected. So, stopping execution while there is an active connection should be used sparingly.

 

Note that we have not modified the make target with the “-debug” flag that we usually use with other WICED Studio projects. The downside of not using -debug is that some variables may be optimized away.

This blog post discusses the procedure to create a new application in Amazon FreeRTOS(AFR).

The SHA1 for repository cloned for this blog post is dae010944f32b403acff8a5a888222da11b8b5a4.

Please follow the steps mentioned in Getting Started with the Cypress CYW943907AEVAL1F Development Kit - Amazon FreeRTOS to setup AFR for CYW943907EVAL1F or CYW54907AEVAL1F

We will be using the APIs provided in AFR for writing SCAN application in this blog.

 

Please follow the steps mentioned below for adding scan application in AFR:

1. We will be forking the AFR repository and will make changes in the forked repository. Visit the FreeRTOS github repository and fork the repo.

Download the repository:

git clone https://github.com/<user_name>/amazon-freertos.git

 

2. To get your repository structure as per the repository used for this blog, checkout the mentioned SHA1:

git checkout dae010944f32b403acff8a5a888222da11b8b5a4

The same steps might be valid for a newer version of AFR with minor changes.

3. You will see an aws_demos project in WICED when you import the aws_demos project.

Let us add the new application in demos directory of aws_demos. Go to the exact path of demos directory in your cloned repo: I have it in C:\afr\amazon-freertos\demos

Create a new folder named scan.

4. Place the attached files(cy_scan.h and cy_scan.c) in the scan folder.

5. The scan folder is kept at the absolute path but is not linked in the aws_demos project in WICED hence it will not appear in the demos directory in aws_demos project in WICED.

To establish a link,  open .project file of the project in text editor and add the link in <linkedResources> as follows:

        <link>

            <name>demos/scan/cy_scan.c</name>

            <type>1</type>

            <locationURI>BASE_DIR/demos/scan/cy_scan.c</locationURI>

        </link>

        <link>

            <name>demos/scan/cy_scan.h</name>

            <type>1</type>

            <locationURI>BASE_DIR/demos/scan/cy_scan.h</locationURI>

        </link>

6. Open the iot_demo_runner.h file and add the following two lines along with the other MACROS defined:

 

#elif defined (CONFIG_CY_SCAN_DEMO_ENABLED)

    #define DEMO_entryFUNCTION                              vStartScanDemo

 

The vStartScanDemo is written in cy_scan.c file.

7. Open the aws_demo_config.h file and enable the defined MACRO instead of CONFIG_MQTT_DEMO_ENABLED

#define CONFIG_CY_SCAN_DEMO_ENABLED

 

8. Open the application makefile(aws_demos/vendors/cypress/WICED_SDK/apps/demo/aws_demo/aws_demo.mk) and add the file names as follows:

Add the cy_scan.c file in $(NAME)_RESOURCES

     $(AMAZON_FREERTOS_PATH)demos/scan/cy_scan.c \

Add the cy_scan.h file in GLOBAL_INCLUDES

    $(AMAZON_FREERTOS_PATH)demos/scan \

 

9. Build the target by clicking on the provided make target

demo.aws_demo-CYW943907AEVAL1F-FreeRTOS-LwIP HOST_OS=Win32 download run

 

10. Open serial terminal and check the UART logs for scan result:

This blog discusses the different binaries that are downloaded in CYW943907AEVAL1F EVK when the board is programmed using WICED SDK. This blog also addresses the procedure of creating a single binary suitable for manufacturing. Please note that the manufacturing image procedure is explained for ota2 compatible image. The same method can be followed to create a similar image for generic case(non OTA2).

 

WICED FRAMEWORK:

The different binaries needed for programming a CYW943907AEVAL1F EVK are

1. Bootloader

2. DCT

3. APPS LUT

4. FILESYSTEM

5. APPLICATION(There can be multiple applications APP0, APP1, APP2)

 

During a normal build process, the files which are downloaded can be viewed by including VERBOSE=1 in the make target. The downloaded files from the build log are shown below:

1. DCT

Downloading DCT ... build/<snip_name>-CYW943907AEVAL1F/DCT.bin @ SFLASH_DCT_LOC=0x00008000

2. The Bootloader file is:

build/waf.bootloader-NoOS-NoNS-CYW943907AEVAL1F-P103-SoC.43909/binary/waf.bootloader-NoOS-NoNS-CYW943907AEVAL1F-P103-SoC.43909.trx.bin

3. Filesystem is created with

./tools/common/Win32/mk_wicedfs32 build/<snip_name>-CYW943907AEVAL1F/filesystem.bin build/<snip_name>-CYW943907AEVAL1F/resources/Staging/

and downloaded

Downloading resources filesystem ... build/<snip_name>-CYW943907AEVAL1F/filesystem.bin at sector 17  size <filesystem_size>...

4. Downloading Application

Downloading APP0 build/<snip_name>-CYW943907AEVAL1F/binary/<snip_name>-CYW943907AEVAL1F.stripped.elf @ sector <filesystem_start_address + filesystem_size> address xxx size <filesystem_size>...

5. APPS LUT

Downloading apps lookup table in wiced_apps.mk ... build/<snip_name>-CYW943907AEVAL1F/APPS.bin @ 0x00010000 size

 

How are the addresses determined for programming the binaries/files?

>> The memory map is defined in <WICED- SDK>\43xxx_Wi-Fi\platforms\CYW943907AEVAL1F\normal_image_defines.mk

The starting address of filesytem is given as:

In /43xxx_Wi-Fi/platforms/CYW943907AEVAL1F/normal_image_defines.mk,

NORMAL_IMAGE_APPS_AREA_BASE := 0x00011000 i.e, 69632 d

 

In /43xxx_Wi-Fi/WICED/platform/MCU/BCM4390x/BCM94390x_common.mk

APPS_START_SECTOR := $(shell $(PERL) $(SECTOR_NUMBER_SCRIPT) $(NORMAL_IMAGE_APPS_AREA_BASE) $(SECTOR_SIZE))

 

Hence APPS_START_SECTOR=69632/4096 = 17

 

The starting address of application stripped.elf is obtained by adding the filesystem size to APPS_START_SECTOR.

Kindly check the BUILD_APPS_RULES in 43xxx_Wi-Fi/tools/makefiles/wiced_apps.mk for understanding the computation of starting sectors.

 

MANUFACTURING IMAGE:

The manufacturing image is a single image suitable for download during manufacturing.

WICED has implemmenttaion for creating manufacturing image suitable for OTA2. It follows the memory map defined in 43xxx_Wi-Fi\platforms\CYW943907AEVAL1F\ota2_image_defines.mk

The image is created using "ota2_manuf_image" in the make target.

 

How is the manufacturing image created and which files are included in it?

>> Please look for ota2_manuf_image target in 43xxx_Wi-Fi\tools\makefiles\wiced_apps.mk

First a manufacturing config file is created.

$(QUIET)$(call WRITE_FILE_CREATE, $(OTA2_IMAGE_MANUFACTURING_CONFIG_FILE) ,$(OTA2_IMAGE_BOOTLOADER_START) build/$(BOOTLOADER_TARGET)/binary/$(BOOTLOADER_TARGET).trx.bin)

The config file is than appended with information of other required binaries. One such example is:

$(QUIET)$(call WRITE_FILE_APPEND, $(OTA2_IMAGE_MANUFACTURING_CONFIG_FILE) ,$(OTA2_IMAGE_FACTORY_RESET_AREA_BASE) $(OTA2_IMAGE_FACTORY_RESET_BIN_FILE))

The config file is then passed to a tool which creates the image. The image is filled with 0xFF for unused parts of the FLASH

$(shell $(PERL) $(CREATE_FLASH_IMAGE_TOOL) $(call CONV_SLASHES,$(OTA2_IMAGE_MANUFACTURING_CONFIG_FILE)) $(call CONV_SLASHES,$(OTA2_IMAGE_MANUFACTURING_BIN_FILE)))

 

The  $(CREATE_FLASH_IMAGE_TOOL) is located @43xxx_Wi-Fi\tools\common\<OS>\mk_wiced_ota2_image32.exe

PriyaM_16

TCP stream API

Posted by PriyaM_16 Moderator Jul 29, 2018

WICED provides multiple APIs to implement a TCP connection. This blog discusses the TCP stream_read/write APIs which are more convenient for receiving/sending a large chunk of data.

The usual flow of sending TCP packets is: packet creation-> write data into packet-> set the end of the data portion-> send the packet -> delete the packet.

This method of sending TCP packets turns out to be cumbersome for large chunk of data as one has to go back and forth between packet creation and deletion. The TCP stream APIs provide a better way to stream successive data without worrying about the packet boundaries. The TCP stream APIs takes care of creating the packet and sending it unless the entire buffer is sent. The following diagram gives a simple overview of differences between existing APIs and stream APIs:

 

Please refer the wiced_tcpip.h file in 43xxx_Wi-Fi\include dir for description of the provided TCP APIs. Some of the stream APIs are listed below:

wiced_result_t wiced_tcp_stream_init( wiced_tcp_stream_t* tcp_stream, wiced_tcp_socket_t* socket );

wiced_result_t wiced_tcp_stream_write( wiced_tcp_stream_t* tcp_stream, const void* data, uint32_t data_length );

wiced_result_t wiced_tcp_stream_write_resource( wiced_tcp_stream_t* tcp_stream, const resource_hnd_t* res_id );

wiced_result_t wiced_tcp_stream_read( wiced_tcp_stream_t* tcp_stream, void* buffer, uint16_t buffer_length, uint32_t timeout );

wiced_result_t wiced_tcp_stream_read_with_count( wiced_tcp_stream_t* tcp_stream, void* buffer, uint16_t buffer_length, uint32_t timeout, uint32_t* read_count );

wiced_result_t wiced_tcp_stream_flush( wiced_tcp_stream_t* tcp_stream );

 

Please find attached the tcp_client application modified to use the wiced_tcp_stream_write() API.

This blog dicusses the download procedure on CYW43907 using external JTAG device - Jlink Segger in WICED SDK 6.2 and future releases.  Blog Downloading and debugging CYW43907 using Jlink Segger is valid only for SDKs prior to WICED SDK 6.2.

 

The hardware connections to connect CYW943907AEVAL1F's JTAG with j-link are tabulated below:

 

CYW943907AEVAL1F

Segger jlink

Signal

Pin

Signal

Pin

3v3

J9_04

VTref

1

GPIO_6_JTAG_TRST_N

J3_01

nTRST

3

Ground

J3_04

GND

4

GPIO_4_JTAG_TDI

J3_03

TDI

5

GPIO_3_JTAG_TMS

J3_07

TMS

7

GPIO_2_JTAG_TCK

J3_09

TCK

9

GPIO_5_JTAG_TDO

J3_05

TDO

13

RESET_N

J9_03

RESET

15

The switches in SW4 on CYW943907AEVAL1F need to be closed to use an external JTAG. (By default the switches are open)

 

 

To Download the application, we need J-Link tool: Please download J-Link tool from SEGGER website and install it. As CYW4390x was not a part of the supported devices list of SEGGER J-LInk, we need to make use of flashloader tool from SEGGER to drive the sflash of CYW4390x. Please copy flashloader_CYW4390x_QSPI.elf as attached here to the Devices/Cypress/ folder in Segger Installation directory (should look something like this: C:\Program Files (x86)\SEGGER\JLink_V640\Devices\Cypress). Modify JLInkDevices.xml in the same directory for adding CYW4390x in support list.

<<JLinkDevices.xml>>

    ********************************************************************

      <Device>

        <ChipInfo Vendor="Cypress" Name="CYW43907" Core="JLINK_CORE_CORTEX_R4" WorkRAMAddr="0x004A0000" WorkRAMSize="0x00100000" JLinkScriptFile="Devices/Broadcom/BCM43907.JLinkScript" />

        <FlashBankInfo Name="QSPI Flash" BaseAddr="0x14000000" MaxSize="0x08000000" Loader="Devices/Cypress/flashloader_CYW4390x_QSPI.elf" LoaderType="FLASH_ALGO_TYPE_OPEN" />

      </Device>

    ********************************************************************

 

 

For programming the image via J-Link connector, the JLink path need to be declared in WICED build string. Add the path of JLink.exe from the downloaded J-Link tool.

 

Example: For downloading test.console application, make the target as follows

test.console-CYW943907AEVAL1F JTAG=jlink-native  JLINK_PATH="C:/Program\ Files\ \(x86\)/SEGGER/JLink_V630c/" JLINK_EXE="JLink.exe" download run

 

To debug through J-Link, you need to create your own J-Link debug configuration in WICED Studio, details about which can be found out in the attached document.

This blog discusses how to download and debug an application on CYW43907 using external JTAG device - Jlink Segger.

NOTE: This blog is valid for WICED releases prior to WICED SDK 6.2

The hardware connections to connect CYW943907AEVAL1F's JTAG with j-link are tabulated below:

 

CYW943907AEVAL1F

Segger jlink

Signal

Pin

Signal

Pin

3v3

J9_04

VTref

1

GPIO_6_JTAG_TRST_N

J3_01

nTRST

3

Ground

J3_04

GND

4

GPIO_4_JTAG_TDI

J3_03

TDI

5

GPIO_3_JTAG_TMS

J3_07

TMS

7

GPIO_2_JTAG_TCK

J3_09

TCK

9

GPIO_5_JTAG_TDO

J3_05

TDO

13

RESET_N

J9_03

RESET

15

The switches in SW4 on CYW943907AEVAL1F need to be closed to use an external JTAG. (By default the switches are open)

 

Connect the Jlink segger to host PC. To download an application using j-link Segger, you need to change the jlink driver to libusbK.

Use Zadig to change the jlink driver.

 

Check the device manager of host PC to verify that J-link segger appears under libusbK USB devices.

 

Modify the configuration file( tools/OpenOCD/BCM4390x.cfg) to include the mode flags as follows:

replace reset_config srst_nogate connect_assert_srst with

reset_config trst_and_srst srst_push_pull srst_nogate connect_assert_srst

 

To build scan application using external JTAG, the make target should contain "JTAG=jlink" in the build string.

Make the target as: snip.scan-CYW943907AEVAL1F-debug JTAG=jlink download run

 

Please note that the download is using openOCD in WICED SDK.

To debug an application, you need to revert back the driver for jlink from libusbK to Segger. Right click on jlink under libusbK and update driver. Choose "Search automatically for updated driver software". This will install the jlink driver. Jlink will appear as J-link driver under Universal Serial Bus Controllers.

Install JLink on your machine. Follow the instructions:

@SEGGER - The Embedded Experts - Downloads

 

Disable the Watchdog by adding the following flag in the make file of your application:
GLOBAL_DEFINES += WICED_DISABLE_WATCHDOG

 

Follow the instructions given in the attached document for setting the debug configurations in WICED SDK.

This blog discusses how to configure CYW943907AEVAL1F as a USB host and connect a USB device to it. In this blog, we are connecting a HID mouse to CYW943907AEVAL1F. The attached snip application will initialize USB host class driver to get USB mouse position and mouse key input by the user and print the XY-axis position and button pressed on WICED console.

 

To test USB host functionality, download the usb_host_hid_mouse snip attached to this blog post. Extract and add the downloaded folder in apps folder of WICED Studio 6.0 or later.

 

To evaluate USB operation on CYW943907AEVAL1F board, some hardware modifications are needed. Refer to blog post Hardware connections for USB evaluation on CYW943907AEVAL1F for the required changes. You won't be able to program the board with micro USB provided after the hardware modifications are done. You can use Olimex ARM-USB-TINY-H debugger or J-Link Segger to program the CYW943907AEVAL1F EVK.

 

Make the hardware connections to connect Olimex ARM-USB-TINY-H debugger with CYW943907AEVAL1F board as discussed in post OpenOCD -WICED.

To program your device using JTAG, install the drivers using zadig. Connect Olimex debugger and CYW943907AEVAL1F board to your PC/laptop. You can see JTAG device detected in Device Manager as follows.

For downloading the application, make the target as follows:

usb_host_hid_mouse-CYW943907AEVAL1F JTAG=Olimex_ARM-USB-TINY-H download run

 

Connect a mouse to the host through a Micro USB-B to Female type-A connector.

The WICED console should show the initialization as follows:

Connect the mouse to the port. The console should show connection details and device enumerations.

Type hid_mouse to start the test. You should be able to see the XY-axis coordinates and button state on the console:

 

The APIs available to configure CYW943907AEVAL1F as USB host are:

1. wiced_result_t wiced_usb_host_init( wiced_usb_user_config_t *config )

This function calls the following USBX driver APIs to initialize USB host:

  • ux_host_stack_initialize(UINT (*system_change_function) (ULONG, UX_HOST_CLASS *)) to initialize the USB host stack.
  • ux_host_stack_class_register(CHAR_PTR class_name, UINT (*class_entry_address) (struct UX_HOST_CLASS_COMMAND_STRUCT *)) to register a USB class to the USB stack. This API is used to register all the host class drivers for USBX implementation. For eg. HUB class, Storage class, HID class, audio class, CDC-ACM class, etc.
  • ux_host_stack_hcd_register(CHAR_PTR hcd_name, UINT (*hcd_function)(struct UX_HCD_STRUCT *), ULONG hcd_param1, ULONG hcd_param2) to register a USB controller to the USB stack. It mainly allocates the memory used by this controller and passes the initialization command to the controller. This API is used to register all the USB20 Host controllers available in the system i.e., OHCI, EHCI

2. static wiced_result_t usb_host_app_event_handler( uint32_t event, void *param1, void *param2 )

This function is an event handler which is called on the occurrence of events like insertion or removal of USB device.

There is an event callback function(wiced_usb_host_usbx_host_evt_callback) in ux_host_stack_initialize. Upon occurrence of an event, wiced_usb_host_usbx_host_evt_callback is called which in turn calls usb_host_app_event_handler to notify the user about specific event.

An Over-The-Air (OTA) update is wireless delivery of new software or data, configuration settings to device. In WICED, there are two snips to demonstrate OTA updates: apps/snip/ota_fr and apps/snip/ota2_example.

The update mechanism of OTA supports starting a SoftAP and perform a manual upload of a new application to replace the current application.

OTA2 has more functionalities compared to OTA.

Please refer to WICED-OTA2.pdf available in 43xxx_Wi-Fi\doc folder of WICED SDK Installation directory for more information about OTA2.

 

The major differences between OTA and OTA2 are tabulated below:

Feature

OTA

OTA2

Update Bootloader

No

No

Update main application

Yes

Yes

Update check can be timed periodically

No

Yes

Update components checked with CRC

No

Yes, upon download and at extraction.

Update All parts of system

No

Yes, excluding bootloader

Keep User DCT Settings

Yes
(DCT untouched)

Yes

DCT saved to separate area. Application must explicitly update the DCT data

 

OTA: Please follow the link for testing ota_fr snip: WICED OTA Upgrade and Factory Reset (SDK 3.1.2 through WICED Studio 4.x)

OTA2: Please follow the link for testing ota2_example snip: OTA2 Update for SDK-3.7.0

Further implementation details of OTA2 are mentioned here:

OTA2 implementation requires nearly 8 MB memory. The memory requirements are shown in the table. In WICED, the memory map for CYW943907AEVAL1F is defined in: 43xxx_Wi-Fi\platforms\CYW943907AEVAL1F\ota2_image_defines.mk.

Size
Description
16KBootloader(Bootloader size can be <32K but for secure boot it should be <16K)
128KOTA2 Failsafe Application(snip/ota2_failsafe)
1MB+

OTA2 Image- Factory Restore Area

(includes reset DCT+LUT*+filesystem+OTA2 Extractor**+Application size)

16KOTA2 DCT Save area (used to keep the DCT data after an upgrade so that DCT data can be recovered)
32KDCT copies(DCT1 and DCT2)
4KApplication Look up Table(LUT*)
512KFilesystem(includes WiFi Firmware)
256KOTA2 Extractor**(can start using SoftAP,DHCP server and Web Server)
256KMedium sized Application(WiFi)
1MB+

OTA2 Image- Staging Area

(includes new DCT+LUT* filesystem+OTA2 Extractor**+Application size)

3MB+

TOTAL + Application Size

*LUT: Look Up Table- in the WICED Multi-Application Framework, this is a directory where the system(App, DCT, Resources) is located in FLASH.

**OTA2 Extractor is an application which extracts the application images and loads in the current application area.

 

The highlighted area in the table shows the images that OTA2 works with. There are 3 images:

  1. Current application image: This is the current application running in your device.
  2. OTA2_image- Staging Area: This is the image to be updated and it is stored in the staging area in memory. There is support for background downloading of OTA2 Update image from file server or manually providing the image through web server.
  3. OTA2_image- Factory reset image: If the device enters an unknown state during update (due to power loss or connection loss or error in extraction of ota2_image), this image is extracted and is loaded in the current application area. On a power loss error, the ota2_extractor first tries to extract the last thing that was being extracted. So if the image in the staging area was being extracted and the power failed, the system will first try to use the staging area before resorting to the Factory Reset Area.

Different type of images that can be generated in WICED are:

  1. ota2_image: OTA2 Image suitable for upgrade server
  2. ota2_download: OTA2 Image suitable for upgrade server + download to SFLASH OTA2 Staging Area at end of build
  3. ota2_factory_image: OTA2 Factory Reset Image
  4. ota2_factory_download: OTA2 Factory Reset Image + download to FLASH OTA2 Factory Reset Area at end of build
  5. ota2_manuf_download: Creates and downloads manufacturing image

 

For creating an OTA2 update image, the application should be build as follows: <folder>.<app_name>-<platform_name> ota2_image

This creates a binary file OTA2_image_file.bin which is located at ../build/snip.<app_name>-<platform_name>/OTA2_image_file.bin(This is the file which is provided for update through Webserver or through client's designated update server).

 

The functioning of OTA2 requires three applications:

  • OTA2 Bootloader
  • OTA2 Failsafe
  • OTA2 Extract

These applications are already built and downloaded when the Ota2_example snip is executed. Few details about these applications are mentioned here:

OTA2 Bootloader: On boot, ota2_bootloader checks the OTA2 Staging Area downloaded Image status and the OTA2 Factory Reset Image status and the Factory Reset Button.

If download status says Extract on Reboot                                              ---->>>     start ota2_extract to start extraction from the Staging Area

else if button(USER_1) hold ~5 seconds                                                 ---->>>    start ota2_extract to start the SoftAP, DHCP server and web server for manual update

else if button hold ~10 seconds or force_factory_reset is set in the DCT --->>>     start ota2_extract to extract the Factory Reset Image

else                                                                                                            --->>>     start current application

 

If power loss occurs during extraction, the ota2 bootloader checks the boot_type from DCT and decides on the image to be extracted. It extracts the apps LUT and ota2_extractor from the staging area or the factory restore area to restore enough of the system to do a full extraction.

 

OTA2 Failsafe: waf/ota2_failsafe

This application is loaded from the bootloader when needed to provide extraction of the Application LUT and snip/ota2_extract to allow for full extraction on reboot. The OTA2 Failsafe Application can restore a system to the valid OTA2 image in the Staging Area or the OTA2 Factory Reset Image if the system fails to boot(device was reset during OTA2 extraction). It is required for all builds, and is automatically built and downloaded with the ota2_bootloader.

 

OTA2 Extract: snip/ota2_extract

This application does all the extraction functionality for a normal extraction. It can also run the SoftAP, DHCP, and Web Server when instructed to do so by the ota2_bootloader. You need to build the ota2_extract application before building your full application. It is automatically downloaded when the ota2_example application is build as the make file of ota2_example points to the binary of ota2_extract. Following directives should be added in the make file of application for OTA2 support

#OTA SoftAp application
OTA_APPLICATION := snip.ota2_extract-$(PLATFORM)
OTA_APP := build/$(OTA_APPLICATION)/binary/$(OTA_APPLICATION).stripped.elf

 

As already discussed in the Bootloader section, the ota2_extract application is extracted from the OTA2 staging area/OTA2 factory restore area hence it should be a part of the update image. To include ota2_extract in the image, the OTA_APP directive should be added to the make file of the application as mentioned above.

Filter Blog

By date:
By tag: