Pin13 Mega appears to have a mind of its own?

Hi Folks,
I have keyboard scanning routine that scans three switches (up, down,select)

.....
byte repeatKey=0; //remember this key to enable repeats
......
  pinMode(A0,INPUT_PULLUP);  //uses active LOW switching
  pinMode(A1,INPUT_PULLUP);
  pinMode(A2,INPUT_PULLUP);
......


//***--- Stop program and wait for a key to be pressed
byte wait4key(){ //Wait for a key until the 'press' is released
   //use the repeat key to enable software loop of repeat key function
  do{
    delay(100);//debounce the switch
  }
  while (!keyNos() & repeatKey!=keyNos());
  temp = keyNos();
  do{
    delay(100);//debounce the switch
  }
  while (keyNos() & repeatKey!=keyNos());
  repeatKey=keyNos();
  return temp;
}
//***--- Scan the keys and return the index of any pressed
byte keyNos(){ //Scan the keyboard to decode the key press into a number, 0=no key pressed
  int nos=0; //default value
  if (digitalRead(A0)==0){
    nos = 4;//Nudge Downwards
  }
  if (digitalRead(A1)==0){
    nos = 3;//Select/Escape
  }
  if (digitalRead(A2)==0){
    nos = 2;//Nudge Upwards
  }
  Serial.print(nos,DEC);
  return nos;
}

I use the three switches (returning 4,3,2 (it had 1 & 5 as well at one stage)) as a simple menu choose/select approach and it seems to work just just fine, however for some reason when in the keyNos() subroutine the LED13 that I use elsewhere in the program to flash at the start of bars of music, LED13 just appears to flash for no reason that I can determine. It flashes at the correct time when the main program is running and it is scheduling the midi events (so it is enabled as an output), but when in this simplest of scanning loops it also flashes. I would love to just ignore it as everything else seems to be working fine, it just !@#$%^ irritates me as to why?

Then for some of the menu positions it then stops flashing? And another menu selection and it begins again grrrrr!

I am using these libraries for the SD card and Video, and expansion SRAM

#include <SD.h>       //Attached to LCD
#include <SPI.h>      //Talks to LCD and SD
#include <ST7735.h>   //TFT Coloured LCD
#include <xmem.h>     //Memory Expansion
#include <EEPROM.h>   //EEPROM Access

Can anybody offer any solutions? Suggestions?

Cheers, Rob

PS forgot to add, I don’t have any interrupts myself declared in this program

You need to post your full code

SPI uses pin 13 does it not?

JimboZA: SPI uses pin 13 does it not?

Not on the Mega boards. It's Pins 50-53.

[quote author=James C4S link=topic=208207.msg1530828#msg1530828 date=1388722353]

JimboZA: SPI uses pin 13 does it not?

Not on the Mega boards. It's Pins 50-53. [/quote]

Ah, right

HazardsMind: You need to post your full code

This should be pretty obvious. How are we supposed to figure out why your LED is flashing if you don't show us the code that flashes the LED?

Without seemingly ungrateful for your interest in my question, it is hard to see how the full program will clarify a small, "self enclosed" subroutine problem, that does not have any "outside" interrupts of my design (hence I can't show them because I don't have any, and even though the libraries may use them, which I did list, they can't be shown by me as well???) Maybe one of the Libraries uses LED13? But then why does the LED13 flashing stop arbitrarily, as soon the program is out that small subroutine, and indeed similarly stops from time to time within that routine ???.

The first steps to any problem solving with programming is to be able to focus on the question at hand and not just unload heaps of code for people to trawl through. I have tried to use my skills as best as they are to help the people who know these things to be able to best concentrate their skills in the problem area of the program. If you can suggest as to what sort of code may produce this problem, and that suggestion is still not enough to enable me to solve it , but it shows a lead, then I will post further code to elaborate the problem.

It is tempting to just list the whole thing and ask for help with an unwanted "Flashing LED13 problem" and hope someone will trawl through 1200 lines of code to solve my problem. However past experience tends to make a little pessimistic about that idea.

The LED is connected from Pin13 to Ground and not to some other "active" pin. Thank you to people who have responded so far. If someone can suggest some code, or strategy, that I could try as a debug I would be very grateful.

Cheers, Rob

If you can suggest as to what sort of code may produce this problem, and that suggestion is still not enough to enable me to solve it , but it shows a lead, then I will post further code to elaborate the problem.

That is getting things back to front. You want others to guess how you have written your program.

If the problem really is in that function (BTW how do you know that ?) then it should be easy for you to post a minimal program that compiles and exhibits the behaviour that you describe.

robwlakes:
It is tempting to just list the whole thing and ask for help with an unwanted “Flashing LED13 problem” and hope someone will trawl through 1200 lines of code to solve my problem. However past experience tends to make a little pessimistic about that idea.

Countless times on this forum people have asked for help with their code and only posted a few lines. The result? They never find their problem. Why? Many times the problem isn’t there.

If you knew where the problem was already, you wouldn’t have to ask for help, no?

By the way, attaching a ino file takes a lot less typing than “I’m too pessimistic to try.”

robwlakes:
If someone can suggest some code, or strategy, that I could try as a debug I would be very grateful.

You can start by posting your entire code. Knowing the context of the suspected code helps. As already stated if you can compile a small section of code that exhibits the same behavior that usually results in success as well.

Why? Many times the problem isn't there.

If you knew where the problem was already, you wouldn't have to ask for help, no?

Very true.... I had a compile fail yesterday, but Alas! I didn't keep the error message as an example. It pointed to a fault on line "x" which I checked a zillion times and was convinced it was good. So I looked earlier in the file, and sure enough there was a missing } or ) or ; or something dumb (I forget what, but it was trivial) on line "x-10" kind of thing. That missing character didn't cause line x-10 to fail, the problem only popped out lines later and as I say, that "bad line" was actually good.

So yeah, post all code. By all means post snippets for discussion in the post, but post the whole thing somewhere. AND full error messages if compile fails.

it is hard to see how the full program will clarify a small, “self enclosed” subroutine problem

Well, one problem is that you are making assumptions that are apparently flawed, one of which may well be where you think the problem is in your code.

robwlakes: Without seemingly ungrateful for your interest in my question, it is hard to see how the full program will clarify a small, "self enclosed" subroutine problem, that does not have any "outside" interrupts of my design (hence I can't show them because I don't have any, and even though the libraries may use them, which I did list, they can't be shown by me as well???)

Because, as I said in my previous post, NOWHERE in that snippet is there a single "digitalWrite" function. If there are no interrupts, it's impossible for that snippet to be flashing the LED. Something else must be going on.

Actually, I see a small problem which MIGHT be ending your blocking loop early.

...
while (!keyNos() & repeatKey!=keyNos());
...
while (keyNos() & repeatKey!=keyNos());
...

Your conditionals in the wait4key function's do-while loops are using the bitwise AND operator (&), whereas I suspect you want the conditional AND operator (&&). With the right value of repeatKey and the right return values of keynos(), it's probable that this logic error is causing your blocking loops to terminate early, allowing the code to proceed to other functions, possibly one that blinks the LED. Change those single ampersands to doubles and see if it makes a difference.

Thank you Jiggy-Ninja, you have helped considerably. The exit criteria in the de-bounce loops were not working as expected. My bit wise & was not planned well enough and was decoding some stuff OK, but allowing exits that should have been trapped. I have made the code below a bit more verbose, but for my simple brain, easier to follow, and now behaves correctly. The && comparison and extra brackets to ensure the precedence has worked. Rethinking the names of variables also clarified things. The flashing of the LED13 while scanning the keyboard has stopped, and the keys are now much more responsive and have a very definite feel about them.

//***--- Stop program and wait for a key to be pressed
byte wait4key(){ //Wait for a key until the 'press' is released
  byte keyRel=0;//key released
  byte keySel=0;//key selected
  //use the repeat key to enable software loop of a "repeat" function
  do{
    delay(100);//debounce the switch
    keySel=keyNos();
  }
  while ((keySel==0) && (keySel!=repeatKey));
  do{
    delay(100);//debounce the switch
    keyRel= keyNos();
  }
  while ((keyRel!=0) && (keyRel!=repeatKey));
  repeatKey=keySel;
  return keySel;
}
//***--- Scan the keys and return the number of any pressed
byte keyNos(){ //Scan the keyboard to decode the key press into a number, 0=no key pressed
  int nos=0; //default value
  if (digitalRead(A0)==0){
    nos = 4;//Nudge Downwards  Menu choice, or selected Value
  }
  if (digitalRead(A1)==0){
    nos = 3;//Select menu choice to set value, or Escape from Menu choice and accept value
  }
  if (digitalRead(A2)==0){
    nos = 2;//Nudge Upwards    Menu choice, or selected Value
  }
  return nos;
}

However a single LED13 Flash still occurs when a keyboard entry is made, even though the only DigitalWrite in the main loop is disabled. This to me indicates some sort of memory leak/bug in the rest of the code. I am happy to set about solving this on my own for the moment.

Thank you for the interest in the topic and your thoughtful suggestions. The original problem still exists, ie unexpected LED13 flashing, but at least I have solved the mystery in the all important keyboard scanning with your help. Ta!!!

Rob

The pin 13 led random lighting up or blinking has been discussed before on the forum. With rev 3 they redesigned the L-13 to be driven by a spare op-amp stage rather then directly from the arduino pin 13. And as pin 13 defaults to be an input pin on reset or power up the op-amps input is subject to being a 'floating input' and thus the state of the led can be off or on or random blinking based on circuit noise, phase of the moon, and how you hold your tongue. Not every Rev 3 board acts the same, but it was a poor design to not place a high value pull-down on the op-amps input.

Anyway the simple fix is to just enable the internal pull-up resistor for pin 13 in your setup function if you are not going to be using pin 13 in your sketch. pinMode(13, INPUT_PULLUP);

Lefty

Thanks again to people who have helped. The solution exposes a mistake on my part in the construction of the project. I have used an Adafruit 1.8" TFT shield with Joystick and SD interface on a Mega2560. What I did, and since corrected, is connect the LED from the GND on the TFT board to the pin 13 on the TFT board.

The big problem with that is I had correctly removed the “thru” pins from 10-13 on the TFT board and re routed its pins 10-13 to the dedicated SPI pins on the Mega pins 50-53. So what I thought was the LED13 was actually the SCK pulses for the SPI coming from pin 52. (The screen and SD is very reliable by the way).

So every time I pressed a key, the LCD was updated, hence “LED13” blinked. :~ What made it harder to crack was I also updated the bar number to the screen as well, creating pulses around where they should have been.

Solution is to jump around the TFT board and wire to the proper LED13 connector on the board below. See attached photo. A bit kludgy but it works for the moment.

Thanks to all those who contributed to helping me solve this puzzle. The real LED13 now flashes correctly at the start of every bar!

Cheers, Rob

2014-01-04 16.41.41x600.jpg

Haha so I was right- or at least on the right track- maybe for the wrong reason- waaaaaay back about reply #2 or 3

Edit... all thru the "post your code" hoohah, we should really have been insisting on a circuit diagram.

A bit late but here it is.... pin 13 ----|>|------GND The LED/pcb mistake actually helped alert me to the keyboard problem. Funny how things pan out. Thanks for your interest. Cheers, Rob