Problem Uploading on Mac Book running Mountain Lion

Hello,

I am new to the Arduino and my Uno R3 arrived a few days ago but unfortunately I can not upload a sketch ( the Blink example ) on my Mac Book Pro running Mountain Lion ( 10.8 ).

I have followed the step-by-step instructions on the web site including the additional information in the FAQ, for example ensuring I have selected the correct port, in my case /dev/tty.usbmodemfa141 ( I also checked that the Mac was recognising the Uno R3 with the System Information Utility ). The error that I get is: avrdude: stk500_recv(): programmer is not responding. Also, I checked that there was no problems with the Uno R3 by connecting it to a Windows machine running XP and it uploaded a sketch with no errors.

I would like to get the Uno R3 working on my Mac therefore grateful for any help.

David

I'm afraid I have no solution to offer, but recently another person had a similar problem with ML and (s)he also reported the device name as usbmodemfa141. I have Snow Leopard and the UNO is seen as usbmodem114. It may be just coincidence, but I wonder what that additional 'fa' in the device name may mean. The other person produced a detailed log of the upload attempt, showing that communication failed when the device would have sent information about voltage and oscillator frequency.

Good to know that it's working on XP. You may try to produce two detailed logs for the attempts made on the two machines. I don't think I'll be able to find a solution but perhaps it will help others to help you. Please have a look at this discussion for more details:

Does the loopback test (sticky on this forum) work?

Thanks for both replies and the pointers.

So far I have tried comparing the verbose output between the Windows XP and Mountain Lion and unfortunately I can't cut & paste the output from Windows XP therefore can't share it on the forum, however the following fragment is from the Mac :

        System wide configuration file is "/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/Users/xxxxxxxx/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/tty.usbmodemfa141
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding

As can be seen above the software is looking for a file called: avrdude.conf which it can't find ( I checked the app bundle in Finder and the directory "etc" and file are missing ). However the file can be found on the Windows machine. I deleted and re-installed the software but found that the directory/file were still missing.

I'm guessing - if it can't find a "system wide config" file then the system will not be able to find a "user config" file ( see errors above ). If I am correct any guidance on how I can sort out ?

Unfortunately I haven't had time to apply the loopback test - hope to carry it out soon

Hmm, I trust you already checked, but please check again. The message is not about avrdude not finding the system wide configuration file (it doesn't complain about that) but an (optional) user configuration file. The full path for the system file is

/Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/etc/avrdude.conf

I am surprised by the very early termination of communications with the Uno, don't know what to think.

The error is really a warning and is normal. Nobody has a (usually) has a configuration file in their home directory.

If the "system wide" file didn't exist in the app bundle then avrdude would have quit before trying to communicate.

There is a communication problem which is why the loopback test is important.

Thanks again for both your replies.

Completed the loopback test and it is not communicating ( I checked the Uno R3 on the Windows XP machine and it successfully communicated using Serial Monitor ).

I doubled checked both USB ports on the Mac using the System Information Utility to make sure that it was "seeing" the Uno R3 and it is. Although on one of the ports ( Bus Number 0xfd ) it doesn't retrieve all of the device information compared to the other port ( Bus Number 0xfa ) - is that important ?

Are there any other tests that you can recommend to help pin point the problem ?

Update on progress.

I connected a powered USB Hub to the Mac Book and then connected the Uno R3 to the powered hub and everything is working - I can download a sketch.

Thanks for everyones help.

Great :slight_smile: I hear rumors that Apple is improving its methods to limit the current you can draw from USB ports when you connect a non-Apple device. For future reference, how old is your MacBook?

spatula:
Great :slight_smile: I hear rumors that Apple is improving its methods to limit the current you can draw from USB ports when you connect a non-Apple device. For future reference, how old is your MacBook?

That's probably a function of the USB spec and not a conspiracy theory.

USB spec says to only provide 100mA until the device asks for more. For USB 2.0 the max is 500mA. Apple's ports (like many PCs) allow for higher than that. It isn't called out in the 2.0 spec how to handle that. So the proper thing to do would be to limit current to 500mA.

I didn't weigh my words carefully. In their newest models Apple is less lenient than before in enforcing the USB specs for non-Apple devices. No conspiracy. I can understand their motives and have no qualms with them. I would like to add that this stricter enforcement doesn't affect the Arduino because it only needs 500mA, maybe just 250mA, which is granted by the USB specs. But I won't add that because I don't know whether it's true.

When I connect my UNO to my mid-2010 MacBook Pro I can go to the System Profiler and see that the USB device has 500mA available, 100mA needed. What if the Arduino, after successfully negotiating the 100mA, wants to draw more current? On my not-so-new MacBook I don't expect any problem. What about a strict specs-enforcer MacBook?

I may be wrong, but it seems to depend on whether the port is treated as a charging port or a downstream (data) port. Yes, it's a single physical port, but what it should do according to the specs depends on how we define it. As a charging port it has to provide up to 500mA, no fuss. As a downstream port, it is up to the Arduino to negotiate the new current before pulling it. Does the driver perform this negotiation? I don't know, but it seems it wasn't necessary in older models. Can the MacBook refuse? I believe it can. What are the externally observable results? I can only guess.

For future reference, how old is your MacBook?

It is a Mac Book Pro 15-inch and is about 2 years old.