Ok let me summarize teknomage’s question/issue:
First of All teknomage in his initial message talks about adding a new component to an OpenBCI board, i dont get specifically , to which board, dongle board or cyton board. If he did it on Cyton Board, It makes sense the flashing problem that occurred on his side, (the GPIO3 is the TX pin of the RFDuino connected to the PIC32) , If he means board the Dongle Board, then it is another story that we can see it further
He uses MacOSX Sierra OS , FTDI drivers for this OS had changed and I haven’t update myself about that old OSX changes on this area, I remember that I had FTDI issues with that version and I had to make a manual tweak on OSX drivers in order to force official FTDI drivers. Since i Use Big Sur OS , I am not sure what is going on anymore.
he mentioned “RadioDevice32bit sketch” that means he hooked up an LED on GPIO3 on the Cyton Board , this is again my guess, if this is true , Cyton board will not longer work properly because there is no PIC32 + RFduino communication
If he did tried to flash the Cyton board with his custom firmware , even he doesnt have an LED on GPIO3 connected after the first time firmware load (with his Win8,1 Machine as he mentioned ), the PIC32 chip can act randomly to the RFDuino because it thinks there is an OpenBCI firmware on the RFDuino chip which is not and who knows the effects on his firmware.
There is also an unknown factor, the Cyton RFDuino development process could involve Variant files changes comparing with the package we share with the public. That means even if you run the same firmware sketch and the RFDuino Package Core files are different than the development RFDuino Package Core files it could generate a firmware that doesn't work as it supposed because of that change small change (in the RFDuino Package Core files like variants.h) that the customer doesn’t have access. I dont know about the Original OpenBCI Development RFDuino Package that the developer could share with you in the office.
I would like to have a more clear plan that what he did exactly in order to follow up. like how many tries had successfully loading firmware before he had the error and what was the order of the binaries he tried, on which board he added the LED on GPIO3 , etc generally speaking his HW and SW setup (an image or scheme would be very helpful)
we can provide our pre-compiled RFduino Firmware and the loader we use in the production Mac as he wish which is not a issue for us
BTW we use 2.1 RFduino loader (it is stock binary, we dont have to modify its binary code) here it is for both windows and mac osx (I never used the Windows version though) . If he is happy with the files , ok.
Please see the zipped file sent separately to your username.
Almost 6 months since my first post about this issue, and I'm happy to say it's finally RESOLVED! Managed to get my hands on an original RFDuino USB shield (#RFD22121) off eBay.. and connected one of my RFduinos to the appropriate pins using jumper wires (this was done standalone though, not yet soldered to either of the OBCI boards). Plugged the USB shield to my PC and allowed it install any required drivers.
IMP NOTE: When you're connecting RFDuino to the shield like this, the Tx pin must be connected to Tx on the shield and RX=>Rx as well (not reversed as how you would have to do so with an FTDI board). Check out the images here:
Next, I setup the programming environment as follows:
On my PC, I started from scratch with a clean installation of Arduino v1.6.x (compilation and upload was successful with v1.8.x as well). I was unable to get Arduino v1.5.8 to upload the hex successfully with the shield, even though that's supposed to be the recommended Arduino version according to the Radio Prog documentation. But this specific version# doesnt seem to be critical for PC as it may be for Mac. Hence, I decided to go with v1.6.6 or .8 at first.
Using Boards Manager, installed the RFDuino board version #2.0.3 initially to experiment with. That's because I deduced this version to be the closest one to what OBCI had originally worked with RFDigital. I had earlier modified the package_rfduino166_index.json file to include ALL the available RFDuino packages from their Github, so you can download any version you want using the Boards Manager. The last updated board version of RFduino is v2.3.3 and that works well too. If anyone wants a copy of my modified json, do let me know
For the compilation to work with any of the RFDuino board versions, a few changes need to be made to the corresponding platform.txt file, specifically wrt the compiler.path, size.script.path, recipe.ar.pattern and recipe.c.combine.pattern (this is similar to the kind of modifications that you would have to make in order to program the Simblee on your Ganglion, just as it is mentioned in the documentation). I do believe others have figured this all out before but I could post the modified platform.txt here, if that's helpful.
Side note: For earlier versions of the RFDuino boards <2.2.4, the files 'size' and 'size.bat' are essential for compilation. So check your RFDuino package installation under: \data\packages\RFduino\hardware\RFduino\2.x.x to make sure that these files are present. If not, you might have to copy & paste these size files from another installation into the above path.
Once all the above is done, check to see if you have an RFduino folder under your Arduino's \hardware\arduino\ folder. If its not there, then I suggest you copy the entire 2.x.x sub-folder from \data\packages\RFduino\hardware\RFduino\ and paste it into \hardware\arduino\ then rename the 2.x.x folder to RFduino. In other words: copy "\data\packages\RFduino\hardware\RFduino\2.x.x\*.*" "\hardware\arduino\RFduino"
(even if you dont copy the entire folder, the RFDLoader.exe file is the most critical, otherwise your compiled hex will not upload)
Finally, hit Version & Compile and then Upload.. and if all goes well, you should see the much coveted SUCCESS alert below:
If you dont want to compile from scratch, then simply use the command below. Navigate to your Arduino's \hardware\arduino\RFduino folder, open Command Prompt there, run this command and you should see the same Success message as above : RFDLoader.exe -q COM# RadioDevice32bit.hex
I have a question here. I followed romankt315's method and it shows success on the Arduino, but I don't know how to test if it is really successful. Also the front D1 diode doesn't light up
@teknomage said:
Almost 6 months since my first post about this issue, and I'm happy to say it's finally RESOLVED! Managed to get my hands on an original RFDuino USB shield (#RFD22121) off eBay.. and connected one of my RFduinos to the appropriate pins using jumper wires (this was done standalone though, not yet soldered to either of the OBCI boards). Plugged the USB shield to my PC and allowed it install any required drivers.
IMP NOTE: When you're connecting RFDuino to the shield like this, the Tx pin must be connected to Tx on the shield and RX=>Rx as well (not reversed as how you would have to do so with an FTDI board). Check out the images here:
Next, I setup the programming environment as follows:
On my PC, I started from scratch with a clean installation of Arduino v1.6.x (compilation and upload was successful with v1.8.x as well). I was unable to get Arduino v1.5.8 to upload the hex successfully with the shield, even though that's supposed to be the recommended Arduino version according to the Radio Prog documentation. But this specific version# doesnt seem to be critical for PC as it may be for Mac. Hence, I decided to go with v1.6.6 or .8 at first.
Using Boards Manager, installed the RFDuino board version #2.0.3 initially to experiment with. That's because I deduced this version to be the closest one to what OBCI had originally worked with RFDigital. I had earlier modified the package_rfduino166_index.json file to include ALL the available RFDuino packages from their Github, so you can download any version you want using the Boards Manager. The last updated board version of RFduino is v2.3.3 and that works well too. If anyone wants a copy of my modified json, do let me know
For the compilation to work with any of the RFDuino board versions, a few changes need to be made to the corresponding platform.txt file, specifically wrt the compiler.path, size.script.path, recipe.ar.pattern and recipe.c.combine.pattern (this is similar to the kind of modifications that you would have to make in order to program the Simblee on your Ganglion, just as it is mentioned in the documentation). I do believe others have figured this all out before but I could post the modified platform.txt here, if that's helpful.
Side note: For earlier versions of the RFDuino boards <2.2.4, the files 'size' and 'size.bat' are essential for compilation. So check your RFDuino package installation under: \data\packages\RFduino\hardware\RFduino\2.x.x to make sure that these files are present. If not, you might have to copy & paste these size files from another installation into the above path.
Once all the above is done, check to see if you have an RFduino folder under your Arduino's \hardware\arduino\ folder. If its not there, then I suggest you copy the entire 2.x.x sub-folder from \data\packages\RFduino\hardware\RFduino\ and paste it into \hardware\arduino\ then rename the 2.x.x folder to RFduino. In other words: copy "\data\packages\RFduino\hardware\RFduino\2.x.x\*.*" "\hardware\arduino\RFduino"
(even if you dont copy the entire folder, the RFDLoader.exe file is the most critical, otherwise your compiled hex will not upload)
Finally, hit Version & Compile and then Upload.. and if all goes well, you should see the much coveted SUCCESS alert below:
If you dont want to compile from scratch, then simply use the command below. Navigate to your Arduino's \hardware\arduino\RFduino folder, open Command Prompt there, run this command and you should see the same Success message as above : RFDLoader.exe -q COM# RadioDevice32bit.hex
Can i have a copy of your modified jsons and modified platform.txt. Thanks a lot
I also faced error "expecting 52, got 53" on MacOS Big Sur when tried to program my Dongle.
I disassembled RFDLoader for MacOS like @romankt315 did before for Windows and patched it to fix a problem.
You can put it to /Applications/Arduino_1.5.8.app/Contents/Java/hardware/arduino/RFduino/ then try to program your Dongle again.
Comments
From an exchange between Ioannis and me -
Ok let me summarize teknomage’s question/issue:
First of All teknomage in his initial message talks about adding a new component to an OpenBCI board, i dont get specifically , to which board, dongle board or cyton board. If he did it on Cyton Board, It makes sense the flashing problem that occurred on his side, (the GPIO3 is the TX pin of the RFDuino connected to the PIC32) , If he means board the Dongle Board, then it is another story that we can see it further
He uses MacOSX Sierra OS , FTDI drivers for this OS had changed and I haven’t update myself about that old OSX changes on this area, I remember that I had FTDI issues with that version and I had to make a manual tweak on OSX drivers in order to force official FTDI drivers. Since i Use Big Sur OS , I am not sure what is going on anymore.
he mentioned “RadioDevice32bit sketch” that means he hooked up an LED on GPIO3 on the Cyton Board , this is again my guess, if this is true , Cyton board will not longer work properly because there is no PIC32 + RFduino communication
If he did tried to flash the Cyton board with his custom firmware , even he doesnt have an LED on GPIO3 connected after the first time firmware load (with his Win8,1 Machine as he mentioned ), the PIC32 chip can act randomly to the RFDuino because it thinks there is an OpenBCI firmware on the RFDuino chip which is not and who knows the effects on his firmware.
There is also an unknown factor, the Cyton RFDuino development process could involve Variant files changes comparing with the package we share with the public. That means even if you run the same firmware sketch and the RFDuino Package Core files are different than the development RFDuino Package Core files it could generate a firmware that doesn't work as it supposed because of that change small change (in the RFDuino Package Core files like variants.h) that the customer doesn’t have access. I dont know about the Original OpenBCI Development RFDuino Package that the developer could share with you in the office.
I would like to have a more clear plan that what he did exactly in order to follow up. like how many tries had successfully loading firmware before he had the error and what was the order of the binaries he tried, on which board he added the LED on GPIO3 , etc generally speaking his HW and SW setup (an image or scheme would be very helpful)
we can provide our pre-compiled RFduino Firmware and the loader we use in the production Mac as he wish which is not a issue for us
BTW we use 2.1 RFduino loader (it is stock binary, we dont have to modify its binary code) here it is for both windows and mac osx (I never used the Windows version though) . If he is happy with the files , ok.
Please see the zipped file sent separately to your username.
Almost 6 months since my first post about this issue, and I'm happy to say it's finally RESOLVED! Managed to get my hands on an original RFDuino USB shield (#RFD22121) off eBay.. and connected one of my RFduinos to the appropriate pins using jumper wires (this was done standalone though, not yet soldered to either of the OBCI boards). Plugged the USB shield to my PC and allowed it install any required drivers.
IMP NOTE: When you're connecting RFDuino to the shield like this, the Tx pin must be connected to Tx on the shield and RX=>Rx as well (not reversed as how you would have to do so with an FTDI board). Check out the images here:
Next, I setup the programming environment as follows:
Once all the above is done, check to see if you have an RFduino folder under your Arduino's \hardware\arduino\ folder. If its not there, then I suggest you copy the entire 2.x.x sub-folder from \data\packages\RFduino\hardware\RFduino\ and paste it into \hardware\arduino\ then rename the 2.x.x folder to RFduino. In other words:
copy "\data\packages\RFduino\hardware\RFduino\2.x.x\*.*" "\hardware\arduino\RFduino"(even if you dont copy the entire folder, the RFDLoader.exe file is the most critical, otherwise your compiled hex will not upload)
Finally, hit Version & Compile and then Upload.. and if all goes well, you should see the much coveted SUCCESS alert below:
If you dont want to compile from scratch, then simply use the command below. Navigate to your Arduino's \hardware\arduino\RFduino folder, open Command Prompt there, run this command and you should see the same Success message as above :
RFDLoader.exe -q COM# RadioDevice32bit.hexI have a question here. I followed romankt315's method and it shows success on the Arduino, but I don't know how to test if it is really successful. Also the front D1 diode doesn't light up
Can i have a copy of your modified jsons and modified platform.txt. Thanks a lot
I have the same problem. Did you have any solutions?
-
I also faced error "expecting 52, got 53" on MacOS Big Sur when tried to program my Dongle.
I disassembled RFDLoader for MacOS like @romankt315 did before for Windows and patched it to fix a problem.
You can put it to /Applications/Arduino_1.5.8.app/Contents/Java/hardware/arduino/RFduino/ then try to program your Dongle again.
GitHub link: RFDLoader