unable to program onboard RFDuino

zwad3

Hi All,

I have successfully installed all of the RFDuino libraries, as well as uploaded the passthrough program to the dongle. I switched the dongle toward GPIO6, connected wires (with a .1 uF capacitor between RST) between the dongle and the board, powered on the board, and attempted to upload a program. However, the Arduino software responded with 

get

fail.......fail.......fail.......

presumably meaning it could not find the device. I should note that it took longer for it to display this message while in contact with the pins, than when unconnected. Any suggestions on how to get it to work? 

biomurph

Do you see the red & green LEDs blink on the Dongle? If so, this is indication that the upload process is happening, however the connection to the OpenBCI Board pads may not be firm enough.

What Board do you have? 8bit or 32bit?

Please make sure that the connection is correct

Dongle FTDI TX goes to Board RF RX

Dongle FTDI RX goes to Board RF TX

zwad3

I do not see the TX and RX led's blinking. Should I see them when the dongle is in FTDI mode? I have a 32bit board, and all of my connections are correct and as firm as I can get them.

biomurph

The Red and Green LEDs are connected to the FTDI IC, and they blink whenever the FTDI chip is RXing or TXing.

Make sure you have a really strong connection to the pads on the 32bit board. 

Maybe needs to be firmer than you think.

The double check again the TX<>RX pairing.

zwad3

Any advice for connecting the pads? I plugged each one via cables into a four-pin header and then connected that to the pads. As far as I can tell, they are making strong contact, but I see no response from the RX and TX LEDs.

chipaudette

I recently reprogrammed my 32-bit boards (it was a 16-channel version, but the main board is the same).  After I got over an issue with the compiler (see post here), I also saw the same "fail...fail...fail..." error.

As Joel said, you have to make sure that you're hitting the pads correctly.  There's no magic there, you just gotta hit them.

Then, I found that there was some additional voodoo that you had to do.  Specifically, I found that I had to have the OpenBCI board turned off during while the program was compiling.  Then, just as the Arduino IDE was about to say "uploading...", I'd quickly turn on the OpenBCI board.  If I got the timing just right (either just before or just after it says "uploading...", I can't remember), the program would upload successfully.  It usually took 3-4 tries.

Joel, can you speak to this part at all?  Do you have to restart the board at just the right time in order to get programming access to the RFDuino?

Chip

zwad3

Hmm, that sounds like an issue with the reset not being hit properly. Presumably that is what the capacitor is for, it fires the reset at the right time thus allowing the RFduino to be programmed. But what you're saying sounds more like manually resetting the RFduino. Regardless, I'll give it a try, thanks.

biomurph

zwad3, that's exactly what the capacitor is for. The DTR pin on the FTDI chip gets pulled low during the upload process, and the cap in series allows the falling edge of that DTR toggle, but then releases the reset so that the RFduino (or Arduino, if you like) comes out of reset and into bootloader mode for that 2 seconds or so.

I have an 8bit and a 32 bit here in front of me, and I'm able to upload the Device code to RFduinos on both of them using the Dongle as a pass-thru successfully.

Try swapping out the 0.1uF capacitor (labeled 104) with a 0.01uF capacitor (labeled 103). 

I do find that all the connections need to be very strong for this to work.

If you continue to have trouble, try using an FTDI breakout from Adafruit or Sparkfun.

Make sure it is a 3V FTDI breakout, or that any selection pads are jumped to ensure 3V logic on the TDI pins.

chipaudette

Note that I was using the RFDuino USB dongle thing (which you show at the end of your docs: http://docs.openbci.com/tutorials/03-Upload_Code_to_OpenBCI_Dongle).  I have not tried it with the OpenBCI dongle.

biomurph

we use those RFduino USB Shields in house for flashing Device code

biomurph

OK ok ok okokokokokok.

I goofed.

The pin connection that I put up on the Docs page is incorrect.

The RESET connection on the Dongle side of things should go to GPIO6, not RESET.

Again, make sure that the slide switch is set to GPIO6, and that you have a connection from GPIO6 to RFRST on the OpenBCI board with a series 0.1uF capacitor.

I'll fix it in the Docs ASAP

doh!

zwad3

Thanks, that did the trick!

bajji93

@biomurph i'm having the same issue. the tx and rx in rfduino blinks, but arduino console im getting 

"get

fail.. fail.. faill.. "

i've made the contact firm.

the connections are perfect as per in the docs (hoping that you've corrected your previous mistake)

powered up the bci board with 6v

capacitor is 0.1uF

what should be the switch position when programming the openbci?? (ble/off/pc) ??please help me out. 

chipaudette

Did you try my voodoo "solution", posted above?

>>>

Then, I found that there was some additional voodoo that you had to do.  Specifically, I found that I had to have the OpenBCI board turned off during while the program was compiling.  Then, just as the Arduino IDE was about to say "uploading...", I'd quickly turn on the OpenBCI board.  If I got the timing just right (either just before or just after it says "uploading...", I can't remember), the program would upload successfully.  It usually took 3-4 tries.

>>>

It's not at all a proper solution, but it did work for me.

Chip

bajji93

@chipaudette yes, I tried the voodoo solution also. Still it didn't work out. I have an 8 bit board. When uploading the device code at different trials, we got in the console like
expected 14, got 00
Expected 14, got 40

What does this mean??

chipaudette

Hmm.  I've never seen the errors that you mention.  Sorry!  Hopefully the guys at OpenBCI have seen those errors and know what to do...

Chip

bajji93

Yea.. @biomurph can answer this I guess

wjcroft

@baji93 , right now Joel is at the SXSW conference. And Conor is at Brain Tech 2015. Both of them supporting OpenBCI for the attendees. (Presentations, answering questions, collaborations, etc.) So Joel will have more chance to catch up when he returns.

https://twitter.com/SafeForRobots
https://twitter.com/russomanno15
https://twitter.com/OpenBCI

http://neurogadget.com/2015/03/12/braintech-2015-day-1-roundup
http://neurogadget.com/2015/03/16/braintech-2015-day-2-from-opportunity-to-startup/11084

bajji93

@wjcroft oh, thanks for the info . can you please check the voltage across the capacitor C45 in the 8bit Board?. I'm getting 0 volts across it. @chipaudette can you please check for the same?

biomurph

@bajji93 can you describe your setup abit more?

Are you using an RFduino USB Shield to connect to the OpenBCI RFduino pin-outs?

If so, you don't need to add a 0.1uF cap. It's already there.

If you can post a photo, that would help too.

moony

Hi there,

I also had the error "expected 14, got 00". I moved my USB connector to the FTDI-chip (usb to serial converter) a bit, then I was able to upload my code to the RFDuino successfully without errors. So it was a faulty USB-connection, even though the FTDI chip was recognized along to /var/log/syslog.


Best regards,
moony

dandan

Hi
I got "expecting 52, got 53
fail.......fail.......fail......." when using RFduino USB Shield to upload RadioDevice32bit.ino

Also got "expecting 52, got 53
fail.......fail.......fail......." when plug Dongle into computer and upload RadioHost32bit.ino

I have double checked TX-RX and RX-TX, but error still exist.
Anyone could give me some suggestions?
Best Regards

AijunHe

I got "expecting 52, got 53
fail.......fail.......fail......." when plug Dongle into computer and upload RadioHost32bit.ino too. Have you solved this problem?

Haofei

@AijunHe said:
I got "expecting 52, got 53
fail.......fail.......fail......." when plug Dongle into computer and upload RadioHost32bit.ino too. Have you solved this problem?

Hi，do you solve the problem now? I meet it too

romankt315

I decided to create my own Dongle, and encountered an error expecting 52, got 53 when loading the code into the RFD22301. After that I downloaded the RFDLoader.exe file from the latest release v2.3.3 and replaced it C:\Program Files\Arduino\hardware\arduino\RFduino\RFDLoader.exe. After that I got the following error RFduino device required for RFduino hex file. Then I used a disassembler to disassemble the RFDLoader.exe. Found a piece of code

Using a hex editor, I made sure that this condition was not met by replacing 74 with 75

This allowed me to upload the code successfully

I uploaded the edited RFDLoader.exe to GitHub
Maybe this comment will help someone

teknomage

I'm experiencing a similar issue with uploading the compiled hex to my RFDuino too.. and this is happening on MacOSx, and partially on Win8.1 as well (and I'll explain what I mean by the partial issue further below). Currently, I'm testing out the RFduinos standalone before I commit them to the Cyton & Dongle boards I got printed. I've followed all the instructions on installing the RFDuino board into Arduino, as well as the required libraries into the respective locations for both OSs. The arduino test code I used is from one of the RFduinoBLE examples.. the only modification I made was to add an LED to the RFduino's GPIO3, so that I can see if there's any response from the RFDuino on startup. Besides that, I paid caution to all the wire connections from the FTDI board to the corresponding RFduino's pins (FT-Tx to RF-Rx, FT-Rx to RF-Tx, FT-DTR to RF-RST through a 0.1uF cap) as described on the Cyton Radio Programming page, as well as other RFduino project pages scattered across the net. Despite all the detailed instructions and precautions, I still get this error on Mac, which is a bit surprising to me:

    RFduino device required for RFduino hex file
    fail.......fail.......fail.......
    An error occurred while uploading the sketch

I'm sure it's not an issue with the wires being loose or incorrectly connected in any way, because surprise surprise! On Windows, I am able to upload the same code successfully to the RFduino from my PC. Much thanks to @Romankt315 for his windows solution above! Initially, I did face the very same fail error on Win as well.. but thanks to Roman's modified RFDLoader.exe which he has graciously provided, I replaced the original exe and when I attempted to upload the code to the RFduino via FTDI, I was able to do so (somewhat) successfully. Now, what I mean by my partial success here is this: any non-BLE section of the code works absolutely fine UNTIL the function RFduinoBLE.begin(); is called inside setup(). For e.g., during the RFDuino's initialization, I can get the LED on pin 3 to light up in setup() but only before RFduinoBLE.begin() is called. Once that line is executed, it's like the RFduino goes into a hang/loop and any successive operations are ignored or not executed, irrespective of whether they are non-BLE or not.

Btw, this can't be a problem with the device itself because when I first tested it out with the stock firmware it arrived with, the LED lit up successfully and blinked during its initial advertising on startup.. and I was able to detect the RFduino using a BLE device scanner on Android (you can do the same with NRF's Connect/Toolbox as well). But after I uploaded the test code to my RFduino, its radio operations have stopped working and I am unable to detect using any scanner now. I can only hope I havent bricked its radio section somehow.

Anyway, I'm curious to know if anyone here has experienced something similar to the issues I've described above?
Also.. I'd like to request if anyone here could provide me with a pre-compiled firmware hex (for RFduino) that I can try burning to my board using RFDLoader directly (i.e., via Command/Terminal), instead of doing it through Arduino's Compile/Upload process. If you can provide a Gdrive link or email me at: t3kn0mage @ gmail (dot) com, that would be most appreciated, thanks!

teknomage

Tested flashing to RFDuino on Sierra MacOsx as well.. did a clean installation of Arduino v1.5.8 and copied the OpenBCI RFduino folder into the package contents as instructed on the Radios programming page. Still no joy, this time the error shows the following.

It's not an issue with the test code coz it compiles successfully. And this is what I've figured out after multiple attempts: the version of RFDLoader provided in OBCI's RFduino archive yields the fail error above.. whereas if I were to switch to a newer version of RFDloader as found through Pert's additional boards manager URL , then I get the earlier mentioned error 'RFduino device required for RFduino hex file' instead!

@biomurph and @wjcroft: Could either of you or anyone from your team please provide an actual working copy of RFDLoader that you guys use to flash RFduinos for your Cytons/Dongles successfully? Or at least compare the executables to find out if they are the very same version or not? There's definitely some discrepancy here.. the problem seems to be with RFDLoader itself and it looks like I'm not the only one facing this issue.

wjcroft

@Shirley, can you arrange to get the working official RFDLoader (binary executable) from the OpenBCI Mac machine, and make it available for customer download? As @teknomage mentions in his two January 25 2022 comments above, flashing the RFduino is working for Windows (with a modified proper RFDLoader binary), but failing for the currently posted Mac RFDLoader.

---

I want to point out to @teknomage, that any issues he is seeing with the very experimental / not-supported, alpha stage BLE code, cannot be easily resolved at this time. As the author A J Keller has moved on, and this code never left the alpha stage of testing. As you may be aware, using the radios in BLE mode vastly decreases the effective throughput. Which is why the production RFduino's use the Gazelle protocol. RF Digital provided special custom libraries to enable the Gazelle feature.

https://openbci.com/community/cyton-ble-code-now-in-alpha/

William

Shirley

@wjcroft, hi

Ioannis can provide the RFD loader, as he's been helping me optimize the Cyton/dongle programming process.
He is on the company slack.

-Shirley

teknomage

@wjcroft: Thank you for addressing this, William. Yes, I am aware of Keller's experimental BLE alpha project but I wasnt playing around with that. When I mentioned the BLE code earlier, I was simply referring to a modification I made from one of the BLE examples provided within the RFduino library itself. I must point out that I was able to successfully compile my simple BLE code, as well as the RadioDevice32bit sketch from the OpenBCI_Radios library, but both failed when it came to finally uploading either of them. To be honest, at this point, I'd just be glad if I can get any of these sketches to be flashed to the RFduino successfully.

By the way, just FYI, I've identified that the version of the RFduino firmware provided by OBCI corresponds with their v2.0.3 package (as evidenced from their CHANGELOG), although the former was modified for OBCI with the optimized GZLL protocol, as you'd mentioned. Nevertheless, just for historical accuracy, the original v2.0.3 package seems to be available from RFduinio's archive here:
https://github.com/RFduino/RFduino/archive/v.2.0.3.tar.gz

@Shirley : Looking forward to the upload, but RFDLoader alone may not be sufficient. It would be great if you or Ioannis could provide a full copy of the entire RFduino package as you have it on your production Mac. Better yet, if you could provide us with a full copy of the production Arduino.app itself, that would be great! (if that's not asking for too much?)

I'm curious to know but could you also verify the exact version# of Arduino being used on that Mac? It's just my suspicion but I do think you might have multiple packages on the Mac, the combination of which is possibly allowing successful flashing of the compiled hex to RFduino on your production system.

for v1.5.8 as stated in the docs, the RFduino package is supposed to be within:
/Applications/Arduino.app/Contents/Resources/Java/hardware/arduino
But if it's v1.6.x or higher, then I suspect the actual RFduino package may be found in the usual Arduino15 location., i.e.,
~/Library/Arduino/packages

I think it's maybe worth looking into, just to see if the RFduino packages in these 2 locations are the same or not?

teknomage

Could someone please help with this issue??