mt2503 不格式化下载，开机NVRAM恢复为默认值
时间：10-02
整理：3721RD
点击：
[NVRAM]不格式化下载，开机NVRAM恢复为默认值
[DESCRIPTION]
对任意代码进行少许修改，编译生成bin档，不格式化FAT下载，NVRAM数据被恢复为默认值，如开机需要重新校准
touchPanel。但校准数据，IMEI这些重要数据没有被恢复。
[SOLUTION]
该问题为重新下载BIN档后，第一次开机时Branch号与上次不同，发生BranchReset。
在问题在以前的版本上出现，如果是最新的拿到的版本，则不会有此问题。
具体确认此问题，可进一步通过Trace确认。开机NVRAM初始化过程中，会进入函数nvram_supplementary_check检测各种版本号是否发生变化，如Branch/Flavor的版本号等。在该函数的第一个if判断分支：
If((！nvram_supplementary_check_data_item(NVRAM_EF_BRANCH_VERNO_LID))||…….)
{
//该分支进入BranchReset，可加Trace确认是否进入该分支。
}
若确认发生此BranchReset现象，需要申请Patch。PatchID：MAUI_02395337
[NVRAM]连续调用ReadRecord读取NVRAM的数据出错的原因
[DESCRIPTION]
为什么在MMItask中连续调用ReadRecord读取NVRAM的数据（例如批量导出电话记录），会引起导致MMICirlQ溢出导致系统错误?
[SOLUTION]
在MMItask中连续调用ReadRecord，在ReadRecord函数中会先发送消息MSG_ID_MMI_EQ_NVRAM_READ_REQ到L4C，然后进入while(1)loop等待L4C返回的MSG_ID_MMI_EQ_NVRAM_READ_RSP消息，当等待到该消息后，ReadRecord会立即返回，当没有读到该消息后，会接收ExtQ的消息，并判断从ExtQ得到的消息是否处理还是写到内部队列，例如如果是MSG_ID_TIMER_EXPIRY消息，会写内部队列；按键消息会置标志位，不写内部队列；
由于是连续调用ReadRecord而且每次ReadRecord又比较耗时，所以读到很多记录时，在这段时间内势必很多有很多timer超时，发送超时消息到MMI,这时我们接收ExtQ的消息会接收到很多MSG_ID_TIMER_EXPIRY消息，然后不停地写到内部队列中，而内部队列中的消息又得不到处理，所以继续ReadRecord会导致MMI内部队列爆掉。在MMItask中连续调用WriteRecord也会有类似的情况发生。
此外，连续调用ReadRecord或WriteRecord会导致task内的其他消息得不到及时处理，例如按键消息，就会导致按键消息延后处理。
如若需在MMItask用ReadRecord进行批量操作，则可以用timercallback方式处理，让MMItask有时间去处理其他的消息。
[NVRAM]添加一个新的Cache BYTE项后，不格式化下载会死机重启
solution适用的SWversion:10.48之后
所有的MMICacheBYTE设置组成一个NV项
LID:NVRAM_EF_CACHE_BYTE_LID
大小：NVRAM_CACHE_SIZE//512/256
默认值：NVRAM_CACHE_BYTE_DEFAULT
CacheByte的添加(旧的方式10.32之前)：
1.在common_mmi_cache_config.c---->common_mmi_cache_byte[]中添加一项
2.在custom_mmi_default_value.h---->BYTEDATA枚举体中增加此LID
示例：
BYTE_ENTRY(SMS_CONCAT_MSG_REF_VALUE,//该BYTE的ID号
NVRAM_APP_PHNSET,//APP的ID号
NVRAM_CACHE_ID_RESERVED,
KAL_FALSE,//是否恢复出厂设置标志
"ByteCache",
0XFF),//默认值
而在10.48之后，CacheBYTE改用新的添加方式：在res文件中添加。若添加后，不格式化下载，需同时升级如下的两个
NV的版本号。
添加后，需升级版本号：NVRAM_EF_CACHE_BYTE_LID_VERNO;
还需同时升级：NVRAM_EF_MMI_CACHE_BYTE_KEY_LID_VERNO;
对于CacheSHORT、DOUBLE项与BYTE类似。
[NVRAM]restore factory流程
[Description]
Feature Phone上restore factory (恢复出厂设置)的 流程
[Solution]
（1）重启前
mmi_restore_proc 中的case MMI_ALERT_CNFM_YES:
--》 RstStartRestore();
--》mmi_restore_app_data
--》mmi_frm_reset_record
--》send_nvram_reset_req 会发送消息MSG_ID_NVRAM_RESET_REQ给nvram task来设置恢复出厂设置的标识
sys_cache[0]=KAL_TRUE，
这样具有NVRAM_ATTR_FACTORY_RESET属性的LID、RESTORE_FLAG为true的cache及具有NVRAM_CLEAN_FOLDER_FACTORY的文件夹会被清空。因此贵司可以将需要恢复的内容按要求添加这些属性。
--》 mmi_restore_app_callback_func 依次调用mmi_restore_app_callback[]数组中设置的call back函数，贵司可以在这里参照已有的callback加一些自己的call back来实现数据的清除，添加的位置请见用
mmi_restore_app_callback[]中的注释语句。
（2）重启后
在nvram_init()函数中会去判断sys_cache[0]标识位，如果为ture则调用nvram_reset_data_itEMS（）函数，第一个参数传的是NVRAM_RESET_FACTORY。
然后在nvram_reset_data_items（）函数中走如下分支：
case NVRAM_RESET_FACTORY:
{
…….
// 分别将具有restore factory属性的LID、cache等恢复成默认值
}
[DESCRIPTION]
对任意代码进行少许修改，编译生成bin档，不格式化FAT下载，NVRAM数据被恢复为默认值，如开机需要重新校准
touchPanel。但校准数据，IMEI这些重要数据没有被恢复。
[SOLUTION]
该问题为重新下载BIN档后，第一次开机时Branch号与上次不同，发生BranchReset。
在问题在以前的版本上出现，如果是最新的拿到的版本，则不会有此问题。
具体确认此问题，可进一步通过Trace确认。开机NVRAM初始化过程中，会进入函数nvram_supplementary_check检测各种版本号是否发生变化，如Branch/Flavor的版本号等。在该函数的第一个if判断分支：
If((！nvram_supplementary_check_data_item(NVRAM_EF_BRANCH_VERNO_LID))||…….)
{
//该分支进入BranchReset，可加Trace确认是否进入该分支。
}
若确认发生此BranchReset现象，需要申请Patch。PatchID：MAUI_02395337
[NVRAM]连续调用ReadRecord读取NVRAM的数据出错的原因
[DESCRIPTION]
为什么在MMItask中连续调用ReadRecord读取NVRAM的数据（例如批量导出电话记录），会引起导致MMICirlQ溢出导致系统错误?
[SOLUTION]
在MMItask中连续调用ReadRecord，在ReadRecord函数中会先发送消息MSG_ID_MMI_EQ_NVRAM_READ_REQ到L4C，然后进入while(1)loop等待L4C返回的MSG_ID_MMI_EQ_NVRAM_READ_RSP消息，当等待到该消息后，ReadRecord会立即返回，当没有读到该消息后，会接收ExtQ的消息，并判断从ExtQ得到的消息是否处理还是写到内部队列，例如如果是MSG_ID_TIMER_EXPIRY消息，会写内部队列；按键消息会置标志位，不写内部队列；
由于是连续调用ReadRecord而且每次ReadRecord又比较耗时，所以读到很多记录时，在这段时间内势必很多有很多timer超时，发送超时消息到MMI,这时我们接收ExtQ的消息会接收到很多MSG_ID_TIMER_EXPIRY消息，然后不停地写到内部队列中，而内部队列中的消息又得不到处理，所以继续ReadRecord会导致MMI内部队列爆掉。在MMItask中连续调用WriteRecord也会有类似的情况发生。
此外，连续调用ReadRecord或WriteRecord会导致task内的其他消息得不到及时处理，例如按键消息，就会导致按键消息延后处理。
如若需在MMItask用ReadRecord进行批量操作，则可以用timercallback方式处理，让MMItask有时间去处理其他的消息。
[NVRAM]添加一个新的Cache BYTE项后，不格式化下载会死机重启
solution适用的SWversion:10.48之后
所有的MMICacheBYTE设置组成一个NV项
LID:NVRAM_EF_CACHE_BYTE_LID
大小：NVRAM_CACHE_SIZE//512/256
默认值：NVRAM_CACHE_BYTE_DEFAULT
CacheByte的添加(旧的方式10.32之前)：
1.在common_mmi_cache_config.c---->common_mmi_cache_byte[]中添加一项
2.在custom_mmi_default_value.h---->BYTEDATA枚举体中增加此LID
示例：
BYTE_ENTRY(SMS_CONCAT_MSG_REF_VALUE,//该BYTE的ID号
NVRAM_APP_PHNSET,//APP的ID号
NVRAM_CACHE_ID_RESERVED,
KAL_FALSE,//是否恢复出厂设置标志
"ByteCache",
0XFF),//默认值
而在10.48之后，CacheBYTE改用新的添加方式：在res文件中添加。若添加后，不格式化下载，需同时升级如下的两个
NV的版本号。
添加后，需升级版本号：NVRAM_EF_CACHE_BYTE_LID_VERNO;
还需同时升级：NVRAM_EF_MMI_CACHE_BYTE_KEY_LID_VERNO;
对于CacheSHORT、DOUBLE项与BYTE类似。
[NVRAM]restore factory流程
[Description]
Feature Phone上restore factory (恢复出厂设置)的 流程
[Solution]
（1）重启前
mmi_restore_proc 中的case MMI_ALERT_CNFM_YES:
--》 RstStartRestore();
--》mmi_restore_app_data
--》mmi_frm_reset_record
--》send_nvram_reset_req 会发送消息MSG_ID_NVRAM_RESET_REQ给nvram task来设置恢复出厂设置的标识
sys_cache[0]=KAL_TRUE，
这样具有NVRAM_ATTR_FACTORY_RESET属性的LID、RESTORE_FLAG为true的cache及具有NVRAM_CLEAN_FOLDER_FACTORY的文件夹会被清空。因此贵司可以将需要恢复的内容按要求添加这些属性。
--》 mmi_restore_app_callback_func 依次调用mmi_restore_app_callback[]数组中设置的call back函数，贵司可以在这里参照已有的callback加一些自己的call back来实现数据的清除，添加的位置请见用
mmi_restore_app_callback[]中的注释语句。
（2）重启后
在nvram_init()函数中会去判断sys_cache[0]标识位，如果为ture则调用nvram_reset_data_itEMS（）函数，第一个参数传的是NVRAM_RESET_FACTORY。
然后在nvram_reset_data_items（）函数中走如下分支：
case NVRAM_RESET_FACTORY:
{
…….
// 分别将具有restore factory属性的LID、cache等恢复成默认值
}
666666