I just received 3 Moteino R4 USB boards, which impress me on being so small. Very nice form factor!
When I connect via USB to my Mac the Ardiuno IDE (version 1.0.5) can see the USB serial adapter. I selected "Ardiuno Uno" as board type and "AVR ISP mkII" as programmer (same settings that work fine with the USB Ardiuno clones from Jeelabs). When I tried to upload a sketch the LEDs start blinking wild, but stop after a second and the IDE delivers the message:
Binary sketch size: 15,184 bytes (of a 32,256 byte maximum)
avrdude: loadaddr(): (b) protocol error, expect=0x14, resp=0xf8
avrdude: stk500_recv(): programmer is not responding
All three boards behave the same, I can't see unwanted soldering bridges on the PCB, and I don't believe all three are somehow faulty.
Any idea what I am doing wrong here?
P.S.: I have Moteinos with flash chips. Is that giving me trouble here?
P.S.S.: I desoldered the flash chip from one of the boards. no change.
You have to use an FTDI adapter, not AVR ISP MKii.
You have to choose Arduino UNO in the IDE.
Flash chips don't interfere with programming, otherwise I wouldn't be offering them.
When the transceivers are soldered to the boards, reflashing the AVR with the AVR programmer is a bit harder, you have to pullup D10.
If you reflash the AVRs yourself, then you are on your own from that point on.
I have the USB Monteino R4 with the FTDI chips already on board.
http://lowpowerlab.com/shop/moteino-r4-usb
As said, it is correctly recognized as a USB serial connection and
when doing the sketch upload it starts fine and I can see traffic
with the Monteino LEDs blinking very fast, but then it stops with an
error message.
Ardiuno IDE provides me the following options to choose from regarding the programmer
Looks like selection of a programmer is not used when Ardiuno UNO selected as board.
However, when I start upload (via USB, I don't even have a SPI programmer or such)
Ardiuno does log progress...
avrdude: Send: d [64] . [00] . [80] F [46] . [80] . [91] . [ef] . [03] . [88] # [23] 1 [31] . [f0] . [c9] . [01] a [61] . [e0] . [0e] . [94] % [25] . [10] . [81] . [e0] . [08] . [95] . [c9] . [01] . [0e] . [94] . [8c] . [10] . [80] . [e0] . [08] . [95] . [0f] . [93] . [1f] . [93] . [cf] . [93] . [df] . [93] . [ec] . [01] . [8b] . [01] a [61] . [e0] . [0e] . [94] % [25] . [10] . [01] . [15] . [11] . [05] . [e1] . [f0] . [ce] . [01] . [0e] . [94] . [8e] . [0f] . [8e] . [eb] . [8e] . [bd] . [0d] . [b4] . [07] . [fe] . [fd] . [cf] . [8e] . [b5] [20] . [e0] 0 [30] . [e0] . [f8] . [01] . [e2] . [0f] . [f3] . [1f] . [80] . [81] . [8e] . [bd] . [0d] . [b4] . [07] . [fe] . [fd] . [cf] . [8e] . [b5] / [2f] _ [5f] ? [3f] O [4f] [20] 1 [31] 1 [31] . [05] . [91] . [f7] . [ce] . [01] . [0e] . [94] . [87] . [0f] . [ce] . [01] m [6d] . [e3] . [0e] . [94] . [cc] . [0f] H [48] / [2f] N [4e] . [7f] . [80] . [e0] . [01] + [2b] . [09] . [f0] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: U [55] . [00] . [11] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [81] . [e0] H [48] + [2b] . [ce] . [01] m [6d] . [e3] . [0e] . [94] . [95] . [0f] . [df] . [91] . [cf] . [91] . [1f] . [91] . [0f] . [91] . [08] . [95] . [88] # [23] . [19] . [f4] . [8c] . [b5] . [80] b [62] . [02] . [c0] . [8c] . [b5] . [8f] } [7d] . [8c] . [bd] . [08] . [95] . [9c] . [b5] . [93] . [7f] . [98] + [2b] . [9c] . [bd] . [08] . [95] , [2c] . [b5] 8 [38] / [2f] 3 [33] p [70] , [2c] . [7f] 2 [32] + [2b] < [3c] . [bd] - [2d] . [b5] . [90] . [e0] . [95] . [95] . [87] . [95] . [95] . [95] . [87] . [95] . [81] p [70] . [2e] . [7f] . [82] + [2b] . [8d] . [bd] . [08] . [95] . [8a] . [e0] a [61] . [e0] . [0e] . [94] F [46] . [17] . [8a] . [e0] a [61] . [e0] . [0e] . [94] . [07] . [17] . [8c] . [b5] . [80] a [61] . [8c] . [bd] . [8c] . [b5] . [80] d [64] . [8c] . [bd] . [8d] . [e0] a [61] . [e0] . [0e] . [94] . [07] . [17] . [8b] . [e0] a [61] . [e0] . [0e] . [94] . [07] . [17] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
#avrdude: Send: U [55] @ [40] . [11] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [08] . [95] . [fc] . [01] . [80] . [81] . [88] # [23] . [11] . [f4] . [82] . [e1] . [01] . [c0] . [8d] _ [5f] . [0e] . [94] . [07] . [17] . [08] . [95] . [fc] . [01] . [80] . [81] . [88] # [23] . [11] . [f4] . [83] . [e1] . [01] . [c0] . [83] _ [5f] . [0e] . [94] . [07] . [17] . [08] . [95] . [fc] . [01] . [80] . [81] . [88] # [23] . [11] . [f4] . [82] . [e1] . [01] . [c0] . [8d] _ [5f] . [0e] . [94] F [46] . [17] . [08] . [95] . [ff] . [92] . [0f] . [93] . [1f] . [93] . [08] / [2f] . [f9] . [2e] . [16] / [2f] ` [60] . [e0] . [11] # [23] . [09] . [f4] a [61] . [e0] . [80] / [2f] . [9f] - [2d] . [0e] . [94] A [41] . [11] . [80] / [2f] . [9f] - [2d] a [61] / [2f] . [0e] . [94] U [55] . [11] . [1f] . [91] . [0f] . [91] . [ff] . [90] . [08] . [95] . [fc] . [01] . [80] . [81] . [88] # [23] . [11] . [f4] . [83] . [e1] . [01] . [c0] . [83] _ [5f] . [0e] . [94] F [46] . [17] . [08] . [95] [20]
avrdude: Recv: . [ff]
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0xff
avrdude: Send: V [56] @ [40] . [00] . [00] . [0c] [20]
avrdude: Recv: . [10]
avrdude: stk500_cmd(): programmer is out of sync
To rule out that my Mac is doing bad things here, I started my Windows PC and tried to upload the simple "blink" sketch.
This returned following errors:
avrdude: Version 5.11, compiled on Sep 2 2011 at 19:38:36
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf"
Using Port : \\.\COM19
Using Programmer : arduino
Overriding Baud Rate : 115200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [84]
avrdude: stk500_getsync(): not in sync: resp=0x84
avrdude done. Thank you.
Funny thing is, that the LEDs starts blinking despite of the upload error messages.
Do I have to change some magic numbers in the Ardiuno config to reflect that your boot loader is larger than the classic one? Just guessing, I am not an expert on that...
As the behavior seems to be a bit unstable in general I changed the USB port. This time I used
the one included in my monitor instead of the one directly at the PC/MAC. To my surprise that
solved the issue. Hmmm, the JeeLab boards work flawless on any USB port.
What also makes me wonder is that the JeeLab board I did refit myself with a RFM69CW
replacement (pin compatible to the RFM12) does collect less noise via RF than the Monteino.
The Monteino starts receiving fine, when I wrap the antenna with my fist. When I release
my hands again tons of noise data flowing in via RF. As said, I have the same sketch running
on the Jeelab board in parallel without that amount of noise catching.
May be this is all because I do something wrong, but for now it looks still a bit unpredictable to me.
Any hint is welcome.
I could bring down false reception by tweaking rx treshold values of rfm69. So that looks fine now.
Looking with my glasses onto the JeeLab and Monteino boards I see that JeeLabs is using
the well-known FT232RL while the Monteino has the FT231XS on board. May be the PC/Mac does simply
have trouble with that.
Anyway... great to have it working now. And may be this thread helps others to find a solution much faster.
The drivers for the FT231XS are the same as for FT232RL so you should have no trouble if you got the drivers installed properly.
In the IDE you have to choose the correct serial port emulated by this FTDI chip, and Arduino UNO as target for Moteino.
All things equal, you will still see differences in RF performance between two different products depending on many factors.
You have to use the proper settings for the RFM69W/HW and solder the antenna. There are already several threads in this forum that discuss the best antenna configuration and good practices so I suggest you read on those if you have more questions in that direction.
Hello Felix,
i have the same problem with these upload errors. Sometimes it seams that the program is uploaded in parts only.
My configuration:
Moteino R4-USB with RFM69HW
OS: Windows 7 64Bit, GERMAN version
Driver: USB Serial Port (COM6 (115200, 8,None, 1, none), FTDI, Version 2.8.30.0
with the following driver files:
C:\windows\system32\drivers\ftser2k.sys (2.8.30.9)
IDE: Arduino 1.0.5-r2 with configuration: Board = Arduino UNO, Serial programmer = AVR ISP
I always get the following message:
avrdude: stk500_loadaddr(): (a) protocol error, expect=0x14, resp=0x53
avrdude: stk500_paged_load(): (a) protocol error, expect=0x14, resp=0x65
avrdude: stk500_cmd(): programmer is out of sync
What i have done wrong? Is something inside Arduino IDE configuration files to adapt to your board?
Could you please give me a hint.
Thanks Wolfgang
Wolfgang, does it only work sometimes and sometimes not?
Have you updated the drivers for the FTDI?
Hello Felix,
I used three different PC's (two with WIn7/64Bit, one with 8.1/64Bit) to test it and the result is that in 98% of all tries it doesn't work.
Despite of having these non working uploads the program is transfered to MOTEINO and is working in 50%, the other 50% the program is uploaded in parts or not and it brings very strange MOTEINO program behaviours then.
I have tried different drivers from Arduinio IDE\hardware\driver\arduino.inf and with FTDI driver from http://www.ftdichip.com/Drivers/VCP.htm
Operating System Release Date x86 (32-bit) x64 (64-bit)
Windows 8.1 2013-10-21 2.08.30 8.1 - 2.08.30 WHQL Certified for Win 8.1 Available as setup executable
Windows* 2013-08-01 2.08.30 - 2.08.30 WHQL Certified Available as setup executable
and both of them doesn't work for IDE (in relation to these errors)
The original Arduino IDE\hardware\driver files leads to a crash inside 8.1, I have also played with 8.1 start without check of signed drivers option two, but it didn't work too.
IMPORTANT: Inside Device Manager the COM port is correctly detected and the Serial Monitor is also working correctly.
The monitor and the USB Serial Driver is set to 115200 Bits/s.
The upload itself starts ( RX and TX LEDs are flashing a lot of times, so it seems that the board is getting data from IDE and driver.
At 80% of the progressbar it stops and prints these error outputs... :(
Can you give me detailed information, which driver under which circumstances should be used and how to test it in more detailed way. Perhaps there is something to change inside the Arduino IDE config files?
I think it is a very simple or stupid thing to change but i don't know which it is.
I will buy an original Arduino UNO for my son to play with and will use this one to test the Arduino IDE behaviour too.
Thanks for your help.
Best regards
Wolfgang
The drivers are located at: http://www.ftdichip.com/FTDrivers.htm where you need to choose your OS etc, and it will install automatically. If yours already installed then you can upgrade the driver.
Do you see this behavior on ALL your Moteinos? Let's say a Moteino could be bad for some reason (even though all are tested before shipping). So maybe that one gives the errors, but if all the Moteinos have the same behavior it's almost impossible that all of them are bad, unless something really bad happened during transit. People tend to email me or ask questions as soon as they hit a snag and there's a problem and eventually in 99% of cases it turns out something else is the problem.
So let's try to divide and conquer the problem. Please try the other Moteinos you got as well and see what behavior that exhibits. Ideally try another Arduino or Jeenode or Moteino equivalent.
I run Windows 7 and Arduino 1.5 so I don't know if there are issues related to Windows 8.1 or other Arduino IDE versions. I tend to only use production releases not RC releases since those might be buggy(er).
The newer Moteino-USBs use a FT231Xs chip which is different than the popular FT232RL but it should work with the same FTDI drivers and emulate the serial COM ports the same way, so no difference in behavior.
Hello Felix,
we have found the problem accidentally by playing around with the USB female connector.
By pressing and holding the plug into the connector strongly the upload process is working very well but
we can see that the connecting spring shackle is loose-fitting in relation to the USB male connector.
Perhaps this selected USB article is of of lower quality and should be replaced in the next production batches.
So the problem is in my opinion solved for now.
Best regards
Wolfgang
Good to know, thanks for the update. The FTDI adapters are tested so it's possible this went through the test OK because of the position it was in when plugged in. The connectors are not the most expensive you can get but have not had problems before.