I was fooling around with an ISR routine on my Pro Micro connected to Pin 3. I can copy/paste the code but the basic gist is that I had a piezo detector circuit attached to Pin 3 which should trigger high and initiate the interrupt. Within the interrupt routine I had one part that sends a serial byte out of Pin 2 using SoftwareSerial and another part that sends a message to the serial monitor out of the USB programming connection…
When I loaded the sketch and it ran the first time I could see immediately that it was in a fast loop continually running the ISR and printing the message to the serial port.
I wanted to correct the program, but now running in this manner the Arduino IDE will not even recognize the USB device. When I try to upload I get “Error Uploading” and "USB Device “USB” not detected.
Did I kill it for good? I also tried reloading the bootloader but still it would not do it and just gave the USB device not detected message. I also tried manual reset and unplugging the arduino then plugging it in when the upload starts. Nothing works. Also now when I have the USB cable plugged in before I open the IDE, the IDE takes forever to open and when it does is says that there was an error while opening the application (doesn’t say what error).
Sorry, please post the code and drawings of your circuit anyway. Details are easily missed or omitted in a written description of the situation. And bugs in the code can always be present causing unintended side effects.
Remove the piezo circuit from the Arduino pin that has the interupt routine for it. Perhaps also add a pull-up or pull-down resistor to keep it in a defined dormant logic state. (depending on what the interrupt routine should NOT react to) Then there would be no external influence keeping it locked in that tight loop.
Thanks for the response. I have indeed tried to pull Pin 3 both high and low figuring it would hold the interrupt from continually changing, but to no avail. My best guess is that either something with printing the message to the serial monitor through the USB connection, or something with the SoftwareSerial function sending the byte out of Pin 2 is somehow causing Pin 3 to reset or change state resulting in the ISR itself triggering a new interrupt each time it runs.
I also know that their could be a conflict with the way SoftwareSerial handles either the timer or the interrupt itself such that maybe I shouldn’t be using it within the ISR. Here is the pertinent code. You might notice something strange in that I have the receive pin for mySerial designated as 11, which is not in use on the Pro Micro. This was my workaround for the fact that I needed a soft serial transmit pin but I had no physical pins left over to assign to the corresponding receive pin (My application does not need to receive anything, so I did not need a physical connection on the receive side). I tool a look at the schematic and found that pin 11 exists on the microcontroller so I tried using it. That worked fine until I added the interrupt stuff, so I don’t see how it could be related to the problem. I also think I should have tried another interrupt mode other than CHANGE. This is actually a very long sketch, but here are the parts that are in question:
#include <SoftwareSerial.h>
SoftwareSerial mySerial(11, 2); // RX, TX
int domeMotorpin = 15;
int domeSensorpin = 14;
int piezoPin = 10;
int pirPin = 16;
int loopVal = 0;
int mp3Pin = 2;
int cycleTimer = 0;
int mp3Volume = 0;
//int incomingByte = 0;
void setup()
{
Serial.begin(38400);
Serial1.begin(9600); // was 38400
Serial1.setTimeout(5000);
delay(3000);
attachInterrupt(1,interruptService,CHANGE);
Serial1.print("b");
delay(250);
Serial1.print("o");
delay(250);
Serial1.print("F");
delay(5000);
… something else I just noticed after reviewing the code I just posted… I see that I included a one second delay in the ISR. But when I actually ran the sketch the first time it was easily cycling more than once per second. The “Head” message that I had printing out of the USB port was scrolling down the serial monitor faster than I could read it. To me this further implies that the ISR is somehow re-triggering itself, even before the delay, which comes at the end.
The only other possibility could be an issue with the electronics of the piezo sensor. I have it going through a filter and op-amp to give a good binary (high/low) response while protecting the input pin from excessive voltage. The only thing is that the problem persists even with the Pro Micro physically removed from the circuit and just running by itself on USB power.
It also now occurs to me that in my code I never explicitly defined a pinMode for the interrupt pin (Pin 3). Perhaps that is causing it to change state by itself somehow.
Without the rest of the code, in particular the loop() function, finding a possible cause is often wasting time.
Could be. Well, you are lucky this time I think: :idea:
attachInterrupt(1,interruptService,CHANGE);
```Which pin does this take for interrupt input?
<QUOTE>
> The Pro Micro has five external interrupts, which allow you to instantly trigger a function when a pin goes either high or low (or both). If you attach an interrupt to an interrupt-enabled pin, you’ll need to know the specific interrupt that pin triggers: pin 3 maps to interrupt 0, <B>**pin 2 is interrupt 1**</B>, pin 0 is interrupt 2, pin 1 is interrupt 3, and pin 7 is interrupt 4.
</QUOTE>According to the hookup guide interupt 1 is connected through to pin 2. The one you use for SoftwareSerial TX! So the Interruptservice routine keeps triggering itself by use of the mySerial commands.
P.S. or does the rest of the code perhaps used I2C communication? As this is also the hardware I2C data pin.
To resolve this try to upload a corrected program to the pro micro before the bootloader finishes and the 3 seconds delay in setup() run out. Probably holding the reset line low (oops, there is no button) manually until the right time.
WOW so I got the interrupt pins wrong? I was going off of the Leonardo documentation and assumed it would be the same for the Pro Micro. This certainly would explain the behavior I am seeing. It gives me something to work from. Thanks for setting me on the right path, I will see if this can be fixed.
I was able to recover the Pro Micro and install the original sketch without the interrupts. Once you had explained the mixup in the interrupt pins, I went back and tried to hold Pin 2 low on the upload. That didn’t work, so then I held Pin 2 high and immediately the looping/scrolling serial monitor message I had been getting ceased. I wasn’t sure if this could have damaged the pin because it seems that this method was essentially overriding the SoftwareSerial output, even to the extent that the interrupt stopped sensing the change in state of the pin.
Once I had Pin 2 held high, the original version of the sketch without the interrupt stuff loaded back in normally and all the original functions I had tested up to this point are working again, including the USB serial monitor messages and the bytes being sent out of Pin 2 by SoftwareSerial to trigger the MP3 player.
It appears the Pro Micro made it through this unscathed. Tomorrow I will (cautiously) pick up where I left off, but using the appropriate interrupt designator for pin 3. (It is zero… right?).
I think holding the pin high when the Arduino wants to output a low (like when sending a 0 bit with the UART) can indeed damage the pin. (equally the opposite) Basically you connect Vcc to ground through the pin circuitry. That’s gonna heat something up. Atleast for prolonged periods, and if you directly connect it to Vcc. To be save, next time use a pull-up resistor. A 200 Ohm minimum resistor to 5 volt Vcc should reduce the ingoing pin current to below the absolute maximum pin current rating of 40mA.
Interrupt routines should be very short and quick. Usually they set a flag that the main program then handles or does some simple register based I/O. No function calls, no delays, no busy waits. Otherwise, they can block the processor from operating or even handling other interrupts, at least for processors without a priority interrupt system. It can be really bad when one interrupt does something that needs another interrupt to finish, but doesn’t let the other interrupts run.
Sure, there are some special apps that run almost everything in the interrupts, but you need to be careful with them.
I was actually using a 15K resistor when I was forcing the state of the pin. Even so, I had no idea what sort of I/O conflict this might have created… but it worked and it got my $20 module functioning again.
I have a new respect for using the interrupts. Even though, having corrected the interrupt pin, the original task I was trying to accomplish is working fine without a hitch. Each time I thump the piezo sensor the board triggers the MP3 as it should and then the sketch picks right up from where it left off. It works from anywhere with the sketch. Nonetheless based upon your feedback I will likely just set a variable from within the interrupt, then use that flag from within the Main loop to call SoftwareSerial to trigger the MP3.