I was trying to add SUOTA support to my application and it didn't work the first time.
As I was debugging I tried to read the partition table:
cli_programmer /dev/ttyUSB0 read_partition_table
>> No partition table found!!
OK, in the readme_suota.md of the pxp_reporter project I found:
If such partitions were not present on the target device the easiest way to fix this is to erase the existing
partition table sector. The bootloader will recreate it with correct values.
So I did:
cli_programmer /dev/ttyUSB0 chip_erase_qspi
I even did:
cli_programmer /dev/ttyUSB0 erase_qspi 0 4096
"Erasing bootloader area"
and
cli_programmer /dev/ttyUSB0 erase_qspi 0x7F000 4096
"Erasing partition table"
as found in the initial_flash.sh script.
Then:
cli_programmer -b uartboot.bin /dev/ttyUSB0 boot
according to the cli_command readme.md this should load the bootloader into RAM and execute it.
After this I have two problems.
1. cli_programmer /dev/ttyUSB0 read_partition_table still response with >> No partition table found!!
2.米y original application will not boot anymore.
If I do
cli_programmer --prod-id DA14681-01 /dev/ttyUSB0 write_qspi_exec application.bin
the application gets loaded but does not boot.
cli_programmer /dev/ttyUSB0 read_qspi 0 -- 4096
Shows me that the application.bin is loaded but not on addess 0x0 it has been shifted 8 bytes.
The byte sequence that starts at address 0x0 is 0x71 0x51 0x00 0x00 0x80 0x01 0x91 0x28
Any suggestions?
BTW the application.bin (with #define dg_configSUOTA_SUPPORT (0) ) was functional before I tried to add SUOTA support.
Hi Myken,
I have asked our team to reach out to you directly for support.
/MHv
Hi Myken
Setting just the #define dg_configSUOTA_SUPPORT (0) will not be enough for having the SUOTA supported.
有需要考虑拟议。
The attached document explains the SUOTA in Chpater 9 and how to build properly a SUOTA aware application. There is also a good ammount of information for the partition table and the flow diagram of the SUOTA and SUOTA booter. It explains in details the process and walk you through that using the existing example applications comming with the SDK.
Please check the chapter 9, follwo the instructions in there and if there are more questions to ask, we will be happy to assist you.
文档也可用https://support.dialog-semicondiondum./system/files/resources/UM-B-056...however you need to get an account to access it. You can apply online athttps://support.dialog-semicondiondum.for an account if you do not have one already.
Regarding the inital 8 bytes you see in the FLASH image, those exist for any project you program to the FLASH and they consist the header needed by the ROM booter in order to identify the type of the image to load from FLASH. These 8 bytes are added automatically by the cpi_programmer tool or the Toolbox (whichever you use for programming the FLASH).
此标题未损坏或更改应用程序图像。ROM Booter预期闪存上的图像中的转换，并在加载其考虑到它的图像时。
Do not worry of these 8 bytes. They have to be there. If they are not the image will not boot.
Best Regards
NV_Dialog.
Hello Dialog,
Thanks for your answer.
Turns out I had a residue setting (dg_configIMAGE_FLASH_OFFSET) from trying to implement SUOTA, that is why my original application didn't boot when I tried to get back to the starting point. That solved problem 2.
And mysteriously also problem 1. Don't know why but now I can read the partition of the flash.
Thanks for the document I will read it carefully and if I get into trouble I'll open a new topic.
Cheers, Robert.