OTA updates


#1

Hello,

When I compile a program for redbear duo, I get the notice that OTA update is disabled? Can we do OTA updates for redbear duo with WICED?

thanks
rifo


#2

We haven’t investigated this yet, but the Duo is suppose to support this feature. Please refer to the docs under “WICED-SDK-3.7.0/doc”.


#3

Thanks GuoHui,

I’ll check that out and report back


#4

Hello @guohui

I have tried compiling the OTA2_example under snip. I have added below snippet to makefile

VALID_PLATFORMS += RB_DUO
RB_DUO_ext

and then issued

.\make snip.ota2_example-RB_DUO

I think we need to generate another mk file
under platforms/RB_DUO
I get the below error.

tools/makefiles/wiced_config.mk:182: platforms/RB_DUO/ota2_image_defines.mk: No such file or directory
tools/makefiles/wiced_config.mk:268: platforms/RB_DUO/ota2_image_defines.mk: No such file or directory

I searched this file and found one under

./platforms/BCM943907WAE_1/B0/ota2_image_defines.mk

The contents of the file is given below

#
# Broadcom Proprietary and Confidential. Copyright 2016 Broadcom
# All Rights Reserved.
#
# This is UNPUBLISHED PROPRIETARY SOURCE CODE of Broadcom Corporation;
# the contents of this file may not be disclosed to third parties, copied
# or duplicated in any form, in whole or in part, without the prior
# written permission of Broadcom Corporation.
#
#
#
#  Layout for FLASH
#
#  Offset 0x000000
#   +---------------------------------------+
#   | Boot loader Area						|
#   +---------------------------------------+
#   | Factory Reset OTA Image				|
#   +---------------------------------------+
#   | DCT Save area (when updating)			|
#   +---------------------------------------+
#   | Current Area							|
#   +---------------------------------------+
#   | Last Known Good (if enabled )			|
#   +---------------------------------------+
#   | OTA Staging area (downloaded image)	|
#   +---------------------------------------+
#
#  LAST KNOWN GOOD Not supported yet
#
# total of all sizes must == FLASH size

OTA2_IMAGE_FLASH_BASE                := 0x00000000

# Bootloader is 32k
# Factory Reset OTA Image is 2MB
OTA2_IMAGE_FACTORY_RESET_AREA_BASE   := 0x00008000

# DCT copy is 16K in size
OTA2_IMAGE_APP_DCT_SAVE_AREA_BASE    := 0x00208000

# Current Area 2.5MB
# LUT - 4k
# DCT - 8k
# Filesystem - 450k
OTA2_IMAGE_CURRENT_AREA_BASE         := 0x0020c000
OTA2_IMAGE_CURR_LUT_AREA_BASE        := 0x0020c000
OTA2_IMAGE_CURR_DCT_1_AREA_BASE      := 0x0020d000
OTA2_IMAGE_CURR_FS_AREA_BASE         := 0x00216000
OTA2_IMAGE_CURR_APP0_AREA_BASE       := 0x00300000
OTA2_IMAGE_CURR_OTA_APP_AREA_BASE    := 0x00380000

# Last Known Good not suppoorted yet
# ( size is ~2.5 Mb)
# OTA2_IMAGE_LAST_KNOWN_GOOD_AREA_BASE := 0x00000000

# Staging OTA Image is 2.5MB
OTA2_IMAGE_STAGING_AREA_BASE         := 0x00600000
OTA2_IMAGE_STAGING_AREA_SIZE         := 0x00200000	# 2MB (currently 850KB)

# TOTAL                                0x00800000	# 8 MB
# total of all sizes must <= FLASH size
#

Can you please guide me for preparing this file for redbear duo too? I think OTA updates are very important and we would greatly benefit from having this feature.

thanks
rifo


#5

Hi @riforifo, The ‘ota2_example’ seams like it needs lots of flash space, while it is not enough on the Duo. I would suggest you try the ‘ota_fr’ example. I used to make it work on the Duo.

Cheers!


#6

Hello @guohui

I checked the OTA examples. Namely tftp and ota_fr

For tftp example, I faced the following problem, when I use the tftp client on my PC to put a stripped.elf image, I got an “Error Writing” error in function wiced_framework_app_write_chunk.

wiced_result_t snip_tftp_write( tftp_t* tftp, uint8_t* data, void* p_user )
{
printf( “Writing size %d from offset %lu [0x%x] \r\n”, tftp->block_size, offset, data[ 0 ] );

if ( wiced_framework_app_write_chunk( &app, data, tftp->block_size ) != WICED_SUCCESS )
{
    printf( "Error Writing\n" );
}
offset += tftp->block_size;
return WICED_SUCCESS;

}

Therefore I wasn’t able to finish the example.

After this, I tried the “ota_fr” example. I connected to the duo working as an access point and opened the browser and selected the scan.stripped.elf image produced by ".\make snip.scan.RB_DUO

Error setting application size!!
Error setting application size!!
Writing chunk 2 of size 1024 from offset 1024
Writing chunk 3 of size 1024 from offset 2048
Writing chunk 4 of size 1024 from offset 3072
Writing chunk 5 of size 1024 from offset 4096
Writing chunk 6 of size 1024 from offset 5120
Writing chunk 7 of size 1024 from offset 6144
Writing chunk 8 of size 1024 from offset 7168



Writing chunk 450 of size 1024 from offset 459776
Writing chunk 451 of size 608 from offset 460800
Uploaded file size = 461408
Restarting…

After this, the scan application didn’t start. It was again the ota-fr application.

So I thought that I should maybe add the stripped.elf image with RB_DUO_ext version but it didn’t work too. It got stuck while writing chunk 1.

Writing chunk 1 of size 1024 from offset 0

I am at a loss now :confused:
can you please help me about this problem

thanks
rifo


#7

After the ota_fr example downloading the scan snip, it won’t automatically start. You need to reset the Duo manually. This issue bothers me for a long time.


#8

hello @guohui

I think I messed up somewhere because when I click the “start upgrade” button. Redbear Duo gets stuck like below. For the upgrade program, I choose scan-RB_DUO.stripped.elf

Hi, I’m the Production App (ota_fr).
Watch while I toggle some LEDs …
Time for an upgrade. OTA upgrade starting …
IPv4 network ready IP: 192.168.10.1
Setting IPv6 link-local address
IPv6 network ready IP: FE80:0000:0000:0000:96A1:A2FF:FEFD:7355

Writing chunk 1 of size 1024 from offset 0

nothing happens, and then the device resets itself after a while. It’s again the same program. I manually press reset but nothing changes.

Is there a way to get back to factory default settings for me. Maybe I messed up somewhere critical in the memory?

thank you
rifo


#9

one more thing,

This happened after I tried upgrading to the program scan.stripped.elf compiled with RB_DUO_EXT
Does this have something to do with that?

what’s the difference between RB_DUO and RB_DUO_EXT?


#10

Hello,

I have deleted the scan and ota_fr examples and rebuilt them with RB_DUO again. I have then opened up a brand new redbear duo and uploaded the ota_fr.

I get the same error. I am again at a loss :confused:


#11

Hi @riforifo,

I used the ota_fr to upload scan example successfully.

  1. I am using WICED-SDK-3.7.0
  2. Make ota_fr example: snip.ota_fr-RB_DUO download run JTAG=RBLINK
  3. Make scan example: snip.scan-RB_DUO
  4. Connect PC to the AP which is broadcaste by the Duo
  5. Select the snip.scan-RB_DUO.stripped.elf to upload
  6. After upload completed, the Duo restarted automatically and print the scanned APs:

The difference between the RB_DUO and RB_DUO_ext is:

  • The RB_DUO places the WiFi firmware in the internal flash when downloading firmware
  • The RB_DUO_ext places the WiFi firmware, which is integrated in the file system image (build\snip.scan-RB_DUO_ext\resources\filesystem.bin), to the external SPI flash. To download this file system image, you MUST add option download_apps in the make command. E.g. make snip.scan-RB_DUO_ext download download_apps run JTAG=RBLINK. Otherwise, it just download application to internal flash, which will definitely result a failed starting

#12

Hello @guohui

thanks for your help. I am using Wiced SDK 3.7.0-3 I am also using DFU mode to download the images.
I didn’t use the option download_apps in the make command for DUO_ext, (I used this only 1 time and used DUO again) Do you think I messed up my redbear duo?

I will now try the example with RBlink. Can you also please upload the ota_fr and snip.stripped.elf binaries that you are using? I think this will help me find where I am making a mistake.

thank you
rifo


#13

If you are developing WICED applications, nothing you can mess up, since everything can be restored with RBLink. But if you are using the DFU to upload WICED applications, the bootloader must not be destroyed. Also note that if you are going to use RBLink to upload WICED application via make command snip.scan-RB_DUO download run JTAG=RBLINK, the bootloader will be overridden by the WICED bootloader, then you will not be able to upload applications via DFU.

You can download the files I built here.


#14

Hello @guohui

I tried the binary files that you’ve attached but got the same error (can’t upload the firmware, gets stuck). I guess with DFU, OTA_fr example doesn’t work. One thing I also noticed is that, the SSID name is listed as DUO-AGJU and not WICED_DEVICE. This may have something to do with the error.

With RB Link, it was OKEY to load the new stripped elf firmware via webpage but the new program doesn’t start and the Redbear simply does nothing. I tried uploading stripped elf scan from your github account and also compiled other images

I did a manual reset too but it didn’t help. Is there some extra setting that I should do?
thank you
rifo

edit: can you also upload the snip.ota_fr-RB_DUO.bin_MSD.bin file too?


#15

It is because that the DCT is not updated.

I have just uploaded the MSD bin file under my Github account. Please have it a try.

The reason I assume why it didn’t restart is that the bootloader jumped to the beginning address where the Particle firmware locates. Updating with the MSD file I provided will make it run WICED application. More details about the bootloader where it jumps to.

Cheers!


#16

Hello @guohui

Thank you very much for your help again. OTA is almost working now :slight_smile:

I unlocked my duo with rblink_unlock.bin and then followed below steps.

  1. Upload ota_fr-RB_DUO-bin_MSD.bin file from your repository

  2. Select snip.scan.stripped.elf file from your repository
    -> wifi transfer finishes and device reboots
    -> ota_fr firmware works again instead of SCAN application

  3. Select snip.scan.stripped.elf file and upload again (**SECOND TIME) **via Ota_server web page
    -> wifi transfer finished and device reboots
    -> SNIP SCAN firmware WORKS successfully SUCCESS ON SECOND TRY !!

I tried this 3 step, with other firmwares and the result is always the . Below is the error I get in the first time

Error setting application size!!
Error setting application size!!
Writing chunk 2 of size 1024 from offset 1024
Writing chunk 3 of size 1024 from offset 2048

The second time, I don’t get this error hence the OTA update works successfully.

I tracked this in the code and found this in wiced_ota_server.c, the last if condition is where the problem occurs

static int process_upgrade_chunk( ota_http_request_message_t* request, wiced_tcp_stream_t* stream, void* arg )
{
    int              i           = 0;
    uint32_t         offset      = 0;
    uint32_t         file_size   = 0;
    static uint32_t  chunk_count = 0;
    static uint32_t  expected_offset = 0;
    uint32_t         received_offset = 0;
    char             offset_string[13];
    static wiced_app_t app;


    offset    = atoi( strstr((char*)request->query_ptr, "offset=") + strlen("offset=") );
    file_size = atoi(strstr((char*)request->query_ptr, "filesize=") + strlen("filesize=") );
    received_offset = offset;

    if( expected_offset != offset )
    {
        memset(offset_string, 0x00, sizeof(offset_string));
        sprintf(offset_string, "%lu", expected_offset);
        wiced_tcp_stream_write( stream, offset_string, strlen(offset_string));
        return 0;
    }


    if (offset == 0)
    {
        uint32_t    current_size;
        if (wiced_framework_app_open( DCT_APP0_INDEX, &app ) != WICED_SUCCESS)
        {
            return -1;
        }
        if (wiced_framework_app_get_size( &app, &current_size ) != WICED_SUCCESS)
        {
            return -1;
        }
        if (wiced_framework_app_set_size( &app, file_size) != WICED_SUCCESS)
        {
            return -1;
        }
        if (wiced_framework_app_get_size( &app, &current_size ) != WICED_SUCCESS)
        {
            return -1;
        }
        if ( current_size < file_size )
        {
            printf("Error setting application size!!\n");
            return -1;
        }
    }

Does this also happen to you too? Can you please guide me for solving this problem too :slight_smile:
thank you very much
rifo


#17

You can print the current_size before and after the wiced_framework_app_set_size() and then add more debug message within the under layer invoked functions. These functions are defined in the ‘WICED-SDK-3.7.0/include.wiced_framework.h’.

The key point is the APPs lookup table (LUT) in the external SPI flash. The LUT is a collection of headers specifying the memory mapping for accessing the apps in the external SPI flash (refer to the ./WICED/internal/dct.c). Since the OTA downloaded file (it seams like the OTA file is stored to APP0) is stored to where according to the LUT and the LUT is only downloaded into external SPI flash when building application with the RB_DUO_ext platform, so you may need to manually update the LUT before the OTA progress, in case that the LUT is invalid.

It would be good for you to investigate the code yourself to understand the WICED Apps framework so that you can play with the wiced application at will. :wink:

Cheers!


#18

Hello @guohui

I have been going through the source code trying to get a better understanding of the update mechanism.
I have added printf for the current size.

The first time I read below values
file size 461400
current size 0

Once update fails, I upload the file again via Web Page and then I get

file size 461400
current size 462848

So somehow, I can’t read the current_size correctly. I didn’t really understand how I can manually update the LUT before OTA, I will keep studying the code for that.

Before we can start producing a batch of our redbear duo based product, I need to demo our customer that OTA works. I would be most happy if you can also help in finding a fix for this :slight_smile:

thank you
rifo

ps: Am I right that you also see the same behaviour?


#19

Hi @riforifo, I tried several stripped elf files built with RB_DUO platform and they all worked fine. What example resulted your failure?

And what is the current_size you printed? before setting size or after setting size?

Before digging deep the OTA mechanism, I introduce you more details about the application framework herein.

  1. There is an entry point in the internal DCT for accessing each of the APP header. All of the APP headers make up the LUT, which is located in external SPI falsh.

  2. Each APP header contains the start sector and the sectors it uses, which will be used to calculated the physical address of the external SPI flash for this APP.

  3. The LUT will be downloaded via WICED IDE only when building application with platform RB_DUO_ext with download_apps options as discussed before.

  4. Every time writing or reading the APP from external SPI flash, it must read the APP header according to the header entry point in internal DCT. Then calculate the SPI flash physical address to update or read the APP.

So if you build applications with RB_DUO, then you need to settle down the LUT through application according to the header entry point, which read from internal DCT. To settle down the LUT, you need to invoke then SPI flash driver. Please refer to ./WICED/platform.MCU/wiced_apps_common.c, function wiced_apps_set_size(). This function update the APP header and its entry point is updated by ./WICED/platform/MCU/wiced_waf_common.c, function wiced_waf_app_set_size() -> wiced_dct_set_app_header_location().

Then next time the OTA server will place this OTA downloaded file to where the APP header specifies.

So why the current_size is zero you need to print more message when setting the file size. It must be somewhere occurs an error and so that you can fix it appropriately.

Cheers!


#20

Hello @guohui

I have used a new redbear duo and ota_fr works without problems now. I can update my problem on my first upload. I was using the snip example codes and didn’t change anything so I think it was a hardware issue.

Still,I can’t guess which part of the hardware was problematic since aside from OTA, other examples seemed to work without problems.

About the app size, below are the printed values, before and after setting the new app

Before App Set Size
file size 461408
current size 0

After App Set Size
file size 461408
current size 462848

In my first app_get_size for current, I read 0

Thanks a lot for the detailed explanation about the application framework. I will try to get a better understanding of the system. It seems a little complicated but I guess things will get clear with time

thanks one more time
rifo