panic when Interrupts enabled in RP Pico

[bmentink]

I am getting: panic: runtime error: nil pointer dereference .. whenever I enable interrupts in my test code.
The interrupt handler does not seem to be doing anything .. (do println statements work in the handler?)

Is there any way to find where the Panic is occurring? Is there a good example for using Interrupts on the Pico?

I am essentially doing the following to use interrupts:

//Interrupt pin:
comp_A.Configure(machine.PinConfig{Mode: machine.PinInputPullup})

//Set interrupt (presume interrupt is now enabled)
comp_A.SetInterrupt(machine.PinRising, handlerA_rising)

// Handler
func handlerA_rising(p machine.Pin) {
comp_A.SetInterrupt(0, nil)) // Disable interrupt !! not sure if you have to disable interrupt to ensure another one does not happen in this handler ???
///.... do stuff
}

Any idea's

[sago35]

@bmentink
The following example appears to be working correctly.

https://github.com/tinygo-org/tinygo/blob/release/src/examples/pininterrupt/pininterrupt.go

Note that you need to add the configuration for rp2040.

//go:build rp2040
// +build rp2040

package main

import "machine"

const (
	buttonMode      = machine.PinInputPulldown
	buttonPinChange = machine.PinRising
)

[bmentink]

@sago35

Yep, that example works. Guess there is something amiss in code that is called by the interrupt ... without further info from the "panic" I am struggling with how to debug this ...

I have plastered error handling all over the place, but none gets hit ... just the panic ..

Can you answer my other question?
I.E Can you have println statements in a interrupt routine?

[bmentink]

With some more investigation, I am getting: machine: no channel available for pin interrupt error..

I have the following code setting up the interrupts .. ( pe() is a print error function wrapping the calls.)

// These functions setup the comparator interrupts
func (d *Device) bemf_B_falling() {
	pe("setupBF", d.comp_B.SetInterrupt(machine.PinFalling, d.handlerB_falling))
}

func (d *Device) bemf_A_rising() {
	pe("setupAR", d.comp_A.SetInterrupt(machine.PinRising, d.handlerA_rising)) // enable this interrupt, disable the rest
}

func (d *Device) bemf_C_falling() {
	pe("setupCF", d.comp_C.SetInterrupt(machine.PinFalling, d.handlerC_falling))
}

func (d *Device) bemf_B_rising() {
	pe("setupBR", d.comp_B.SetInterrupt(machine.PinRising, d.handlerB_rising))
}

func (d *Device) bemf_A_falling() {
	pe("setupAF", d.comp_A.SetInterrupt(machine.PinFalling, d.handlerA_falling))
}

func (d *Device) bemf_C_rising() {
	pe("setupCR", d.comp_C.SetInterrupt(machine.PinRising, d.handlerC_rising))
}

I get these errors, when they are executed: (They are executed in the sequence above)

setupBF machine: no channel available for pin interrupt
setupAR machine: no channel available for pin interrupt

How am I filling up channels?
As you can see, I am wanting a handler for each of the edges, is this the correct way to do it?
These handlers get enabled one at a time, I would have thought that that was possible?

[sago35]

@bmentink
Please write the entire source code so I can look into it some more.
Please use Quoting code to do so.

You may also want to use gist.

https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#quoting-code

[bmentink]

@sago35
Sorry, it's 1000+ lines at the moment and commercially sensitive ..
What else can I post that will help?

All I can say at this point, is that even just calling one of the above functions that sets' the interrupt results in that error ..

This is the function that calls the above:

// High level BLDC motor commutation function
func (d *Device) bldc_move(en bool) {
	switch bldc_step {
	case 0:
		start_time = time.Now() // Get the current time
		if en == true {
			d.bemf_B_falling()
		}
		d.ch_al()
	case 1:
		comm_time = int64(time.Since(start_time).Microseconds()) // return time between 60deg interrupts, in microseconds.
		if en == true {
			d.bemf_A_rising()
		}
		d.ch_bl()
	case 2:
		if en == true {
			d.bemf_C_falling()
		}
		d.ah_bl()
	case 3:
		if en == true {
			d.bemf_B_rising()
		}
		d.ah_cl()
	case 4:
		if en == true {
			d.bemf_A_falling()
		}
		d.bh_cl()
	case 5:
		if en == true {
			d.bemf_C_rising()
		}
		d.bh_al()
	}
}

It's not even getting as far as the interrupt handler .. the setup is failing.

One of the 6 handler's looks like this:

func (d *Device) handlerA_rising(p machine.Pin) {
	pe("handlerAR", d.comp_A.SetInterrupt(0, nil)) // Disable interrupt
	d.motorStep(d.comp_A)
}

[bmentink]

I think the problem is I can't seem to assign two handlers, one for each edge. On the same pin I.E

func (d *Device) bemf_A_rising() {
	pe("setupAR", d.comp_A.SetInterrupt(machine.PinRising, d.handlerA_rising)) // enable this interrupt, disable the rest
}

func (d *Device) bemf_A_falling() {
	pe("setupAF", d.comp_A.SetInterrupt(machine.PinFalling, d.handlerA_falling))
}

Because they refer to the same pin ... I am having issues.

I could have an interrupt handler that responds to both edges, But then how do I tell which edge it is?
... I need to have both edge interrupts active ... at the same time... because I don't know which comes first ..

Seems to be some functionality missing here for this user case ..

EDIT:

I also cannot do this to setup all interrupt handlers at once, it crashes the compiler ...

        pe("setupBF", d.comp_B.SetInterrupt(machine.PinFalling, d.handlerB_falling))
	pe("setupAR", d.comp_A.SetInterrupt(machine.PinRising, d.handlerA_rising)) 
	pe("setupCF", d.comp_C.SetInterrupt(machine.PinFalling, d.handlerC_falling))
	pe("setupBR", d.comp_B.SetInterrupt(machine.PinRising, d.handlerB_rising))
	pe("setupAF", d.comp_A.SetInterrupt(machine.PinFalling, d.handlerA_falling))
	pe("setupCR", d.comp_C.SetInterrupt(machine.PinRising, d.handlerC_rising))

[sago35]

The following requests have been made, but I don't think anyone has worked on them yet.

#2452

[sago35]

It would be easier to analyze if you could make a small reproduction of the code instead of a part of the code.

[bmentink]

Hmm, I will try, but very difficult as it is quit complex ... and also, there is a lot of real-time stuff going on, so hard to debug .. especially as the only options at this point is printf's ..

Meanwhile I have reduced my interrupt handlers to 3 that react to both edges, However it still crashes the compiler when I try to enable them all at once I.E

        pe("setupAR", d.comp_A.SetInterrupt(machine.PinRising|machine.PinFalling, d.handlerA)) 
	pe("setupBR", d.comp_B.SetInterrupt(machine.PinRising|machine.PinFalling, d.handlerB))
	pe("setupCR", d.comp_C.SetInterrupt(machine.PinRising|machine.PinFalling, d.handlerC)) 

[bmentink]

@sago35
I have found the issue. You can't seem to have a time.Sleep() call in an interrupt function, it causes the panic.

So my attempt at correcting this is to have the interrupt signal a Goroutine by doing the following:

// These are the interrupt handlers
func (d *Device) handlerA(pin machine.Pin) {
	debounce(d.comp_A)
	trigA <- 0
}

then the Goroutine:

func (d *Device) doAPhase() {
	for { // Forever
		select { // Wait for one of the event below
		case <-trigA:
			//led.Set(true)
			for sector := 0; sector < 6; sector++ {
				for i := 0; i < 32; i++ {
					d.setDutyA(uint32(duty[index[sector][0]][i]) >> 1) // These three phase duty needs to be loaded into the correct duty register
					time.Sleep(time.Microsecond * 2)
				}
			}
			led.Set(true)
		case <-quitA:
			return
		}
	}
}

The above time.Sleep() causes a panic and the LED is not lit ... if I comment it out the LED is lit and no panic.

So why can't I have sleeps in a Goroutine either ??
(The channels (trigA and quitA) are declared globally ... )

[aykevl]

I have found the issue. You can't seem to have a time.Sleep() call in an interrupt function, it causes the panic.

Correct. There is no way we could support this in a safe way. There are multiple reasons this is difficult:

• time.Sleep itself is usually implemented using interrupts
• it has the (probably unintended) effect of also blocking everything else in the system, while a regular goroutine can sleep while other goroutines are still running
• Interrupts are usually expected to be short running.

Instead of doing a debounce by sleeping, have you tried doing it via time.Now? That function should still work in interrupts.

So my attempt at correcting this is to have the interrupt signal a Goroutine by doing the following:

// These are the interrupt handlers
func (d *Device) handlerA(pin machine.Pin) {
	debounce(d.comp_A)
	trigA <- 0
}

This probably works... most of the time. It will still panic if trigA doesn't have space to receive the data.
For safety, it may be better to do this using a non-blocking select:

select {
case trigA <- 0:
    // send was successful
default:
    // send failed: channel is full
    // how this should be handled depends on the application (ignore, panic, reboot, whatever)
}

Do you have a debugger? I can very much recommend a debugger to debug these issues. For example, you could set a breakpoint on runtime._panic and if it is hit, do a backtrace to see where in the code the panic is triggered.

[bmentink]

Is there a HOWTO somewhere on adding a debugger to VSCode for TinyGo on Linux? I used to use OpenOCD for GDB, but I am guessing there has to be some other tool?

[aykevl]

There is this PR that I still need to take a look at: tinygo-org/vscode-tinygo#4

What I normally use is tinygo gdb (which you use just like tinygo flash but it'll drop you into a GDB shell). It may need a little bit of configuration depending on your board but many boards with on-board debugger are already supported. This may be helpful: https://tinygo.org/docs/guides/debugging/

[bmentink]

Thanks, It will be great to see it integrated into VSC ..

[bmentink]

By the way. I have my application mostly working now.

I have actually got it going by using a custom ticker(since time.Tick() is not supported), my ticker sends to a channel continuously at a rate determined by the receiver function. The overhead on this uP is a round-trip of 2uS. Means I can run motors over 15,000 RPM if I want.