嗨对话框,
我们遇到了一个奇怪的问题。尝试使用SUOTA在代理报告程序的例子在SDK。suota启用的固件运行良好,甚至上传新的图片从suota应用程序;然而,当设备重启固件没有更新,即它仍然从旧版本启动。相同的步骤和相同的FW在Dev-kit pro上工作良好,FW正在更新。
这里的问题是什么?
你好,穆
由于这是一个发生的问题,我想,在自定义板上而不是开发套件上,我只能猜测可能出错的是什么可能出错,因为图像正在更新,就你而言,应该引起问题由ble_suota_loader。当设备重新启动并具有当前下载的图像的任何问题时,它将只使用BLE Suota Loader启动,而不是使用上一张图像,因为这应该在设备启动引导过程后立即被新的图像覆盖(这很奇怪)。
为了调试它,您可以做的是#define dg_configDEBUG_TRACE,以便打印引导加载程序一执行就打印的消息。我可以假设是,当下载新形象引导装载程序并不认为一个有效的标题(0 x70 0 x61)相应的弥补,所以不经过图像的更新(如果图像是有效的)或擦除图像(如果图像是无效的),他的靴子与当前图像。因此,开始调试的一个好地方是ble_suota_loader。您还可以使用智能片段验证NVMS_FW_UPDATE_PART在SUOTA更新后是否有数据。
谢谢mt_dialog.
感谢您的回复,在这种情况下,设备不是应该启动后卡住吗?但我们的设备在重启后没有卡住,并继续使用之前的FW。
不,如果新更新的图像有什么问题,ble_suota_loader将检查当前的图像,如果当前的图像ok,那么这就是将要执行的。如果加载器发现当前的映像错误,BLE suota加载器将启动一个只有suota服务的基本BLE应用程序。在任何情况下,设备将广告与一个图像(新的或当前的图像)或一个简单的SUOTA启用项目,它不会卡住。
因此,我们已经通过工具箱检查了NVMS_FW_UPDATE_PART,并没有在其上写入任何内容(仅在自定义DUT的情况下)。可能的原因是什么?
仍然是在自定义DUT上使用Suota(Dev-kit仍然运行罚款)
我们进一步调查这个,当我们使用调试和遵循写入flash SUOTA它顺利的一部分,告诉我们,我们有写我们需要写的字节数(前512),但是当我们打开智能片段工具箱NVMS_FW_UPDATE_PART是空的。
我们尝试使用程序中的自定义代码写入nvms_fw_update_part,并可以通过nvms_fw_update_part的Smart Scippets工具箱验证,即NVMS_FW_UPDATE_PART具有我们编写TROUGH自定义BLE服务的确切值。我们正在使用ad_nvms_write()函数
我们错过了什么?我们需要做一些初始化吗?
没有明显的原因,这种行为,没有标志,以便拟议应用程序正确地写入正确的nvms_fw_update_part,因为这是用仅在自定义板上运行而不是在dev套件上运行的upota(i假设您使用的是测试的确切代码?)显然这是与您使用的H / W相关的东西,而不是S / W.
由于Suota应用程序更新,我发现写入过程中有点难以存在,我的意思是在写作中有问题,应用程序将提及写入外部内存的问题,所以为了测试它有点开始更新过程,在更新的中间点击从智能片段工具点击连接(以确保闪存上有写入执行,并且首先验证更新图像分区是否为空)尝试从该分区读取信息并检查它们是否包含任何内容,或者它们确实包含图像的一部分(不要让BLE_SUOTA_LOADER以来,因为这可能会删除数据)。
如果它们不包含任何东西,那么一定是闪光出了问题。如果它们确实包含了图像的一部分,那么头文件就出了问题,当加载器运行时,它会擦除整个更新后的图像。您还可以通过定义dgconfigDEBUG_TRACE检查引导加载程序的擦除情况,并检查引导加载程序从代码的哪一部分经过。
另外,BLE_SUOTA_LOADER所知的分区表也可能是不同的,并且应用程序使用是不同的,例如,如果您使用的情况使用不同的大小闪存,并且您有一个自定义分区表,则为此自定义分区,BLE_SUOTA_LOADER也应该请注意,由于加载程序默认使用USE_PARTITION_TABLE_1MB_WITH_SUOTA,因此其要获取的图像和数据基于该分区。
闪存大小为1M,与开发工具包相同。我们正在为DUT和Dev-kit运行相同的代码。
我们所做的就是在Suota代码中使用ad_nvms_write()之后使用ad_nvms_read()。并打印了很少的字节。FW正正确地写入512的第一个块,但之后没有写。有时它会进一步,但然后开始写入任何东西。因此,当引导加载程序启动它时,它不会获取有效的新映像标题,因为没有什么是在0时编写的
下面给出了一些UART打印:(如您所能在0x824开始出错
擦除头擦除0 36.在24 512上写图像数据在24:[0] 0 [1] 80 [2] FD [3] 7 [4] 35 [5] 1 [5] 1 [4] 2 [4] 2 [4]读取图像数据UPDT_PART on 24:[0] 0 [1] 80 [2] fd [3] 7 [4] 35 [5] 1 [6] 2 [7] 8在224上写入图像数据224上写图像数据:[0]0 [1]0 [2]fc [3] 7 [4] c0 [5] 0 [6] fc [7] 7读取图像数据updt_part在224:[0] 0 [1] 0 [2] FC [3] 7 [4] C0 [5] 0 [6] FC [7] 7在424 512上写图像数据在424上写图像数据:[0] 27 [1] E0 [2] 0 [3] 2b [4] 14 [5] DA [6] 3 [7] 25读取图像数据updt_part在424:[0] 27 [1] E0 [2] 0 [3] 2b [4] 14 [5] DA [6] 3 [7] 25在624 512上写图像数据在624上写图像数据:[0] DD [1] 43 [2] 0 [3] 9b [4] Ab [5] 42 [6] C5 [7] D1读取图像数据updt_part在624:[0] DD [1] 43 [2] 0 [3] 9b [4] Ab [5] 42 [6] C5 [7] D1在824 512上写入图像数据在824上写Image Data:[0] 0 [1] 2a [2] fb [3] da [4] 10 [5] bd [6] 0 [7] 0读取图像数据UPDT_PART on 824:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff在a24上写入图像数据在A24:[0] 7 [1] 39 [2] [3] 43 [4] DA [5] 86 [6] 70 [7] 47读取图像数据updt_part在A24:[0] FF [2] FF [3] FF [4] FF [5] FF [6] FF [7] FF在C24 512上写图像数据在c24上写Image Data:[0] 30 [1] b5 [2] 40 [3] 1 [4] 0 [5] 23 [6] 8c [7] 7读取图像数据UPDT_PART在c24:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff擦除1000年36在E24 512上写图像数据在e24上写图像数据:[0] 62 [1] 88 [2] 13 [3] 40 [4] 6 [5] 22 [6] 5b [7] 9读取图像数据UPDT_PART on e24:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff
您在定制板上使用的闪存是什么?与Dev套件上的那样是一样的吗?
我们正在使用GD25LQ80。http://www.xinyahong.com/upLoad/product/month_1411/201411181636261776.pdf它具有与在Dev-kit上使用的规格相似
是否有一个样本mems测试程序,我们可以用来检查flash的完整性?SUOTA问题在我们当前的所有dut中都存在
我们已经解决了这个问题。问题是我们的flash不正确配置和custom_config_qspi_suota主要应用程序和custom_config_qspi引导装载程序没有正确定义的默认配置bsp_defaults被加载比我们的设备有不同的闪光的闪光。包括主应用程序中的custom_config_qspi_suota和引导加载程序中的custom_config_qspi中的以下行,解决了这个问题:// Flah配置#定义dg_configFLASH_HEADER_FILE“qspi_gd25lq80b.h”#定义dg_configFLASH_MANUFACTURER_ID GIGADEVICE_ID#定义dg_configFLASH_DEVICE_TYPE GD25LQ_SERIES#定义dg_configFLASH_DENSITY GD25LQ80B_SIZE
我认为DIalog也应该在UM-B-056软件开发人员指南中包含适当的设置指南。
这些设置是针对gd25lq80b闪存芯片的;请参阅UM-B-044软件平台参考的10.2.1.4节,了解不同flash的适当设置
你好,穆
由于这是一个发生的问题,我想,在自定义板上而不是开发套件上,我只能猜测可能出错的是什么可能出错,因为图像正在更新,就你而言,应该引起问题由ble_suota_loader。当设备重新启动并具有当前下载的图像的任何问题时,它将只使用BLE Suota Loader启动,而不是使用上一张图像,因为这应该在设备启动引导过程后立即被新的图像覆盖(这很奇怪)。
为了调试它,您可以做的是#define dg_configDEBUG_TRACE,以便打印引导加载程序一执行就打印的消息。我可以假设是,当下载新形象引导装载程序并不认为一个有效的标题(0 x70 0 x61)相应的弥补,所以不经过图像的更新(如果图像是有效的)或擦除图像(如果图像是无效的),他的靴子与当前图像。因此,开始调试的一个好地方是ble_suota_loader。您还可以使用智能片段验证NVMS_FW_UPDATE_PART在SUOTA更新后是否有数据。
谢谢mt_dialog.
感谢您的回复,在这种情况下,设备不是应该启动后卡住吗?但我们的设备在重启后没有卡住,并继续使用之前的FW。
你好,穆
不,如果新更新的图像有什么问题,ble_suota_loader将检查当前的图像,如果当前的图像ok,那么这就是将要执行的。如果加载器发现当前的映像错误,BLE suota加载器将启动一个只有suota服务的基本BLE应用程序。在任何情况下,设备将广告与一个图像(新的或当前的图像)或一个简单的SUOTA启用项目,它不会卡住。
谢谢mt_dialog.
嗨对话框,
因此,我们已经通过工具箱检查了NVMS_FW_UPDATE_PART,并没有在其上写入任何内容(仅在自定义DUT的情况下)。
可能的原因是什么?
嗨对话框,
仍然是在自定义DUT上使用Suota(Dev-kit仍然运行罚款)
我们进一步调查这个,当我们使用调试和遵循写入flash SUOTA它顺利的一部分,告诉我们,我们有写我们需要写的字节数(前512),但是当我们打开智能片段工具箱NVMS_FW_UPDATE_PART是空的。
我们尝试使用程序中的自定义代码写入nvms_fw_update_part,并可以通过nvms_fw_update_part的Smart Scippets工具箱验证,即NVMS_FW_UPDATE_PART具有我们编写TROUGH自定义BLE服务的确切值。我们正在使用ad_nvms_write()函数
我们错过了什么?我们需要做一些初始化吗?
你好,穆
没有明显的原因,这种行为,没有标志,以便拟议应用程序正确地写入正确的nvms_fw_update_part,因为这是用仅在自定义板上运行而不是在dev套件上运行的upota(i假设您使用的是测试的确切代码?)显然这是与您使用的H / W相关的东西,而不是S / W.
由于Suota应用程序更新,我发现写入过程中有点难以存在,我的意思是在写作中有问题,应用程序将提及写入外部内存的问题,所以为了测试它有点开始更新过程,在更新的中间点击从智能片段工具点击连接(以确保闪存上有写入执行,并且首先验证更新图像分区是否为空)尝试从该分区读取信息并检查它们是否包含任何内容,或者它们确实包含图像的一部分(不要让BLE_SUOTA_LOADER以来,因为这可能会删除数据)。
如果它们不包含任何东西,那么一定是闪光出了问题。如果它们确实包含了图像的一部分,那么头文件就出了问题,当加载器运行时,它会擦除整个更新后的图像。您还可以通过定义dgconfigDEBUG_TRACE检查引导加载程序的擦除情况,并检查引导加载程序从代码的哪一部分经过。
另外,BLE_SUOTA_LOADER所知的分区表也可能是不同的,并且应用程序使用是不同的,例如,如果您使用的情况使用不同的大小闪存,并且您有一个自定义分区表,则为此自定义分区,BLE_SUOTA_LOADER也应该请注意,由于加载程序默认使用USE_PARTITION_TABLE_1MB_WITH_SUOTA,因此其要获取的图像和数据基于该分区。
谢谢mt_dialog.
闪存大小为1M,与开发工具包相同。
我们正在为DUT和Dev-kit运行相同的代码。
我们所做的就是在Suota代码中使用ad_nvms_write()之后使用ad_nvms_read()。并打印了很少的字节。
FW正正确地写入512的第一个块,但之后没有写。有时它会进一步,但然后开始写入任何东西。因此,当引导加载程序启动它时,它不会获取有效的新映像标题,因为没有什么是在0时编写的
这里的问题是什么?
下面给出了一些UART打印:(如您所能在0x824开始出错
擦除头
擦除0 36.
在24 512上写图像数据
在24:[0] 0 [1] 80 [2] FD [3] 7 [4] 35 [5] 1 [5] 1 [4] 2 [4] 2 [4]
读取图像数据UPDT_PART on 24:[0] 0 [1] 80 [2] fd [3] 7 [4] 35 [5] 1 [6] 2 [7] 8
在224上写入图像数据
224上写图像数据:[0]0 [1]0 [2]fc [3] 7 [4] c0 [5] 0 [6] fc [7] 7
读取图像数据updt_part在224:[0] 0 [1] 0 [2] FC [3] 7 [4] C0 [5] 0 [6] FC [7] 7
在424 512上写图像数据
在424上写图像数据:[0] 27 [1] E0 [2] 0 [3] 2b [4] 14 [5] DA [6] 3 [7] 25
读取图像数据updt_part在424:[0] 27 [1] E0 [2] 0 [3] 2b [4] 14 [5] DA [6] 3 [7] 25
在624 512上写图像数据
在624上写图像数据:[0] DD [1] 43 [2] 0 [3] 9b [4] Ab [5] 42 [6] C5 [7] D1
读取图像数据updt_part在624:[0] DD [1] 43 [2] 0 [3] 9b [4] Ab [5] 42 [6] C5 [7] D1
在824 512上写入图像数据
在824上写Image Data:[0] 0 [1] 2a [2] fb [3] da [4] 10 [5] bd [6] 0 [7] 0
读取图像数据UPDT_PART on 824:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff
在a24上写入图像数据
在A24:[0] 7 [1] 39 [2] [3] 43 [4] DA [5] 86 [6] 70 [7] 47
读取图像数据updt_part在A24:[0] FF [2] FF [3] FF [4] FF [5] FF [6] FF [7] FF
在C24 512上写图像数据
在c24上写Image Data:[0] 30 [1] b5 [2] 40 [3] 1 [4] 0 [5] 23 [6] 8c [7] 7
读取图像数据UPDT_PART在c24:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff
擦除1000年36
在E24 512上写图像数据
在e24上写图像数据:[0] 62 [1] 88 [2] 13 [3] 40 [4] 6 [5] 22 [6] 5b [7] 9
读取图像数据UPDT_PART on e24:[0] ff [1] ff [2] ff [3] ff [4] ff [5] ff [6] ff [7] ff
你好,穆
您在定制板上使用的闪存是什么?与Dev套件上的那样是一样的吗?
谢谢mt_dialog.
我们正在使用GD25LQ80。http://www.xinyahong.com/upLoad/product/month_1411/201411181636261776.pdf
它具有与在Dev-kit上使用的规格相似
是否有一个样本mems测试程序,我们可以用来检查flash的完整性?SUOTA问题在我们当前的所有dut中都存在
嗨对话框,
我们已经解决了这个问题。问题是我们的flash不正确配置和custom_config_qspi_suota主要应用程序和custom_config_qspi引导装载程序没有正确定义的默认配置bsp_defaults被加载比我们的设备有不同的闪光的闪光。包括主应用程序中的custom_config_qspi_suota和引导加载程序中的custom_config_qspi中的以下行,解决了这个问题:
// Flah配置
#定义dg_configFLASH_HEADER_FILE“qspi_gd25lq80b.h”
#定义dg_configFLASH_MANUFACTURER_ID GIGADEVICE_ID
#定义dg_configFLASH_DEVICE_TYPE GD25LQ_SERIES
#定义dg_configFLASH_DENSITY GD25LQ80B_SIZE
我认为DIalog也应该在UM-B-056软件开发人员指南中包含适当的设置指南。
这些设置是针对gd25lq80b闪存芯片的;请参阅UM-B-044软件平台参考的10.2.1.4节,了解不同flash的适当设置