Hi Dialog,
We're running into a strange problem. Trying to use SUOTA in prox-repoter example in the SDK. The suota enabled firmware is runing fine and even uploads the new image from the suota app; however when the device reboots the firmware isn't updated i.e. it's still booting from the older version. Same steps and same FW on Dev-kit pro is working fine and the FW is being updated.
What is the issue here?
Device:
Hi mutahir,
Since this is an issue that occurs, i suppose, on a custom board and not on a dev kit, i can only guess what can possibly go wrong, since the image is updating, as far as you mention, then to problem should be caused by the ble_suota_loader. When the device reboots and having any kind of issues with the image currently downloaded then it will just boot with the ble suota loader and not with the previous image since this should be overwritten by the new one as soon as the devices starts the booting procedure (which is weird).
What you could do in order to debug this is to #define the dg_configDEBUG_TRACE in order to print the messages that the bootloader prints as soon as its executes. What i can assume is that when the new image is downloaded the bootloader doesn't see a valid header (0x70 0x61) at the corresponding offset, so it doesn't go through the updating of the image (in case the image is valid) or the erasing of the image (if the image is invalid) and he boots with the current image. So a good place to start the debugging is the ble_suota_loader. You can also verify using the Smart Snippets if the NVMS_FW_UPDATE_PART has data after the SUOTA update.
Thanks MT_dialog
Thanks for the reply, in this case shouldn't the device be stuck after booting up? but our device after reboot doesn't get stuck and keep working with the previous FW.
Hi mutahir,
No, if there is something wrong with the newly updated image the ble_suota_loader will check the current image and if the current image is ok then this is what is going to be executed. In case that the loader finds the current image faulty as well the BLE suota loader will lauch a basic BLE application with only the SUOTA service. In any case the device will advertise either with one of the images (new or current image) or with a simple SUOTA enabled project and it will not get stuck.
Thanks MT_dialog
Hi Dialog,
So we have checked the NVMS_FW_UPDATE_PART through the toolbox and there is nothing being written on it (only in case of the custom DUT)
What can be the probable cause for this?
HI Dialog,
This is still regards to using SUOTA on custom DUT (dev-kit its still running fine)
We have investigated this further and when we use the debug and follow the write to flash part of the SUOTA it goes smoothly and tells us that we have written the number of bytes we need to write (first 512) but when we open the smart snippets toolbox the NVMS_FW_UPDATE_PART is empty.
We have tried to write to NVMS_FW_UPDATE_PART using a custom code in the program and can verify through the smart snippets toolbox that the NVMS_FW_UPDATE_PART has the exact value we write trough custom BLE service. We are using ad_nvms_write() function
What are we missing? Do we need to do some initialization?
Hi mutahir,
There is no obvious reason for this kind of behaviour, there is no flag in order for the SUOTA application to properly write to the proper NVMS_FW_UPDATE_PART and since this is replicated with the SUOTA running only on the custom board and not on the dev kit (i suppose that you are using the exact code for the tests ? ) apparently this is something related with the h/w that you are using and not the s/w.
Since the SUOTA application updates properly i find it a bit hard to be a problem in the writting procedure , i mean if there was something wrong in writing, the application would mention that something went wrong with writing to the external memory, so in order to test it a bit more start the update procedure and in the middle of the update hit the connect from the Smart Snippets tool (in order to be sure that there is a write execution on the flash and also verify first that the update image partition is empty) and try to read back the info from that partition and check if they dont contain anything or they do contain a part of the image (dont let the ble_suota_loader to run since this might erase the data).
If they dont contain anything then there must be something wrong with the flash. If they do contain part of the image, then something is wrong with the header file and when the loader runs it erases the entire updated image. You can also check regarding the erase of the bootloader via the defining the dgconfigDEBUG_TRACE and check from which parts of the code the bootloader goes by.
另外也有可能是partition table that the ble_suota_loader is aware of and the application uses are different, for example in case you are using a different size flash and you have a custom partition table, for this custom partition, the ble_suota_loader should also be aware of, since the loader uses by default the USE_PARTITION_TABLE_1MB_WITH_SUOTA, so the images and data that its is going to obtain are based on that partition.
Thanks MT_dialog
The flash size is 1M same as the dev-kit.
We are runing the same code for both DUT and the dev-kit.
What we have done is use the ad_nvms_read() right after the ad_nvms_write() is used in the SUOTA code. and printed few of the bytes.
The fw is writing the first chunk of 512 correctly but afterwards nothing is written. Sometimes it goes further but then starts to write nothing. So when the bootloader starts it doesnt get the valid new image header, because nothing is being written at 0
What can be the issue here?
some of the UART prints are given below: (as you can it begins to go wrong at 0x824
ERASING HEADER
ERASING 0 36
Writing Image Data on 24 512
Writing Image Data on 24:[0] 0 [1] 80 [2] fd [3] 7 [4] 35 [5] 1 [6] 2 [7] 8
Reading Image Data UPDT_PART on 24:[0] 0 [1] 80 [2] fd [3] 7 [4] 35 [5] 1 [6] 2 [7] 8
Writing Image Data on 224 512
Writing Image Data on 224:[0] 0 [1] 0 [2] fc [3] 7 [4] c0 [5] 0 [6] fc [7] 7
Reading Image Data UPDT_PART on 224:[0] 0 [1] 0 [2] fc [3] 7 [4] c0 [5] 0 [6] fc [7] 7
Writing Image Data on 424 512
Writing Image Data on 424:[0] 27 [1] e0 [2] 0 [3] 2b [4] 14 [5] da [6] 3 [7] 25
Reading Image Data UPDT_PART on 424:[0] 27 [1] e0 [2] 0 [3] 2b [4] 14 [5] da [6] 3 [7] 25
Writing Image Data on 624 512
Writing Image Data on 624:[0] dd [1] 43 [2] 0 [3] 9b [4] ab [5] 42 [6] c5 [7] d1
Reading Image Data UPDT_PART on 624:[0] dd [1] 43 [2] 0 [3] 9b [4] ab [5] 42 [6] c5 [7] d1
Writing Image Data on 824 512
Writing Image Data on 824:[0] 0 [1] 2a [2] fb [3] da [4] 10 [5] bd [6] 0 [7] 0
Reading Image Data UPDT_PART on 824:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff
Writing Image Data on a24 512
Writing Image Data on a24:[0] 7 [1] 39 [2] a [3] 43 [4] da [5] 86 [6] 70 [7] 47
Reading Image Data UPDT_PART on a24:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff
Writing Image Data on c24 512
Writing Image Data on c24:[0] 30 [1] b5 [2] 40 [3] 1 [4] 0 [5] 23 [6] 8c [7] 7
Reading Image Data UPDT_PART on c24:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff
ERASING 1000 36
Writing Image Data on e24 512
Writing Image Data on e24:[0] 62 [1] 88 [2] 13 [3] 40 [4] 6 [5] 22 [6] 5b [7] 9
Reading Image Data UPDT_PART on e24:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff
Hi mutahir,
What is the flash that you are using on the custom board ? Is the same as the one on the dev kit ?
Thanks MT_dialog
We are using the GD25LQ80.http://www.xinyahong.com/upLoad/product/month_1411/201411181636261776.pdf
It has similar specs as the one used on dev-kit
Is there a sample mem-test program that we can use to check the integrity of the flash? The SUOTA problem is persistent across all of our current DUTs
Hi Dialog,
We have figured out the problem. The problem was that our flash wasn't configured properly and the custom_config_qspi_suota in the main application and the custom_config_qspi in the bootloader didn't have the proper defines so the default configurations in the bsp_defaults were being loaded which had different flash than our device's flash. Including the following lines in custom_config_qspi_suota in the main application and the custom_config_qspi in the bootloader, solved the problem:
//FLAH configurations
#define dg_configFLASH_HEADER_FILE "qspi_gd25lq80b.h"
#define dg_configFLASH_MANUFACTURER_ID GIGADEVICE_ID
#define dg_configFLASH_DEVICE_TYPE GD25LQ_SERIES
#定义dg_configFLASH_DENSITY GD25LQ80B_SIZE
我认为guideli对话框应该包括适当的设置nes in the UM-B-056 software developer's guide also.
These settings are for the gd25lq80b flash chip; please refer to section 10.2.1.4 of UM-B-044 software platform reference for proper settings for a different flash