I am using a uno board and a adafruit music maker. I have a 3x4 keypad connected to the GPIO pins on the music maker. When I upload sketch from hard drive the keypad does not function. When I upload the same sketch from a usb drive in the computer, the keypad does function. In all the years that I have been using this sketch without any problems I have never seen anything like this. Has anyone an idea as to what might be causing this?
Are both hex files the same?
Can you share your code (using code tags please).
As you can upload, this has nothing to do with Avrdude, stk500 or Bootloader. Your topic has been moved to a more suitable location on the forum.
Right now you are solidly in “that’s impossible” territory.
So. The sketches are 100 percent identical.
You are using the same IDE to open, compile and upload both sketches…
to the same UNO…
and one sketch works and the other doesn’t.
Yeah, there’s something else going on.
Have you tried saving the sketch from the USB to the hard drive with a different name so it doesn’t over write the original hard drive sketch? To see if that works?
And vice versa, save the hard drive sketch to the USB drive with a different name so it doesn’t over write the original USB sketch? To see if that works?
What else is on the USB drive? Does your sketch have multiple tabs? What libraries does it use if any?
What is # included in your sketch?
Yes, not all of those should cause such a problem I don’t think.
a7
I copied the sketch to another computer's hard drive and when I upload it from that computer the sketch functions properly. So, it has something to do with the 1st computer. This is in the impossible region. It makes no sense. I have tested this back and forth many times and the failure is consistent. It never works full function when uploaded from the hard drive from computer 1, only when it is uploaded from a flash drive plugged into computer 1. With computer 2 it does not make any difference. With computer 2 it works as it should regardless of where it is uploaded from. The only thing that doesn't work when it is uploaded from the hard drive on computer 1 is the 3x4 keyboard scanning. I thought that perhaps computer 1 might be introducing some noise on the usb line but disconnecting it does not correct the problem. This problem was causing me to chase my tail for days until I stumbled on the solution.
So, if this thread is being moved, where is it being moved to?
What solution?
Only do what works, and remain forever superstitious?
You didn't bother to answer any questions that were asked. There is a logical explanation.
a7
The solution is to use computer 2. I don't have time to go any further in trying to figure it out.
The sketch was copied to the usb flash drive from the hard drive. It's the same sketch. I compared them using WinMerge to make sure.
The usb drive has some older versions of the sketch as does the hard drive.
I've been working on this sketch for the last seven years going from version 1 to 5.2 with about 30 versions in between. I've been using the same computer 1 for all that time and computer 2 from time to time without any problems. I've been using the same IDE version for all that time as well. All the same libraries. One of the libraries (Adafruit_VS1053.h) is in the same folder with the sketch. The application is an audio kiosk in a museum where visitors select a sound track via a keypad. Once I figured out the code for the key pad track selection seven years ago it has always worked.
I don't know what you mean by "What is # included in your sketch"
I think they mean, you have not provided any code and the crystal ball light is out.
It will still have the same URL as always:
so the move has no effect on the people already involved in the thread.
It's simply listed under the "Project Guidance" forum category:
it sounds like you may gave sone stray ‘extra’ fixes in the project folder on computer#
The compiler will try to choose the right files and folders, but if it’s a mess, might easily get it wrong, or use ‘extra’ files that aren’t needed.
The optimiser can also misinterpret your intentions if the sources are all tangled up when the compiler does it’s stuff.
I’m guessing disorganised workspace or misunderstanding how source files are used by Arduino IDE (it’s a bit weird)
If you look at the top of your topic, you can see wher it is now
Different versions of the IDE / compiler / boards package might result in different HEX files when compiling. The linker might also has different thoughts in that case and lay out the memory differently in which case you more than likely have a bug in your program.
Note: your opening post never mentioned a second computer.
When the sketch is compiled and uploaded from the computer 1 hard drive some of the GPIO pins do trigger the playing of mp3 files however the 3x4 keypad which is connected to 7 GPIO pins does not respond properly. The sketch is looking for two numbers followed by the pound (#) key. It reads the first number (because a tick ack sound is heard) however it locks up (stops looping) and no longer responds to any GPIO. If the sketch is uploaded from the usb drive using computer 1, it does not lock up...it works perfectly. With computer two it makes no difference, hard drive or usb drive...it works just fine. The same IDE is used on both computers. The problem is related to the scanning of the 7 keypad pins. Very strange.
Do you have any include files, such as a modified library file, that are in the sketch folder on computer #1, but default to the library on the 2nd computer & usb drive?
there is a library file in the folder with the sketch on both the hard drive and the usb drive. What is on the hard drive was copied to the usb drive and re-copied a few times in case something got corrupted. The sketch was developed on computer 1 and remains on the hard drive until I need to copy it to a usb drive so I can take it and computer 2 to the museum and upload the sketch to the uno boards there. I have never had any problems with reading the keypads with the units in the museum since I installed them 7 years ago.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.