This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您好,
微控制器(F2.8377万D)似乎卡在bootrom代码中。 这不是正常现象,只能通过应用程序中的监视程序重复重置来重新创建。 一旦微控制器进入这种“僵尸”状态,我就能够连接JTAG (经过修改的凝胶,不会更改CPU状态)并读取寄存器并找到它被卡住的地址(0x3fe2ee)。我们可以看到它在分支无条件地卡在同一位置,实际上是1。 连接CPU寄存器和反汇编视图中的bootrom代码快照。 问题
注册内容:/CFS文件/__key/communityserver-discussions-组件文件/171/CCS_5F00_Export_5F00_PeripheralMap.txt
启动引脚(GPIO72和GPIO84)通过10kOhm电阻器连接到3.3V,不用于任何其他用途。 10千欧是否太弱?
如果我可以将问题中描述的商品标记为unit_A,则我们还有两个商品处于相同情况。
unit_B:似乎卡在0x3FEFB3地址,并在两个指令之间循环。
从寄存器中,看门狗被禁用。
我们有意将GPIO84接地,将台式装置置于"等待"模式。 已连接JTAG,并可以确认其卡在 0x3fe2ee处(就像在原始问题中一样),我们还可以看到监视器已禁用。
在这些主板中,OTP启动配置未使用,仅留空(将仔细检查)
问题:
Sandeep,
是,在等待引导时禁用了监视程序。
电阻值取决于 主板上预期的噪音类型。 10kOhm 灵敏度值可能不足以适应非常嘈杂的环境。
您是否检查过GPIO 72/84值以确保其确实是由于错误的GPIO值 ?
此致,
Vivek Singh
Vivek,
您能否详细说明您希望我在GPIO 72/84上检查的内容。 是否要我检查GPADAT寄存器? 我怀疑它将显示为1,将进行检查以确定。 BootROM可能由于 瞬态而读数较低。 bootrom是否将这些引脚采样值存储在ram中? 它可以确认进入"等待"模式的原因。
这种情况并不是每次都发生,我们必须运行一个周期周期,定期复位,它将在某个时刻进入这种状态。
谢谢!
Sandeep
Sandeep,
我想知道10k拉电阻器是否太弱。 你们已经试过1K上拉电阻器了吗? 我们可以更改引导模式引脚,但无法在没有引导模式引脚的情况下直接引导至闪存。
此外,是否已确保启动引脚处于正确状态至少1.5毫秒?
此致,
Manoj
Sandeep
已编辑:另一个要考虑的选项是对OTP位置进行编程,以便对两个引导GPIO中的每个使用相同的GPIO。 这基本上只需要您使用一个启动销,然后对其进行强力拉拔。 这将导致获取引导模式。
此致
Chris
大家好,
该问题尚未解决,我们尝试了很多事情。我们尝试了1K电阻器,但问题仍然会发生。 此外 ,我们有时必须运行超过36小时的循环测试来重新创建,这使得诊断非常困难。 在一个实例中,问题可能在几分钟内重新出现,但一旦我们将bootloder (我们的引导加载程序代码在闪存中运行)更改为其他版本进行测试并恢复,因为此后无法在该设备上重新创建。
我们从示例中获取了biky应用程序并启用了看门狗,因此它会不断重置,在5个设备上运行超过15小时,并且无法重现问题。 到目前为止,我们可以看到重复下载固件(然后重置看门狗)的测试似乎导致了此问题。 闪存擦除/程序中是否有任何可能导致此问题的原因?
我们正在设置几个单元,将此问题作为测试场至少出现一次,并将其用于运行测试,这样我们就可以增加重新出现问题的机会。
谢谢!
Sandeep
您好,Manoj,
1)您是否在应用程序代码中使用引导模式PIN? 否,引脚被拉至10K,不连接或用于任何用途
2)您是否已尝试在应用程序代码中不使用引导模式PIN? 引导模式引脚配置为使用上拉进行输入
3)看到问题时闪存是否被擦除? 我必须检查笔记,然后返回。
4)一旦您发现问题? 您是否能够重复生产? 需要很长时间,有时需要24小时的固件下载重复循环,每分钟一次。
我们在两个引导选择GPIO引脚上有范围,并捕获了bootrom选择不同模式的实例。 轨迹是实线,没有任何故障,所以3.3V导轨是实线的。
Sandeep