完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
|
PIC32MZ2048EFM144MPLAB-X v3.35XC32v1.42我们正在开发软件，以支持PIC32MZ-EF启动器套件电路卡上的实时更新，同时我们正在制造应用程序专用硬件。午睡。所有操作都按预期进行，只是我们无法对DEVCFG0进行编程以匹配预期的配置：当使用Row或Quad-word编程（即，使用运行时自编程（RTSP），而不是JTAG）时，JTAGEN将不能清除。从那个引导闪存库引导（PIC32MZ–EF数据表明确指出在配置寄存器上不使用Word编程）。其他帖子提到，当通过JTAG编程时，在硬件中禁止清除JTAGEN。使用在线串行编程器，我们可以在编程初始映像时根据需要设置JTAGEN=0(OFF)，但是Live Update需要通过RSTP软件对配置寄存器进行编程。是否有人成功地通过RTSP清除了JTAGEN，或其他PIC32MZ部件？
0
|
|
相关推荐
15个回答
|
|
|
你如何测试程序设计的结果？高速缓存会妨碍你吗？
|
|
|
|
|
|
只有当JTAG被用于调试/编程时，我才看到JTaGEN不可写。例如，我曾经在JTAG上从一个设备到另一个设备复制引导加载程序做了一个小项目。JTAGEN位在源中是明确的，但是在目标中它最终被设置了。但是如果在运行时执行RTSP（没有调试），它应该可以工作。
|
|
|
|
|
|
我不清楚为什么在编程时不能清除DEVCFG0.JTAGEN位。但是如果您打算禁用JTAG，那么在运行时尝试清除CFGCON.JTAGEN。只要设置了DEVCFG0.JTAGEN熔断位，就可以写入这个CFGCON.JTAGEN字段，这实际上是您的情况请确保在将任何东西写入CFGCON寄存器之前打开。
|
|
|
|
|
|
@Totem：好建议。我对PIC上的JTAG还不够熟悉，不知道是否能够完全解决我们所关心的问题，即所加载代码的IP的安全问题。我认为JTAG程序员/调试器可以在我们的固件清除CFGCON.JTAGEN之前读出内存内容，这是我们想要防止的。您的建议确实给了我在重新编写DEVCFG0之前尝试清除CFGCON.JTAGEN的想法——唉，将CFGCON.JTAGEN从1更改为0不允许DEVCFG0.JTAGEN被清除。我们刚刚收到我们新硬件板的第一篇文章，所以我将提出那些，看看这个行为是否重复，或者它是否与这个Starter Kit板隔离，并报告回来。
|
|
|
|
|
|
DEVCFGS是程序时间保险丝设置，CFGCONs是运行时系统配置寄存器。那么，这意味着什么？程序时间保险丝值将反映在运行时系统配置，但反之亦然！因此，当您在CFGCON中更改值时，不能期望DEVCFG被修改。
|
|
|
|
|
|
所有PIC32芯片简化JTAG超过ICSP编程，如果您清除JTAGEN，它不会被禁用。因此，在清除JTAGEN时没有附加的安全性。
|
|
|
|
|
|
我也面临着JTAGEN配置位相同的问题。意外地打开这个位会导致4个引脚在JTAG模式下工作。任何地方都不能从Bootloader中设置这个位。好的，这将是一个新的问题，在一个解决方案的勘误…我的主要问题是，我已经花了几乎3天，以实现正确的配置字写作。没有文档描述如何完成它，但是每一个文档章节都引用了其他文档章节，在阅读了50页之后，我仍然不知道它应该如何工作。这个项目是在最后期限，我必须再做一个工作来处理一些事情。PIC32 Flash编程规范，CH.19.1.1）提到了一个配置不匹配RESETF我写这个内存区域…但是它没有重置…它会重置下一个硅版本吗？即使页面擦除也会重置吗？我的引导加载程序将在1年后继续使用硅版本吗？这些配置位受到保护，它们只能在电源周期中写入一次。这是真的吗？每次重置后我都可以写。Bootloader是否要进行电源周期以确保正确的更新？？？？
|
|
|
2020-4-28 09:25:55
评论
|
|
|
我们已经在自定义硬件（不同的PIC包：PIC32MZ2048EFM100）上验证了相同的行为（DEVCFG0.JTAGEN不清楚为“0”）。@NorthGuy：为了澄清，您是说清除CFGCON.JTAGEN（我可以理解）没有增加安全性，或者清除时没有增加安全性。DEVCFG0.JTAGEN（我会感到惊讶）？
|
|
|
|
|
|
我查看了我们的内部设计文档，发现Flash控制器（负责Flash编程的模块）故意阻止清除该位（DEVCFG0.JTAGEN）。我还测试了一些东西，发现如果该位开始是清晰的，那么页面将被擦除。D（例如，Bootloader更新），该位现在将被设置并且不能被清除。现在，EJTAGBEN可以被清除。那会做你想做的吗？如果需要其他功能的引脚，则需要清除CFGCON.JTAGEN。JTAG通常是那些引脚上的最高阶函数，因此必须关闭它们才能禁用它们。
|
|
|
|
|
|
在清除DEVCFG0.JTAGEN时不增加安全性。同样的功能可以通过ICSP获得。
|
|
|
|
|
|
拉里.斯坦格：非常感谢！你还可以检查“配置错配重置”和“配置字保护”的工作原理和工作原理吗？
|
|
|
2020-4-28 10:08:20
评论
|
|
|
很好地理解了DEVCFG0.JTAGEN位保持高位的根本原因。谢谢您！我们希望防止从一个已部署单元读取程序内存。我能找到的关于EJTAGBEN的唯一信息是在PIC32MZ-EF数据表中，它简明地陈述：EJTAGBEN：EJTAG引导启用位1=普通EJTAG功能0=简化EJTAG功能0=EJTAG功能0=0实现/支持我们的目标吗？其他地方有这种记录吗？更广泛的问题是：什么是必要的配置设置，以防止程序内存读取？
|
|
|
|
|
|
我正在寻找比特被进一步记录的地方。在图像技术文档中，它被描述为“EJ_.bleProbeDebug”，并且从DEVCFG0中的EJTAGBEN位反转。基本上，它禁用了调试器对核心的访问。在48节FRM（内存访问和许可）中，它这样说：“为了防止调试器在引导代码建立保护方案之前访问受保护区域，通过设置EJTAGBEN（DEVCFG0<30>30>）来限制EJTAG功能。;)位到'0'，阻止探测从EJTAG引导。“DEVCP0中的CP位用于保护闪存。如果调试器连接到处理器并试图读取Flash，那么请求将被拒绝。访问某些区域。
|
|
|
|
|
|
Layy.Stay:谢谢你提供的额外信息。从提供的内容来看，JTAGEN位在代码安全性方面似乎并不重要。概括地说：我们希望防止任何外部工具回读所有程序和引导内存。我们还希望防止外部工具（尽管允许RTSP）对任何内存进行重新编程，除非整个内存被擦除。我们将这些配置位设置如下：DEVCP0.CP=0//Code.on启用DEVCFG0.EJTAGBEN=0//Reduced EJTAG functionailtyDEVCFG0.JTAGEN=01//JTAG被启用（要求为1）DEVCFG0.DEBUG=11//Debugger被禁用（即使当CP=0时是冗余的）。如果有人知道我们忽略的安全配置设置，请指出来。谢谢！
|
|
|
|
|
|
我也遇到过这个问题，花了两天时间去寻找问题！谢谢你的报道。有没有解释为什么不可能对这个钻头编程？这确实需要在数据表中突出。-鲍勃
|
|
|
|
|
只有小组成员才能发言，加入小组>>
5238 浏览 9 评论
2028 浏览 8 评论
1950 浏览 10 评论
请问是否能把一个ADC值转换成两个字节用来设置PWM占空比？
3204 浏览 3 评论
请问电源和晶体值之间有什么关系吗？PIC在正常条件下运行4MHz需要多少电压？
2253 浏览 5 评论
777浏览 1评论
666浏览 1评论
有偿咨询，关于MPLAB X IPE烧录PIC32MX所遇到的问题
595浏览 1评论
PIC Kit3出现目标设备ID(00000000)与预期的设备ID(02c20000)不匹配。是什么原因
676浏览 0评论
576浏览 0评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1773
淘帖
1988
