GPIO (output) stops working after a certain amount of switches.

[mitch0s]

I've began a small project where I use a RP2040 as a base of an ECU for an engine. I'm currently testing, and will need high frequency switching of output pins, e.g. to trigger a mosfet for spark and fuel injection. While testing, seems that the output to the pins set to output signals over a range of time seems to disappear, I can see that inputs are detected via a serial debug output, but the LEDs that I have connected as a visual representation of the signals being outputted by the RPi Pico (RP2040).

If it helps, moments before, there are two brief flashes that can be seen prior to all output being stopped. The timespan between these two pulses are also directly proportional to the frequency I'm running.

It's consistent in a sense where if I double the frequency, it takes half the amount of time it takes for the same sudden stop in output to happen, and not even using an external button to try and trigger the lights/timing seems to work once frozen in the off state.

I'm currently running the latest version of MicroPython for the Pico W.

[mitch0s]

Notes:

1. There is no console serial output or exceptions that are raised
2. I have used the gc module to see whether it'a a memory issue, but all output it still disabled even if garbage collection is run every cycle.

[mitch0s]

I think this may be a problem on my end, I couldn't replicate it by just triggering 4 outputs at the same speed. I'll do some more thinking and see if I can find what may be causing it.

[peterhinch]

I have moved this to discussions: more detail is required to raise a bug report.

It's very hard to comment on this. I suggest you write a minimal script which demonstrates this problem and post your code here. Then other users can review it, offer suggestions, and determine where the fault lies.

[mitch0s]

Yea, I've written a small script to toggle an output of 4x GPIO pins really fast (10,000/min) and couldn't replicate it.

With my current setup, I'm using two picos, a common ground between the two, and then the output of the secondry pico connected to the input pin on the primary pico.

[peterhinch]

In electronics terms this isn't very fast (166Hz). However if the receiving Pico is expected to respond to each pulse, some care is needed in the code. Without an example it's impossible to comment.

[mitch0s]

Yeah, I understand that. The loop I'm currently running runs at about 2500Hz. So that is likely not the problem. I'm currently rewriting the script in a way that makes it a little more simpler and potentially remove the issue that I'm having.

I'll be sure to keep the thread updated as I progress.

[mitch0s]

Hahahahaha I'm laughing hysterically right now. Remember when I regarded garbage collection?

I was right, but I completely forgot to check it for the pico acting as the sensor input.

All is working now, was no actual bug with MicroPython, which I am assuming many will be thankful for.

[mitch0s]

This is the original:

import machine
import utime as time
import _thread
import gc


class VirtualCrankSensor:
	def __init__(self):
		self.crank_sensor_output = machine.Pin(0, machine.Pin.OUT)
		
		# Crank Variables
		self.crank_rpm = 10_000
		
		
		# Start Threads
		_thread.start_new_thread(self.thread_1, ())
		self.thread_0()
		
		
	def thread_0(self):
		while True:
			try:
				self.crank_rpm = float(input('RPM: '))
			except Exception as error:
				print(error)
	
	
	def thread_1(self):
		while True:
			try:
				time.sleep((1 / (self.crank_rpm / 60)) / 2)
				self.crank_sensor_output.high()
				time.sleep((1 / (self.crank_rpm / 60)) / 2)
				self.crank_sensor_output.low()


			except Exception as error:
				print(error)
			
			
start = VirtualCrankSensor()
	

[mitch0s]

This is the fixed:

import machine
import utime as time
import _thread
import gc


class VirtualCrankSensor:
	def __init__(self):
		self.crank_sensor_output = machine.Pin(0, machine.Pin.OUT)
		
		# Crank Variables
		self.crank_rpm = 10_000
		
		
		# Start Threads
		_thread.start_new_thread(self.thread_1, ())
		self.thread_0()
		
		
	def thread_0(self):
		while True:
			try:
				self.crank_rpm = float(input('RPM: '))
			except Exception as error:
				print(error)
	
	
	def thread_1(self):
		while True:
			try:
				time.sleep((1 / (self.crank_rpm / 60)) / 2)
				self.crank_sensor_output.high()
				time.sleep((1 / (self.crank_rpm / 60)) / 2)
				self.crank_sensor_output.low()
				
				gc.collect()
				
			except Exception as error:
				print(error)
			
			
start = VirtualCrankSensor()
	

Notice the additional gc.collect(). Shaking my head in disbelief

[mitch0s]

On the plus side, the code that I rewrote for the ECU portion of the project is faster now. Thank you for your time.

[jimmo]

@mitch0s Can you summarise why the gc.collect() fixed your problem? In general, it shouldn't be necessary for a program to explicitly call gc.collect(). In this case your program is just going to be spending 100% of core 2's time doing garbage collection (which spends a good amount of time locking out core 1).

Which firmware version are you using btw, there was a bug with multi-threaded GC on pico, but it was fixed a while ago. Unfortunately there are still a lot of web pages and forum posts saying to blindly add "gc.collect()" everywhere to solve the problem.

[mitch0s]

G’day. It wasn’t an issue with the Pico W (latest firmware). It was an issue with the garbage collection with my secondary Pico, unsure what firmware version, running out of memory. To give context for my setup, the primary ECU reads the crank sensor to calculate timing of spark plugs and fuel injectors, but I currently don’t have an engine to test on so I wired up a secondary pico to act as a button press sort of input, switching at intervals similar to that of the crankshaft in an engine. I’ll update the firmware on the secondary pico and let you know if the issue remains, even after removing garbage collection.

…

On Tue, 22 Nov 2022 at 09:17, Jim Mussared ***@***.***> wrote: @mitch0s <https://github.com/Mitch0S> Can you summarise why the gc.collect() fixed your problem? In general, it shouldn't be necessary for a program to explicitly call gc.collect(). In this case your program is just going to be spending 100% of core 2's time doing garbage collection (which spends a good amount of time locking out core 1). Which firmware version are you using btw, there was a bug with multi-threaded GC on pico, but it was fixed a while ago. Unfortunately there are still a lot of web pages and forum posts saying to blindly add "gc.collect()" everywhere to solve the problem. — Reply to this email directly, view it on GitHub <#10035 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQCZ5GDFPCFAQZJZRJHUA6DWJQNJLANCNFSM6AAAAAASGNJNQI> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>