6 posts / 0 new
Last post
Stone_wang
Offline
Last seen:9 months 1 week ago
Joined:2015-10-23 03:55
关于产品的最终测试与烧写

参考文档:@@AN-B-020_v1.2_End product testing and programming guidelines.pdf
使用的Jlink进行烧写:
总结整个烧写流程如下
1.使用Jlink烧写cust_prod_test_ES5.hex (Dialog 原厂提供)。
2.烧写完成即可通过串口进行晶振校准,RF测试功能。
3.以上测试完成得到晶振校准值,记录下来。
4.使用jlink烧写programer_ES5.bin(Dialog 原厂提供)。
5.使用Jlink烧写Custom Code hex file(即我们开发的应用程序)。
6.烧写NVDS(此步骤可选)可烧可不烧。
7.烧写OTP Header。
整个流程都验证过,是可以的。但有如下几个问题。
1、在第三步,得到了晶振校准值,可以先加上6.8v 直接烧写如OTP吗? 然后6.8v一直不断开,直到烧写CustomCode.hex 跟OTP Header 后才断开6.8v。 这样可以吗?
2、OTP的烧写区域是不是可以分开烧写?(意思是 OTP中有很多参数,比如Application Flag1/2,IQ_Trim,Device unique ID 等等,我可以第一次烧写Device unique ID 之后,芯片完全断电,重新再烧写OTP Header中的Application Flag 1吗?此时是不是Device unique ID 的内容烧写是无效的,如果重复烧写是否会导致坏掉?)
3、如需要烧写NVDS,是否要把源码中的nvds 读取宏定义取消掉?

谢谢您的回答。

Device:
Gongyu_Dialog
Offline
Last seen:2 days 14 hours ago
Joined:2016-04-27 07:07
1.这样没问题。参见我们的回复:

1.这样没问题。参见我们的回复:
It is actually not very critical how long the high voltage is applied to the chip. The VPP control pin will only switch on the VPP at the beginning of the programming cycle and disable it afterwards.
Advice is to switch of the VPP as soon as possible but this is not in the order of ms.
2.application flag没写仅是告诉bootloader不要从OTP那里去boot,之前写的内容已经生效。重复烧写应该不起作用了。
3.如需要烧写NVDS,是否要把源码中的nvds 读取宏定义取消掉?
//你说的是哪个宏?

Stone_wang
Offline
Last seen:9 months 1 week ago
Joined:2015-10-23 03:55
Hi,Gongyu:

Hi,Gongyu:
如下的定义:READ_NVDS_STRUCT_FROM_OTP ,
#ifdef READ_NVDS_STRUCT_FROM_OTP
const struct nvds_data_struct nvds_data_storage __attribute__((section("nvds_data_storage_area")));
#else
const struct nvds_data_struct nvds_data_storage __attribute__((section("nvds_data_storage_area"))) =
{
.NVDS_VALIDATION_FLAG = 0x1ffff,
…………
.NVDS_TAG_APP_BLE_ADV_DATA = "\x1A\xFF\xD2\x00\x02\x15\x58\x5C\xDE\x93\x1B\x01\x42\xCC\x9A\x13\x25\x00\x9B\xED\xC6\x5E\x00\x00\x00\x00\xC5",
.NVDS_TAG_APP_BLE_SCAN_RESP_DATA = " \ x09 \ xFF \ x00 \ x60\x52\x57\x2D\x42\x4C\x45",
.NVDS_TAG_DEVICE_NAME
.NVDS_TAG_BD_ADDRESS
……………
.NVDS_TAG_BLE_CA_NB_BAD_PKT = 50,
};
有另一个问题:参照上述的参考文档中提到:
Enable XTAL trimming calibration flag.
=> prodtest.exe -p 41 otp we_xtrim
Write BD address into OTP header.
=> prodtest.exe -p 41 otp wr_bdaddr 06:05:04:03:02:01
问: 该命令烧写的位置是否为NVDS里面的内容?

Gongyu_Dialog
Offline
Last seen:2 days 14 hours ago
Joined:2016-04-27 07:07
定义了READ_NVDS_STRUCT_FROM_OTP

定义了READ_NVDS_STRUCT_FROM_OTP ,说明这些参数都存放在OTP里,而不是外部flash里面。另外,你用的SDK版本是什么?

你可以导入prod_test的工程,在host_hci.c文件里 查看hci_dialog_otp_wr_bdaddr函数。

在customer_prod.c里面找到函数hci_otp_rw_cmd,可以看到地址是写的0x7fd4的地方(OTP里存放地址的地方),这并不是NVDS里的内容

Stone_wang
Offline
Last seen:9 months 1 week ago
Joined:2015-10-23 03:55
sdk : 3.0.6

sdk : 3.0.6
另外问题: 没定义READ_NVDS_STRUCT_FROM_OTP ,那么蓝牙地址跟设备名称等信息都是定义在源码中const struct nvds_data_struct nvds_data_storage __attribute__((section("nvds_data_storage_area"))) = ……这个结构体中。
那么,源码中的地址是不能改变的(0x112233445566,那么又往OTP写了如下参数,那最终蓝牙地址会是哪一个?
Write BD address into OTP header.
=> prodtest.exe -p 41 otp wr_bdaddr 06:05:04:03:02:01

Gongyu_Dialog
Offline
Last seen:2 days 14 hours ago
Joined:2016-04-27 07:07
首先设定宏NVDS_SUPPORT是定义的

首先设定宏NVDS_SUPPORT是定义的,上电之后在lld_init_func(ROM里的代码)会调用nvds_get函数去获取蓝牙地址,并存放到0x40000024和0x40000028寄存器里面。后面组包都会从这两个寄存器里面拿地址。

再看nvds_get这个函数,ROM里会调用Jump_table里的custom_nvds_get_func函数(这个函数SDK里可以看到)。
里面主要是从变量dev_bdaddr里获取蓝牙地址。而dev_bdaddr则是从之前nvds_read_bdaddr_from_otp里面拿到的。

里面涉及到几个宏,因为组合起来有几种情况,你可以自己看打开或者关闭对取地址的影响。