@@ -267,3 +267,27 @@ If you are measuring size using the right method and your program is still too
267
267
big then check out our section on optimizations.
268
268
269
269
> ** TODO** (resources team) add link to the optimizations section
270
+
271
+ # My program just halts without connected debugger. What am I doing wrong?
272
+
273
+ An embedded MCU will typically stop work working if exceptions (which is the MCUs
274
+ way of signalling special or abnormal events) occur which are not handled and
275
+ cleared, either by an exception handler or a connected debugger. The latter case is
276
+ especially interesting because there's a method of interacting with a connected
277
+ computer dubbed ` semihosting ` which will work iff a debugger is properly connected
278
+ and debugging software running and correctly set up. This method uses special
279
+ processor instructions (e.g. a service or breakpoint call) to alert the connected
280
+ system about input and/or output requests from the device. If no debugger is
281
+ available to handle such a situation, the system either wait indefinitely or
282
+ generate an even stronger exception which can only be cleared by a reset.
283
+
284
+ There're two common scenarios which cause such a lockup unintentionally:
285
+ - The use of semihosting as input / output channel, e.g. via ` cortex-m-semihosting ` crate
286
+ - A ` panic ` in the program with the ` panic-semihosting ` crate in use, however the
287
+ occurence of a ` panic ` means that the program is defunct anyway
288
+
289
+ Please note that examples may make use of the ` semihosting ` concept but this
290
+ should not be used in production setups due to the lack of connected debugger and
291
+ a host running appropriate debugging software. The use of a serial interface is
292
+ often a better choice. However if you just would like to see your example running
293
+ please make sure your setup is ready to deal with the ` semihosting ` requirements.
0 commit comments