- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- After reset start, main of waf/bootloader/bootloader.c starts from crt0.
- Read boot information from DCT by wiced_dct_read_with_copy() function.
- 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)
- 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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.