Arduino BT docs / programming reliability?

Hi. I just got an Arduino BT which I'm very pleased about, but programming it seems to result in "Programmer is not responding." quite a lot.

Is there any particular trick? I'm pressing the reset button and then clicking upload immediately. Working about 20% of the time at present, on a Macbook Pro (intel), OSX 10.4.8 with Arduino 0007 (similar problems with 0006). BT's firmware is v1.15.

There hardly seems to be any documentation for the BT apart from and I missing something?

I noticed that sometimes my LED on p13 was flashing 3 times on reset -- does this have a special meaning? (I didn't program it)

Many thanks


last week I programmed 36 BT modules with the same equipment you are using. Once you get the hang of it, they work perfectly.

What I found is that you have to press the reset button on the module and the upload button simultaneously.

There are a couple more tutorials than you mention, in the 'Playground' tutorials section.

Macintosh BT setup

XP setup

Burning the bootloader on the BT

Changing the name of a BT module

You are right, there is little documentation, just like the Arduino itself a year ago. Have a look at this:


What I found is that you have to press the reset button on the module and the upload button simultaneously.

Well, that worked but it doesn't fill me with confidence!

[ update: it worked for me once, but only once ]

Some better feedback in the IDE about what's going on would be useful.

Strangely the output I was getting was the usual:

Atmel AVR ATmega168 is found. Uploading: flash Firmware Version: 1.15 Firmware Version: 1.15

but followed immediately by

Programmer is not responding.

This appears real time in the console window looking at system.log, but all at once in the Arduino window... there's data going over bluetooth according to the BT logo in the menu bar, so it looks like the code's being sent but the burn process is failing???

Also I found that the IDE has locked up a few times while I've been trying to sort this out, and forcing a quit results in a process named (Arduino) that only goes away on reboot (kill -9 doesn't work).

In case it's related I've spotted intermittent errors like this in system.log

Feb 22 18:22:27 mungbean kernel[0]: ttyiossa000000: mctl RS232_S_OUTPUTS failed e00002cd

Could it be flakiness in the macintel version of RXTX over Bluetooth?

(Native lib Version = RXTX-2.1-7, Java lib Version = RXTX-2.1-7)


it looks like the code’s being sent but the burn process is failing???

I should’ve also said that the LED flashing 3 times was repeating
with a period of about 10 seconds, as if the atmel was continuously
resetting rather than running the new program… would this happen if there
was a failure while uploading the code and it was corrupted or something?

Thanks again.

do you have anything connected to pin 7 by chance?


do you have anything connected to pin 7 by chance?


no, just an LED in pin 13 for now


not really sure what to suggest next. We ordered 35 of the BT modules for a class I teach, and they have worked well. On the same MAC hardware you are using I had no problem identifying them with BT and programming them.

The only cautions are not to call pin 7 in software , or to connect it in hardware, as it is hard-wired to reset the BlueGiga BT module. Also, the default serial speed is always 115200. so Serial.begin(115200); is what you always have to use.

What BT number is on the back of the module? It should have a white label that says BT33 etc.


the number is BT201 - I bought it from pcb europe recently.

I would appreciate someone telling us what the LED on pin 13 flashing 3 times every 10 seconds means -- I've seen other people describing this happening on their boards too.

I'm snowed under due to a deadline just now but will get to more experimenting later this week.


the three quick flashes is the boot sequence... it does sound like it is resetting every ten seconds, if that happens every ten seconds.

It also sounds like you haven't actually uploaded a new program, even if the IDE Is telling you you have. It's kind of hard to tel with the BT, since there are no LEDs. You could set the upload preferences to "verbose" in the preferences text.

That's about all I can think of...



I think I found your problem, as it just happened to me.

I was reprogramming some modules and burned the bootloader file, which I imagine wiped the current program. The BT reset and acted just like yours: a reset every five or six seconds.

When I put a new program in, it stopped resetting.

This means your reset is telling you that there isn't a program....


Hi Daniel.

So if I understand correctly the conclusion is that:

  • sometimes the burn process fails
  • sometimes when it fails the code gets corrupted and the atmel will reset itself continually

is that right?

FWIW I’ve tried using 0006 and 0007 and still seeing exactly the same issues.
I’ve also switched from batteries (known good) to a 5V supply and it still makes no difference.

Sometimes when I get “Programmer is not responding.” at the end of the burn sequence the code has been uploaded anyway, ie. it works despite the error message.

I’ve tried using an NG board with exactly the same software and I haven’t seen the problem with that, so I’m inclined to think it’s a bluetooth-specific problem.

I’ve also briefly tried building on the command line but didn’t get past avrdude complaining about programmers:

avrdude: Can’t find programmer id “stk500”

what programmer setting does it expect? I couldn’t get avrdude to list the programmer types it’s compiled to support.


Hi Daniel. So if I understand correctly the conclusion is that: - sometimes the burn process fails - sometimes when it fails the code gets corrupted and the atmel will reset itself continually is that right?

Not at all! For me it works ALL the time, no resets, no problems.

With the boards I ordered, there haven't been any problems similar to what you describe. What I did observe once was that if you upload empty user code (i.e. your program) then the BT will reset continuously. That's not a defect in the BT, but rather it just reflects the fact that you haven't successfully uploaded any code for the BT to run.

Maybe Massimo can give you a hand here, he knows it better than I do.


To answer one of my own questions, it's possible to get more verbosity during the burn process by changing the preferences.txt file to say


On doing this I noticed the serial speed in the uisp command is still 19200 rather than the 115200 we're told to use for the ArduinoBT. Is this likely to be a problem? I guess something is changing it to the right speed somewhere since my uploads are working SOME of the time. (Actually having about 90% success rate at the moment, somehow...)

tools/avr/bin/uisp -v=4 -dpart=atmega168 -dprog=stk500 -dserial=/dev/tty.ARDUINOBT-BluetoothSeri-1 -dspeed=19200 --upload if=/Users/chris/Documents/Arduino/myled_blink/applet/myled_blink.hex

I found the relevant line in preferences.txt :


and changed it to 115200.... interestingly when I started up the IDE it got changed back to 19200!

In case none of this is relevant (!) is there any debug output I can useful provide from the occasions where the upload is failing?


(I may be talking to myself here, but I'm keen to resolve this as fast as possible -- I have a project to do and if I can't resolve this very soon I will need to find an alternative to the ArduinoBT... any recommendations for a BT module I could use with my arduinoNG ?)

Here's the verbose output on an occasion when the upload is failing:

Binary sketch size: 4116 bytes (of a 14336 byte maximum) tools/avr/bin/uisp -v=4 -dpart=atmega168 -dprog=stk500 -dserial=/dev/tty.ARDUINOBT-BluetoothSeri-1 -dspeed=19200 --upload if=/Users/chris/Documents/Arduino/myled_blink/applet/myled_blink.hex

Transmit: { 0 [30] [20] } Receive: { . [14] } Receive: { . [10] } Transmit: { B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [02] . [00] . [00] . [00] @ [40] . [00] [20] } Programmer is not responding.

and a successful one:

tools/avr/bin/uisp -v=4 -dpart=atmega168 -dprog=stk500 -dserial=/dev/tty.ARDUINOBT-BluetoothSeri-1 -dspeed=19200 --upload if=/Users/chris/Documents/Arduino/myled_blink/applet/myled_blink.hex

Transmit: { 0 [30] [20] } Receive: { . [14] . [10] } Transmit: { B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [02] . [00] . [00] . [00] @ [40] . [00] [20] } Receive: { . [14] . [10] } Transmit: { A [41] . [82] [20] } Receive: { . [14] . [0f] . [10] } Transmit: { A [41] . [81] [20] } Receive: { . [14] . [01] . [10] } Transmit: { E [45] . [04] . [04] . [d7] . [a0] . [01] [20] } Receive: { . [14] . [10] } Transmit: { P [50] [20] } Receive: { . [14] . [10] } Transmit: { u [75] [20] } Receive: { . [14] . [1e] . [94] . [06] . [10] } Transmit: { Q [51] [20] } Receive: { . [14] . [10] } Vendor Code: 0x1e Part Family: 0x94 Part Number: 0x06 Atmel AVR ATmega168 is found. Page Write Enabled, size=128 FLASH Write Delay (t_wd_flash): 12500 us EEPROM Write Delay (t_wd_eeprom): 11111 us Transmit: { 0 [30] [20] } Receive: { . [14] } Receive: { . [10] } Transmit: { B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [02] . [00] . [00] . [00] @ [40] . [00] [20] } Receive: { . [14] . [10] } Transmit: { A [41] . [82] [20] } Receive: { . [14] . [0f] . [10] } Transmit: { A [41] . [81] [20] } Receive: { . [14] . [01] . [10] } Transmit: { E [45] . [04] . [04] . [d7] . [a0] . [01] [20] } Receive: { . [14] . [10] } Uploading: flash

###########################################################################################################################Transmit: { P [50] [20] }


For some reason today I've not seen at all the situation where the upload appears to work, but then it says "Programmer is not responding". This was happening a lot last week.

hello you're not talking to yourself...

I'm reading...

I've come to the realisation that bluetooth support is somehow inconsistent across platforms...

reliability seems to change even from computer to computer running the same os (MacBook for example)

BTW: i'm going to email you so we can help you more directly


Hi guys,

I have just received my arduino bt and was trying to get it to work with mac osx leopard but was having the same problems with the software crashing.

I tried using the windows version of the software (running xp under parallels) and managed to get it going.

My observation is that the timing of pressing the reset button on different PC's may be different because it all depends on the compile time of the sketch before it is transmitted. I now do a test upload to see how long the sketch takes to compile (in the order of 20 seconds for small sketches) whilst at the same time looking at CPU activity, which drops once compilation is complete.

Once i know how long to wait, I can time my pressing of the reset button appropriately.

I wonder if it would be possible to include an option to not compile before each upload? Maybe require a separate compile or send message saying upload is about to begin?

Also, does anyone have any ideas on leopard compatibility? Michael