PIC32具有高温

您为选定的系统时钟提供了多少个闪存等待状态？我有一个问题与PIC32 MZ运行200兆赫系统时钟。在热室测试期间，系统偶尔会将CPU发送到异常处理程序。根据数据表，2个闪存等待状态是所有需要在200兆赫。然而，当等待状态增加到4时，问题就消失了。对于MX族，我认为是PICMW字段在PICM寄存器中设置PFM等待状态。



      以下为原文

    How many Flash wait states do you provide for the chosen system clock? I had an issue with PIC32MZ running 200MHz system clock. The system would occasionally send the CPU to an exception handler during heat chamber testing. According to the datasheet, 2 Flash wait state is all it needs at 200MHz. However, when the wait state is increased to 4, the problem goes away. For the MX family, I think it is PFMWS field in the CHECON register that sets the PFM wait state.

HI AsCH0866，关于您的评论，我有：//数据存储器SRAM等待状态：默认设置＝1；BMXCONBITS.BMXWSDRM＝1；/Flash PM等待状态：MX闪存运行在2个等待状态@ 80 MHz校验位。PFMWS＝2；//预取高速缓存：启用预取可缓存的PFM指令校验。PREFIN＝0；I WI；尝试将等待状态增加到4。在这些条件下，一些图片可以开始重置，而其他图片却不能重置？我做了一些测试，在一些图片中，可能是在其中的一些时候，当它们开始重置，经过一段时间的重置之后，在某个点就像代码停止运行一样。PIC32连接到TFT，并且程序甚至不再重置。它停下来了，就像PIC32完全死了一样。然后，恢复环境温度，它又开始工作了。



      以下为原文

    Hi aschen0866,
About your comment, I have:
// Data Memory SRAM wait states: Default Setting = 1; 
BMXCONbits.BMXWSDRM = 1;
// Flash PM Wait States: MX Flash runs at 2 wait states @ 80 MHz
CHECONbits.PFMWS = 2;
// Prefetch-cache: Enable prefetch for cacheable PFM instructions
CHECONbits.PREFEN = 0;
 
I will try to increase wait states to 4. It could be possible that, under these conditions, some PICs starts to reset and other ones not?
 
Doing some tests I faced how, in some PICs, maybe in a couple of them, when they start to reset, after some time reseting, in some point is like if the code stop running. PIC32 is connected to a TFT and, program even didnt reset anymore. It was stoppped, like if the PIC32 was totally dead. Then, recovering ambient temperature, it started to work again.
 
Regards,
 

嗨，PICS都被加到+85 C，有时上面是永久操作。所以如果你看到重置的话，很可能是HW或SW的原因。首先你必须确定重置的原因（如果可能的话），也就是说使用一个异常处理器来决定重置（看门狗，非法内存）。尝试实现一个非常简单的SW环路，它触发一个LED并增加温度，以查看应用程序本身是否是重置的原因，这将有助于更精确地确定根源。



      以下为原文

    Hi,
The PICs are all garanted up to +85C and sometimes above for permanent operation.
So if you see resets there is most probably a HW or SW reason.
At first you must identify what causes the RESET (if possible), i.e. determine using an exception handler what caused the reset (watchdog, illegal memory access,...).
Try to implement a very simple SW loop which toggle an LED and increase the temperature to see if the application itself is the reason for the resets this will help to pinpoint more precisely the rootcause.
Regards
 

嗨，RISC，谢谢你的回复。正如我在第一篇文章中评论的那样，复位管理异常处理程序的原因是WDT。在异常处理程序中，我得到“数据总线错误”，有时“指令总线错误”（异常处理程序中的第6和7号异常）。但是我不认为看门狗的重置是正确的，因为当你调试和跟踪异常时，代码会跳进非逻辑点，每次都在代码的一部分，没有理由认为，标准温度SW工作良好，并且在高温下SW变坏。实际上，如果SW重置是原因，为什么它在几小时后发生，然后当它开始重置时，程序甚至不能启动？我理解一个看门狗例外，在我的代码中有“一些特性”，当“特性”发生时，SW被堆叠起来，但是这次，SW甚至不能在跳的时候开始“做事情”。这个WDT重置我很早以前就用坏的VCAP设计。PIC，经过一段时间（标准温度和条件，即使是一个简单的回路）崩溃和复位。如果你驳回了例外，PIC说WDT，而且，异常跳转在不合逻辑的地方，线路和地址。这是一个不稳定的行为，通过PIC通过VCAP电源。我确信这次是另一件事（10uF 25V 1206，低ESR与0，1uf 0603并行），我只是评论，解释WDT重置可以是“假的”，至少在我的经验。我不知道，只是一个想法。我有点迷茫。阿申说的逻辑是因为温度会影响PIC的行为，而“闪光等待”会受到影响（至少我认为他是对的）。我要试试。我在RAM有一些功能，我也会把它们移到程序存储器上。也许这是一件愚蠢的事情，但我可以试试。非常感谢RISC的支持，



      以下为原文

    Hi RISC,
 
Thanks for the reply. As I commented in my first post, cause of reset managing exception handler says WDT. In the exception handler I get "Data bus error", and sometimes "Instruction bus error" (exceptions number 6 & 7 inside exception handler). But I dont think this reset by watchdog is true because when you debug and track the exception, code it jumps in illogical points, each time in one part of the code and there is no reason to think that, with standard temperatures SW works fine, and with high temperatures SW becomes bad. Actually, if SW reset is the cause, why it happens after some hours and then, when it starts the resets, program can't even start? I understand a Watchdog exception as someting with "some characteristics" in my code and, when that "characteristic" happen, SW is stucked, but this time, SW can't even starts "to do things" when it jumps. 
 
This WDT resets I faced long time ago with bad Vcap design. PIC, after some time (standard temperatures and conditions, even with a simple loop) crashed and reset. If you debbuged the excepcion, PIC said WDT, and again, exception jumped in illogical places, lines and addresses. It was an unstable behavior from PIC through VCap power. I'm sure this time is another thing (10uF 25V 1206, low-esr in parallel with 0,1uF 0603), I just comment that to explain that WDT reset can be "fake", at least in my experience. 
I don't know, just a thought. I'm a bit lost.
What aschen said has logic because temperature can have an impact in PIC behavior and the "flash waits" can be affected (at least I think he is right). I'm going to try it.
I have some functions located in RAM, I will move them to program memory as well. Maybe this is a stupid thing, but I can try it.
 
Thanks a lot RISC for the support,
 
 

你是真的使用WDT，还是你能禁用它？要知道，WDT可能在高温下运行得快一点，所以如果你只是在低温下搔痒得足够快，那么它在高温下可能会太慢。



      以下为原文

    Are you actually using the WDT, or could you disable it?
Be aware, the WDT probably runs a bit faster at high temperatures, so if you are only just tickling it fast enough at low temps, then it could  be too slow at high temps.
 

嗨！好建议。我认为有时在WDT明确的行动在我的代码，我从来没有想到在“速度变化”之间的低温和高温。我正在使用软件WDT，并清除它的每个应用程序状态机循环（嗯，在主应用程序状态机中，因为有很多应用程序状态机）。这个时间应该短，MS或100ms。关于WDT，我实际使用它，我认为必须启用。我不得不说，看门狗时间被配置…长时间（4秒，我想，我完全不记得WDT PS值）。但是，如果这是原因，我总是会得到一个“明确”的中断例外，在插入点，对不对？在我的例子中，我每次都把非法逻辑地址排除在一个地方，不管怎样，谢谢你的建议，我会用一种不同的方式管理WDT在这些有问题的多氯联苯中来研究这一点。甚至禁止测试。



      以下为原文

    Hi qhb,
Woah! Good advice. I thought sometimes in the WDT clear action in my code, my I never thoght in the "speed change" between low temperatures and high temperatures. I'm using software WDT and clearing it each app-state machine loop (well, in the main app-state machine because there are many app-state machines). This time should be short, ms or 100ms. About WDT, I'm actually using it, I think must be enabled.
I have to say that, watchdog time is configured... with long time (4 seconds I think, I dont remember exactly the WDT PS value). But, if this it would be the cause, I would always get a "clear" interrupt exception in the stucked point, right? In my case I get each time exceptions in illogical addresses and each time in one place.
 
Anyway, thank you for the advice, I will manage WDT from a different way in one of these problematic PCBs to investigate this point. Even, disable it for the tests.
 
Regards,

也许你应该把你的MCLR示意图以及部分NO的旁路帽？从第一篇文章中似乎有点不清楚，你是用350C来删除旧部分吗？如果你真的要用350C来把新部分放在黑板上，我会怀疑那不是很好。



      以下为原文

    Maybe you should post your mclr schematic as well as part no's for bypass caps?  
 
It seems a bit unclear from the first post, are you using 350ºC only to remove the old part?  If indeed you would be using 350ºC to put the new part on the board, I'd suspect that isn't very good.

嗨，弗里森，我附了SCH图像：我不能上传图片，我不知道为什么。我得到“许可被拒绝”。是的，我就是这样做的。首先，用350℃的空气喷嘴去除旧的PIC，第二，用350℃的空气喷嘴在PCB上焊接新的PIC。我认为PICS也会因为这个动作而被损坏。我还必须说，增加闪存等待状态，其中一个“故障中的PCB”不再被重置。其余的，的确如此。



      以下为原文

    Hi friesen,
I attached the sch image:
I can't upload image, I don't know why. I get "Permission denied".
 
https://imgur.com/a/pZSto
 
About PIC replacement. Yes, I'm doing exactly that. First, air nozzle with 350ºC to remove the old PIC, and, second, air nozzle with 350ºC to weld the new PIC on the PCB.
I think PICs can be damaged as well because of this action.
I have to say as well that, incresing flash wait states one of the "PCBs in trouble" didn't reset anymore. Rest of them, it did.
 
Regards

未显示图像



      以下为原文

    image is not shown

为我工作。



      以下为原文

   
Worked for me.
 

啊，是的，在链接被放置之后：（在初稿中没有）



      以下为原文

    ah yep, after the link has been placed :) (in first draft it was not)

即使你在环境温度范围内，你可能正在做一些导致高功率耗散和推动结温度过高的事情。THETAJ-A的范围在30到50℃之间，是否有任何I/O采购或下沉过大的电流，可能由于外部组件行为而随温度变化？



      以下为原文

    Even if you are within the ambient temperature range, you may be doing something that is causing high power dissipation and pushing the junction temperature too high. The Thetaj-a is in the range 30 - 50 ºC/W.
 
Do you have any I/O sourcing or sinking excessive current, maybe varying with temperature due to external component behaviour?

嗨，克罗斯兰，我想不是。我有：-I2C + 2 SPI+ 1 UART - 1 PWM（背光）- 5个数字输入（使用中断）。我已经测量了PICS电源中的电流，它似乎还行，即使在高温时刻。我认为PICS必须被损坏。我没有这些问题，不止一个图片，但所有测试，和建议从你我说，说，问候，



      以下为原文

    Hi crosland,
 
I think not. I have:
- I2C + 2 SPIs + 1 UART
- 1 PWM (backlight)
- 5 digital inputs (using interrupts).
 
I have been measuring the current in PICs power and it seems OK, even in high temperature moments.
I think PICs must be damaged. I didn't have these problems with more than one PIC, but all tests, and suggestions from you I'm following, say that.
 
Regards,

你的系统时钟运行在什么地方？我一直都在对冲我的时钟，大部分来自FPGA的问题，但是你可以在这里得到一些东西。如果你在100MHz，部分只是在85摄氏度，我从来没有相信那些最大额定值。如果你能容忍一个较慢的系统时钟（95MHz？）你可以自己买5摄氏度…如果你能下降到80MHz，你将被评为+105C（PyHTTP://WW1.MICCHIP.COM/DeLoSs/En/DeVICECD/6000 1185G.PDFTABLE 31 -1）。



      以下为原文

    What's your system clock running at?  I've always hedged my clocks a bit, mostly from FPGA issues, but you could have something here.  If you are at 100MHz, the part is only rated for that at 85C, and I've never trusted those max ratings.  If you can tolerate a slower system clock (95MHz?) you may buy yourself 5 Celsius...  If you can drop to 80MHz you will be rated up to +105C (per http://ww1.microchip.com/downloads/en/DeviceDoc/60001185G.pdf table 31-1)

嗨，你确定：1，你正确地初始化时钟系统2/缓存/等待状态，假设没有硬件问题，可能是由于错误的中子化，芯片会随着温度上升而上升。检查这一点的一种方法是做一个简单的循环，用一个LED闪烁一个LED。简单的延迟和不初始化时钟系统或高速缓存。处理器将运行非常缓慢，但它不应该挂在你增加温度加热器。



      以下为原文

    Hi,
Are you sure that :
1/ you initialize correctly the clock system
2/ the cache / the wait states
Assuming that there is no hardware issue, it could be that the chip, due to improper inialization, hungs up as temperature goes up.
One way to check this is to do a simple loop which blinks an LED using a simple delay and without initializing the clock system or the cache.
The processor will run very slowly but it should not hang as you increase temperature
Regards
 

HangRangBo和RISC，Grimb:PIC运行在80MHz。我试图减少FREQ到64 MHz，在坏的PCB（PICS）中，结果是相同的，也许，它们需要更多的温度（更多的C）来掉/复位。这里是我的系统时钟配置：/**DVCFG0***/*Prima-TracMig-Cuffg调试。P＝Off-TraceMac配置，CPW= Off/**DeFCFG1***/A*PrimaMatlab配置FFONC＝PrpLLL PrimaMac配置文件FSCONEN＝Off-PrimaAsCOFIG-ISOO＝α-PrAPMA配置文件POSCMOD＝XT* 2×PrimaMac配置PWFIG FWDTENN＝PrimaTracMig-COFIGIG FWDTWISZZ＝WiSZZ25/***DEVCFG2***/*PrimaFILIGIGIF FPLLIDEV＝DIVIO2O* PrimaMac配置语言FPLLMUL= Mulr20My PrimaMatg配置文件FPLLoDIV= DIVIG1πPrimaMac配置文件WDTPS＝PS8192αFIG USERID＝0xFFFFα-PrRAPSFEL＝PrReSythy7，TraceMy7，PrdL1WORE＝α-PrimaMaungIOL1WORE＝on PrimaMaMatg配置FuBidio＝Off-Prima配置文件FVBUSONIO= FU//L//L//Loop/Grand。E状态为“高条件”。等待状态被配置为4（AsCH0866的建议）。我认为稳定性已经提高（至少在一个PCB中）。我有预取高速缓存禁用。我做了一些测试时钟FRQ（示波器），它似乎工作良好，即使在“高的条件”。我每天花在研究这个问题，我想更难，我有一个HW问题与这些问题。我想他们一定是被损坏了。谢谢，



      以下为原文

    Hi grambo and RISC,
 
grambo:
PIC is running at 80Mhz. I tried to reduce the freq to 64Mhz and, among the bad PCBs (PICs), the result is the same, maybe, they need more temperature (a few more ºC) to fall down/reset.
 
RISC:
Here is my system clock config:
 
/*** DEVCFG0 ***/
#pragma config DEBUG = OFF
#pragma config JTAGEN = OFF
#pragma config ICESEL = ICS_PGx2
#pragma config PWP = OFF
#pragma config BWP = OFF
#pragma config CP = OFF
/*** DEVCFG1 ***/
#pragma config FNOSC = PRIPLL
#pragma config FSOSCEN = OFF
#pragma config IESO = ON
#pragma config POSCMOD = XT
#pragma config OSCIOFNC = OFF
#pragma config FPBDIV = DIV_1
#pragma config FCKSM = CSDCMD
#pragma config WDTPS = PS8192
#pragma config FWDTEN = OFF
#pragma config WINDIS = OFF
#pragma config FWDTWINSZ = WINSZ_25
/*** DEVCFG2 ***/
#pragma config FPLLIDIV = DIV_2
#pragma config FPLLMUL = MUL_20
#pragma config FPLLODIV = DIV_1
#pragma config UPLLIDIV = DIV_4
#pragma config UPLLEN = OFF
/*** DEVCFG3 ***/
#pragma config USERID = 0xffff
#pragma config FSRSSEL = PRIORITY_7
#pragma config PMDL1WAY = ON
#pragma config IOL1WAY = ON
#pragma config FUSBIDIO = OFF
#pragma config FVBUSONIO = OFF
//
 
I think is initialize in the right way, in fact, it works with "normal" conditions, and mostly, it works fine with "high conditions".
Wait states are configured to 4 (aschen0866's suggestion). I think stability has been improved (at least, in one PCB).
I have Prefetch-cache disabled.
I did some testings measuring the clock freq (oscilloscope) and it seems to work fine, even with "high conditions".
 
Each day I spend studying this issue, I'm think harder that I have a HW problem with these problematic PICs, I think they must be damaged.
 
Thank you,

“焊工喷嘴”是什么意思？我真的希望它与焊接设备无关：“你是指热空气还是热气体？”那么，你用多长时间来焊接（不焊接？）新PIC？温度控制有多精确？你应该真正使用底部热量，使PCB和焊点接近熔点，然后快速爆炸的顶部热，为最终重新流动。



      以下为原文

    What exactly do you mean by "welder nozzle"? I REALLY hope it has nothing to do with welding equipment :)
Do you mean hot air or hot  gas?
So how long are you applying the heat to solder (not weld!) the new PIC?
How accurate is the temperature control?
You should really be using bottom heat to get the PCB and solder close to melting point then a quick blast of top heat for the final re-flow.

在一些语言中，他们使用“焊接”这个词，在那里英语使用者会使用“焊接”这个词。假设他们使用的是热空气喷嘴，仍然有可能损坏芯片。在手工焊料中，您不能获得适当的焊接温度和时间。芯片需要机器焊接才能确定。但由于其他问题，芯片仍可能在董事会上过热。在这种情况下，内部温度传感器可能非常有用。



      以下为原文

    In some languages they use the word "weld" where an English speaker would use the word "Solder". Assuming they are using a hot air nozzle it is still possible they damaged the chip. You can not get the proper solder temperatures and times in a hand solder. The chips would need to be machine soldered to be sure. But it is still possible the chips are overheating on the board due to other issues.
The internal temperature sensor may be very usefully in this case.