3 Replies Latest reply on Feb 5, 2020 11:37 PM by HiIw_4620611

    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.

        • 1. Re: Understanding for embedding OTA function
          HirotakaT_91

          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

          • 2. Re: Understanding for embedding OTA function
            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.

            • 3. Re: Understanding for embedding OTA function
              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.