[Sorry removed an in-between post to avoid confusion if you see the odd reply, as a few things weren’t quite correct].
Those fault conditions occur when the safety mechanism can’t perform a read from the temp sensor. It’s not a case of overheating, as that will still return a valid temperature. It returns -1 when it cannot successfully read the temp from the internal sensor. The temp reads will fail/be invalid during discharge event - the most often occurs due to rapid external or internal triggers normally.
If the -1 state gets latched, this normally means the read failed too many times in a row so the device “disabled” that temp sensor. The failsafe you are seeing is that to avoid the device overheating/being damaged due to a missing temp sensor reading.
You can call the “triggersafe” command to see if that forces a correct read. Basically the problem is attempting to read the temp sensor during a discharge event may cause a latched error. The “triggersafe” command helps avoid this (see page 48/49 of manual in ChipSHOUTER User Manual which briefly mentions this).
If you get the error - does it clear the error when you perform a soft reset (with ‘reset’ command)? If the error remains latched, it could be a problem on the temp sensor itself if it requires a hardware power cycle.
Normally you can get around the problem by adjusting the pulse width/voltage/etc. We’ve found various corner cases that cause odd behavior such as this.
Finally - there is a setting called absent_temp you can try. This setting specifies how long the temp sensor is invalid for before it flags an error. If the sensor is indeed latching to -1 that might not be enough, but increasing that value might give you time to detect it via the API and recover gracefully (assuming the soft reset works OK).
But as a first step I’d see if calling triggersafe in-between glitches works. Check the value of absent_temp and increase that too.
Let me know if that changes any behaviour!