1

We programmed a STM32L072, using, for the lower layers, the HAL lib generated from cubeMX.

Note that the "programming style" in my enterprise does not involve to include a watchdog in their embedded devices. No comment.

During one particular field test (out of many), the device stopped working (i.e.: screen freeze, and no response on the communication bus, but the PWM driver was working).

The device has been restarted and after a few minutes of work, the freeze happened again. This happened a few times before we arrived.

We plugged a JTAG/ST-LinkV2, and nothing changed on bus or screen. As soon as we unplugged the flasher, the device restarted working without a reset (we could have recognized a initialization pattern if it had happened).

  • I don't understand how JTAG specification could explain this behavior (i.e. the unfreezing)?
  • By the way, what can cause a freeze that can be unfrozen by a JTAG unplugging? Oscillator stopped? Auto sleeping modes? hardware breakpoint? software breakpoint? Interrupts disabled?

EDIT - Answer to comments and recap :

  • Not an oscillator cause because PWM is still working.
  • Software breakpoint? unlikely as none has been set before flashing the program.
  • Concerning interrupts, I think this is an interesting lead, but how can the JTAG change anything by unplugging it?
Guillaume D
  • 2,202
  • 2
  • 10
  • 37
  • Not sure this is on-topic on SO. – Clifford Apr 12 '19 at 11:18
  • 2
    Are you _sure_ there was no reset? As in, did you watch the /reset pin with a scope? That's the most likely explanation by far. Other explanations would be JTAG forcing a different MCU mode which in turn might affect certain registers. And also sleep/freeze modes. I've encountered such rare bugs in the past when the MCU would only work with debugger attached. However I know too little of the various modes on STM32 to give an answer. – Lundin Apr 12 '19 at 11:35
  • We are sure no reset happened as there was not visible init pattern and the back-on-business (bus messages) timing would have been waaaaaay more longer in case of a reset/reinit. We didn't watch the reset pin with a scope, this is the next step if the problem reappears. thanks – Guillaume D Apr 12 '19 at 11:50
  • 1
    The JTAG involvement is curious, but how could the code have froze in the first place, especially in a manner that can then be unfrozen without a reset? Is it possible that the code was stuck in a continuously asserted interrupt? What interrupt sources are enabled? Are any of the interrupts level-sensitive? – kkrambo Apr 12 '19 at 12:13
  • Your edit was unnecessary - SO is not a discussion forum. That stuff belongs in comments, either here or against the answers you are referring to. Moreover your point about software breakpoints misses the point that they may explicitly appear as instructions in the code rather than being set by the debugger. – Clifford Apr 16 '19 at 13:35
  • Just a guess: Could the system have been in one of the stop or sleep modes? AFAIR there are two ways of entering these states, wait for interrupt (wfi), and wait for event (wfe), where the latter's behaviour depends on what is configured to be an event. Assuming some interrupts become pending, your system should wake up on its own with wfi, but may not do so from wfe. According documentation cited in [this question](https://stackoverflow.com/questions/27188807/arm-sleep-mode-entry-and-exit-differences-wfe-wfi), wfe may wake up on debug, but the debugger may hold the processor until disconnect. – PaulR May 06 '19 at 12:33

1 Answers1

2

Hard to determine without knowing more about your software. If the PWM is running, clearly the oscillator has not stopped. It sounds like the code may have an embedded software breakpoint instruction. The on-chip debug does not by default stop peripheral clocks when it hits a break-point.

Such instructions should be guarded to only block when the host debugger is attached (i.e. the debugger software, not just the physical JTAG hardware), e.g: 

if (CoreDebug->DHCSR & 1) __BKPT(0);

If the breakpoint is not conditional on the debugger, the processor will halt with nothing to restart it (other than a watchdog, preferably the independent watchdog, because the windowed watchdog can be configured to have its clock stopped when a breakpoint is hit).

When a debugger is detached the break-point will be released, which may be what is happening here.

Clifford
  • 88,407
  • 13
  • 85
  • 165