Understanding for embedding OTA function

[HiIw_4620611]

Hello.

When incorporating OTA functions into application creation,

Please teach me specific procedures and mechanisms for understanding.

• The target MPU is STM32F412 (ROM: 1MB / RAM: 256KB), with an external 4MB sflash.
• The operation of OTA to be implemented is as follows.

a). Download directly to APP0 of external flash in user application, check VALID, and rewrite DCT.

b). After the reboot, update the firmware according to the DCT settings.

Q1. Does the example described in WICED-OTA.pdf and WICED-WAF.pdf, correct with the following understanding?

1. After reset start, main of waf/bootloader/bootloader.c starts from crt0.
2. Read boot information from DCT by wiced_dct_read_with_copy() function.
3. When it is determined from the DCT boot information that there is an application update, the OTA-APP is deployed in RAM. (WICED-WAF.pdf 2.1)
4. Jump to entry point in boot information's.

Q2. The wiced_waf_app_load () function can be considered as processing to deploy the application from external/internal flash and RAM to external/internal flash and RAM.

Are the parameters to be given to load_details_t the following?

• .id: Means copy source type ... <NONE>, <INTERNAL>, <EXTERNAL_FIXED_LOCATION>(external sflash), or <EXTERNAL_FILESYSTEM_FILE>(It is Invalid, because BOOTLOADER_LOAD_MAIN_APP_FROM_FILESYSTEM is undefined)
• .detail.internal_fixed: { .location=<source address>, .size=<source size> }

Q2-1.How to specify when the extract destination is RAM?

Q3. Q2's parameters are considered to be included in the DCT boot information (DCT_INTERNAL_SECTION, platform_dct_header_t).

Can this DCT rewrite be done with wiced_framework_set_boot() function?

Q4. In the following generally method, Is there no problem with the way in thinking of a).?

wiced_framework_app_open( DCT_APP0_INDEX, &app );

wiced_framework_app_erase( &app );

wiced_framework_app_set_size( &app, app_size );

while ( eof )

{

    wiced_framework_app_write_chunk( &app, p_data, chunk_size );

}

for ( result = CRC32_INIT_VALUE, offset = 0; offset < app_size; offset += chunk_size )

{

    wiced_framework_app_read_chunk( &app, offset, p_data, chunk_size );

    result = crc32( p_data, chunk_size, result );

}

wiced_framework_app_close( &app );

if ( result == valid )

{

    wiced_framework_set_boot( DCT_APP0_INDEX, WICED_FRAMEWORK_LOAD_ONCE );

    wiced_framework_reboot( );

}

メッセージ編集者: Hiroyuki Iwasaki I wanted to get some answers, so translated it into English. Thank you.

[HirotakaT_91 · Accepted solution]

A1.1. Yes, it starts from _start() of the crt0_GCC.c based on the core that is used.

A1.2-4. Yes

A2. Yes.

Regarding the deploying to RAM, the implementation in WICED uses an external Flash by defaut and modifications such as deploying destination in RAM hasn't been tested. Please let us know if you face any issues while testing this out and we will try to debug the issue.

A3. The wiced_framework_set_boot() function is used to set the index of the APP that needs to be used on BOOT. An example of how to reqrite the contents of DCT has been provided at /43xxx_Wi-Fi/apps/snip/dct_read_write

A4. This is an enhancement which isn't present by default with the OTA implementation. Please feel free to implement this and try it out and do let us know if you face any issues during the implementation.

Best regards,

Hirotaka

[HiIw_4620611]

Hello.

With the code implemented based on Q4, I downloaded the file of the built apps and tried to rewrite the current application with bootloader.

As a result, when checking the dump of the internal flash, it was confirmed that the flash rewriting had been completed halfway, despite that wiced_waf_app_load() was WICED_SUCCESS.

(Because it was filled with "FF" halfway)

We're analyzing the cause, but please provide the following information as necessary information to solve it.

Q1. Does the boot loader(wiced_waf_app_load) expect to store the image in ELF32 format in the APP0 area?

It is this generated file.

build/<My APP>-<My Platform>-ThreadX-NetX_Duo-debug/<My APP>-<My Platform>-ThreadX-NetX_Duo-debug.stripped.elf

Q2. When loading the external flash from APP0 to the internal flash (current application), is the DCT information necessary only for the following calls?

wiced_framework_set_boot( DCT_APP0_INDEX, WICED_FRAMEWORK_LOAD_ONCE )

I think that the image size of APP0 is necessary, but we think that there is no problem if it is loaded only with information from the elf header.

dct_header.boot_detail.load_details.source.detail.external_fixed.size ?

The header information of the elf file stored in APP0 is attached below as information.

$ readelf -a <My APP>-<My Platform>-ThreadX-NetX_Duo-debug.stripped.elf

ELF Header:

  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00

  Class:                             ELF32

  Data:                              2's complement, little endian

  Version:                           1 (current)

  OS/ABI:                            UNIX - System V

  ABI Version:                       0

  Type:                              EXEC (Executable file)

  Machine:                           ARM

  Version:                           0x1

  Entry point address:               0x800c751

  Start of program headers:          52 (bytes into file)

  Start of section headers:          726168 (bytes into file)

  Flags:                             0x5000200, Version5 EABI, soft-float ABI

  Size of this header:               52 (bytes)

  Size of program headers:           32 (bytes)

  Number of program headers:         4

  Size of section headers:           40 (bytes)

  Number of section headers:         10

  Section header string table index: 9

Section Headers:

  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

  [ 0]                   NULL            00000000 000000 000000 00      0   0  0

  [ 1] .vectors          PROGBITS        0800c000 0000c0 00018c 00   A  0   0  4

  [ 2] .text             PROGBITS        0800c1c0 000280 0b0000 00  AX  0   0 64

  [ 3] .sleep_event_hand PROGBITS        080bc1c0 0b0280 00002c 00  AX  0   0  4

  [ 4] .sleep_event_hand PROGBITS        080bc1ec 0b02ac 000058 00  AX  0   0  4

  [ 5] .ARM.exidx        ARM_EXIDX       080bc244 0b0304 000008 00  AL  2   0  4

  [ 6] .data             PROGBITS        20000000 0b0310 0010ec 00  WA  0   0  8

  [ 7] .bss              NOBITS          200010f0 0b1400 0135fc 00  WA  0   0  8

  [ 8] .stack            NOBITS          200146ec 0b1400 000320 00  WA  0   0  1

  [ 9] .shstrtab         STRTAB          00000000 0b13fc 00009c 00      0   0  1

Key to Flags:

  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),

  L (link order), O (extra OS processing required), G (group), T (TLS),

  C (compressed), x (unknown), o (OS specific), E (exclude),

  y (purecode), p (processor specific)

There are no section groups in this file.

Program Headers:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align

  EXIDX          0x0b0304 0x080bc244 0x080bc244 0x00008 0x00008 R   0x4

  LOAD           0x0000c0 0x0800c000 0x0800c000 0xb024c 0xb024c R E 0x10

  LOAD           0x0b0310 0x20000000 0x080bc24c 0x010ec 0x010ec RW  0x10

  LOAD           0x0b1400 0x200010f0 0x200010f0 0x00000 0x1391c RW  0x10

Section to Segment mapping:

  Segment Sections...

   00     .ARM.exidx

   01     .vectors .text .sleep_event_handlers.sleep_rtos_event_handler .sleep_event_handlers.wiced_sleep_call_event_handlers .ARM.exidx

   02     .data

   03     .bss .stack

There is no dynamic section in this file.

There are no relocations in this file.

Unwind section '.ARM.exidx' at offset 0xb0304 contains 1 entry:

0x8092240: 0x1 [cantunwind]

No version information found in this file.

I would like cooperation for an early solution.

Thanks.

[HiIw_4620611]

Hi.

# The flash rewriting had been completed halfway,
About the above,

It was confirmed that all writing to the internal flash was completed normally.

I guess the cause is that a debugger was used.

Once, the question is withdrawn.
Repeat the trial several times and try to reproduce.

Thanks.