嗨,对话框中,
i am working on a custom board for some time now, I am using a macronix flash.
i did manage to have suota working using the sdk 1.0.8. on my custom board.
i did check the forum and i have problem really similar to the one below :
https://support.dialog-semiconductor.com/forums/post/dialog-smartbond-bl....
I use a custom partition table which i updated to the ble_suota_loader project as well as the macronix flash files as below :
#define dg_configFLASH_HEADER_FILE "qspi_mx25r3235.h"
#define dg_configFLASH_MANUFACTURER_ID MACRONIX_ID
#define dg_configFLASH_DEVICE_TYPE MX25R_SERIES
#define dg_configFLASH_DENSITY MX25R3235_SIZE
我也检查dg_configIMAGE_FLASH_OFFSET parameter matches my partition table.
When updating an image through the smart app, everything seems fine but then loader reboot and never jump to my code.
i tried with my own code and with the pxp_reporter project with the same result.
I tried on the pro dk with the same results.
It seems the image header is corrupt or not copied.
where should i look?
Thanks for your help.
matthieu
Hi MatthieuW,
Well in the forum post that you are refering the user haven't defined the custom flash that he was using, and since you are using a flash that its not supported by default from the SDK, you will have you created the proper drivers for the flash that its been used from your custom board, which i suppose that you have allready done that (please take a look in the readme.md file in order to double check the procedure in order to add a custom flash on the SDK). Regarding the fact that you have used the dev kit, you mean you have used it and fail to update the device's fw using the flash that is allready supported by the SDK and the dev kit or you attached the custom flash on the dev kit ? since i ve checked using the proximity SUOTA enabled sw and i could perform the update properly.
If you think that this is an image header issue then you can check (after the upload of the new fw through SUOTA) the fw and the image header from the Smart Snippets QSPI partition table tool and read back the data from the flash after the update has occured.
Thanks MT_dialog
Hello,
i performed multiple tests.
I can use the OTA function on the pro devkit with a da14681 with the pxp reporter project and with my own project.
On my own board which implement a da14680 with internal flash, i can use the ota only with the pxpreporter project.
when sending my own project (same img as the one i send to the pro DK) , the dialog reboots endlessly as if the reset vector is not updated in ram.
However it is strange,
i use the attached partition table in the projects (ble_suota_loader, pxp_reporter and mine).
As my application needs more space i shifted the NVMS_PRODUCT_HEADER_PART to 0x22000.
If my understanding is correct, i must define in the application the dg_configIMAGE_FLASH_OFFSET accordingly to the NVMS_FW_EXEC_PART address (in the project i want to update), and the ble_suota_project must have the same partition table has the project i want to update.
The problem is that the pxp_reporter ota works only when i define the image_offset to 0x20000 which do not match my partition table.
I erase the flash before charging any project in order to update the partition table.
有什么我错过或misun吗derstanding something?
Thanks for your help.
matthieu
Hi matthiew,
I am quite confused from the partition table that you have attached, the offset that you have placed the NVMS_FW_EXEC_PART (which is the actual fw that the device will run after running the bootloader) is 0x25000 and not 0x22000. From the partition table you increased the space that the bootlaoder will be stored. Please take a look at the UM-B-056-DA1468x Software Developer Guide.pdf in paragraph 9.1.4 SUOTA Flash Memory Layout in order to check what goes where, and modify the partition table as you see fit. If you need more space for your NVMS_FW_EXEC_PART which is the location that the fw runs you will only need to modify the partitions under that specific partition, so you wont have to build for a different address. Also for you information the fact that you have builded the application for a different address other than the 0x20000 doesn't mean that the tool will automatically burn it at that location, you will have to alter the script as well in order for the image to be burned at the proper offset in the initial_flash.bat.
Thanks MT_dialog
HI,
sorry for the confusion,
i understood the partitions better now,
Thus i use now the attached partition and set the flash_offset to 0x20000.
The thing that i don't understand is why i can perform
- suota with my the ble_suota_loader and pxp_reporter and my own project on the pro dk.
- and with the exact same projects suota works only with the pxp reporter on my own board.
I checked with the debugger and the reset vector is not well copied at the end of the bootloader boot_application.
There must be some configuration missing.
Do you have any hints?
Thanks in advance.
matthieu
Hi matthieW,
The partition table that you have attached is identical with the partition tables used in the SDK examples, regarding that you are able to run the custom application and the pxp_reporter on the pro board and only the pxp_reporter on the custom board doesn't help much and i am not aware of any SDK configuration that will make a project board depended, can you please share some more details on this ? You perform the SUOTA procedure and what happens next with your board, i mean after the update you see that the ble_suota_loader application gets launced instead of the custom application ? You can debug the ble_suota_loader after the SUOTA procedure and check where the loader fails to boot from the updated image (check the boot_application() function of the ble_suota_loader() project).
Thanks MT_dialog
Hi,
i know it is confusing.
My board implements a DA14680 with integrated flash, whereas the pro dk implements a da14681 with external flash but the flash is the same reference for winbond.
I am also using the internal rc clock for low power on board and thus don't have a 32k quartz present.
Appart from this, the external perpherals are differents (on the i2c and spi bus) but it should not be relevant.
i updated my schematic.
Now when trying to perform suota :
- first i erase the flash content with qspi erase script.
-then i program the ble_suota_loader
- then i update the application program using the dialog suota smartapp.
- then i reboot the board and the suota loader update the new program to the firmware execution board, update the reset vector to the ram and reset
- but here instead of starting my application the suota loader is started, as the updated header as been erased by the loader the boot application jumps directly to the update of the reset vector and reboot and again and again.
It seems that the reset vector is not updated by the boot application or that my application start address is not good.
I don't know where this come from and where to look.
matthieu
Hi matthieuW,
Thats is indeed very odd, have you tried to run the custom application on the custom board without the SUOTA configuration (just as a regular project, just to check if the fw is causing anykind of reset forcing the ble_suota_loader to execute over and over), can you see the device operating properly ? Also the ble_suota_loader has a debugging feature (dg_configDEBUG_TRACE) perhaps you can set it up and this will give some extra information about what is happening.
Also i dont quite get what you are describing about the reset vector and the header, upon finishing the update the device will reboot and the bootloader will run again in order to copy the image from the updated part and copy the header of the image in the NVMS_IMAGE_HEADER_PART and the image in the NVMS_EXEC_PART. This will happen only one time depending on if the fw in the update partition is new or not. After the copy the updated image in the NVMS_EXEC_PART the device will take the interrupt vector table validate him and copy the table in the RAM at address 0 after reset the device will start the application having a vector table including a reset handler that corresponds to your application. The interrupt vector table from where your application will start depends on what is the IVT on your image, this is what is copied to the RAM. Check with the dg_configDEBUG_TRACE this will print out your image location and the reset vector of your current IVT.
Thanks MT_dialog