Re: Interrupt questions
Martin Husemann <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.arm |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jun 25, 2025 at 09:47:44AM -0400, Mouse wrote: > > Is it legal to call uprintf() inside an interrupt handler? > > I don't know. It might work enough of the time to be useful even if > it's not promised; I've used printf() on amd64 inside interrupt > handlers often enough. I don't know whether it's promised, but I've > found it works reliably enough to be a useful debugging tool. I don't > recall trying it on any ARM, much less something like your board, but > it might be worth investigating. > > > If not, is there another way to add traces? > > Sure. For example, I've had cases where printf introduces enough delay > to cause problems; I've dealt with them in various ways, such as by > allocating a ring buffer of logging events and putting my logs there. > You can print them from (eg) an every-tick callout or you can just > leave them there for postmortem debugging or some debugging interface > (such as an ioctl or a custom character special device).... printf() is OK in interrupt handlers, but it will cause timing issues. In cases like yours where I just wanted to know if an interrupt handler ever is called I have also used Debugger() calls - but make sure you have all watchdog timers disarmed before triggering that. If you need low latency logging you should set up a kernhist(9) for your device (like usbhist does for USB debugging). Martin