V2 firmware upgrade questions on Cyton

wEEtoZ · November 2016

Hi!

It started when we wanted to add an external trigger button to the system. We found out that it would be best to have firmware 2.0, so that we could send auxiliary data instead of acceleration data. After updating to 2.0 code with external trigger, the signals went haywire. In OpenBCI_GUI, all signals went to the roof and had some harmonic properties. Then we thought it might be something with the bluetooth dongle, so we started updating firmware to 2.0 on both device and host side. This was a bit tricky with the cabling and all, but we managed it at last, with some magic involved. When the firmware was updated on bluetooth dongle, the OpenBCI_GUI program stopped working. There were no signals at all when we started the data stream. So now we are out of options, what do we do?

Can it be that we tried to upload 2.0 code before updating dongle to 2.0? Could it be something else?

Please help us. We are having a project regarding OpenBCI, and would really like to move on with it.

Thanks in advance.

wjcroft · November 2016

Mentioning AJ Keller @pushtheworld and Joel @biomurph . AJ is the V2 firmware developer.

Have you also tried the new GUI release?

https://github.com/OpenBCI/OpenBCI_GUI_v2.0

http://docs.openbci.com/tutorials/04-Updating_Custom_Firmware_to_2.0

William

wEEtoZ · November 2016

Hi again, and thanks for the answer William. We have not tried the new GUI, but we think that the problem lies with the RFduino flashing, since we don't get any communication between device and host. We wrote the correct channel in both ends, and followed the guide for updating radio to 2.0. When we try to send "b" through serial we receive this message: "Failure: Communications timeout - Device failed to poll Host". Any idea what is wrong?

wjcroft · November 2016

Wee, hi.

I'm really shooting in the dark here because I'm not running the V2 firmware. RE-MENTIONING @pushtheworld, in hopes that he may have some suggestions.

Colin @cfausn has written a configuration utility. Have you tried using that to possibly see if that can get both RFduino's onto the same channel?

http://openbci.com/community/openbci-radio-configuration-utility/

William

pushtheworld · November 2016

@wEEtoZ did you upgrade all three microcontrollers?

Please follow this upgrade guide here: https://github.com/OpenBCI/OpenBCI_32bit_Library/blob/master/UPGRADE_GUIDE.md

There are also links to in-depth tutorials: https://github.com/OpenBCI/OpenBCI_32bit_Library/blob/master/UPGRADE_GUIDE.md#in-depth-tutorials

@wjcroft thanks for emailing me, I did not get an email notifying that you tagged me!

pushtheworld · November 2016

Also here is an example of two external triggers: https://github.com/OpenBCI/OpenBCI_32bit_Library/blob/master/examples/BoardWith2ButtonExternalTriggers/BoardWith2ButtonExternalTriggers.ino

wEEtoZ · November 2016

@pushtheworld:

We upgraded all three microcontrollers.

What we did:

Uploaded new firmware to microcontroller
Noticed weird signals when using OpenBCI GUI program
Assumed it had something to do with not updating bluetooth host and device to the V2 firmware as well
Updated the dongle with the pass-through firmware
Tried to update the device RFduino
Had some problems with uploading in arduino software, had to turn the BCI board ON right before "Uploading..." in arduino showed up. It would not upload if it had been on for at least a few minutes. Is this intended behaviour?
Updated the dongle with the firmware, and it would not connect to the device RFduino and we cannot update the arduino firmware.
We expect that the problem lies in the communication part between host and device.

Help will be apprectiated.

pushtheworld · November 2016

So step five was not successful? What microcontroller are you referring to in step 6? Step 3 sounds like an accurate assumption.

The order of programming is listed here as well in the upgrade guide https://github.com/OpenBCI/OpenBCI_32bit_Library/blob/master/UPGRADE_GUIDE.md

It sounds like you had trouble "Uploading code to the RFDuino Device radio found on the Board", if so, be sure to follow the tutorial found here: http://docs.openbci.com/tutorials/03-Upload_Code_to_OpenBCI_Dongle#uploading-device-firmware-to-openbci-board-overview-upload-device-radio-firmware-version-2xx-fall-2016

pushtheworld · November 2016

To understand the importance of why all three microcontrollers must be updated please see here: http://docs.openbci.com/tutorials/04-Updating_Custom_Firmware_to_2.0#updating-and-using-v200-32bit-firmware-sending-data-packets-from-the-pic32-to-the-pc

wEEtoZ · November 2016

Hi again @pushtheworld

We re-tried all the steps now, and it seems like the new firmware on Radio is got uploaded like it should, on both device and host ends. But when we tried to upload the "DefaultBoard" to the PIC32, we did not find the target. Does this mean that device and host firmware update did not work? Or could it be anything else? Is there some other way to test if the RFduino is working?

pushtheworld · November 2016

@wEEtoZ are you sure they are on the same radio channel? Sounds like that would be the issue if you cannot find the target (Pic 32). That error is seen when you the uploader sends a status message and does not receive, so it's like they are not even talking, which would point me to ensure they are both on the same channel.

First either use the Radio Config Utility, a terminal program like coolterm, or the node.js driver to get the radio system status.

Sending a 0x07 (that's a single hex byte, not an ASCII string) will either return "Success: System is up$$$" or "Failure: System is down$$$" which indicates if the Host and Device are communicating.

If you verify that the system is down, somehow during flashing the radio channels were not the same. You now need to override the Host's channel number to match that of the Device's channel number. You do this with the node driver here, the radio config utility has an auto scan feature which will loop through all channels and keep sending status messages till the channels are aligned or all channels have been tried.

If you are unable to align the two devices through overriding the Host's channel number, you could try reflashing both the Host and Device, twice, with the line "radio.flashNonVolatileMemory()" in the setup function, see the "important" section in the tutorial docs. The radio channel numbers are now stored to non-volatile flash memory so you can change the radio channel of the system with a 0x01 (that's a single hex byte, not an ASCII string) and both the Host and Device will change their radio channels. Note: the system must be communicating too.

Good luck! Let me know how it goes!

wEEtoZ · November 2016

@pushtheworld

Seems like we managed to upload the code at last. The channels were correct. We tried to flashNonVolatileMemory() on both Host and Device, and then it seemed to work. There is no description to run the flashing on Host side in guide, but I don't know if it was just pure luck or the fact that we needed to do that. We have uploaded "DefaultBoard" code now, and will try to get it to work. If not, we will come back to you :-)

pushtheworld · November 2016

Make sure to uncomment or remove flashNonVolatileMemory() because you do not want to flash every power cycle!

It sounds like your channels were not correct if flashing the non-volatile fixed it... well I think this thread will help people so thanks for it! Also glad to hear you're up and running! Get those brainwaves!!!

yj · November 2016

Hello,
@pushtheworld.

The setup function in question is well this one? :
void setup() {
// Declare the radio mode and channel number. Note this channel is only
// set the first time the board powers up OR after a flash of the non-
// volatile memory space with a call to `flashNonVolatileMemory`.
// MAKE SURE THIS CHANNEL NUMBER MATCHES THE HOST!
radio.begin(OPENBCI_MODE_DEVICE,20);
}

If yes, does this following blue line Important! As of firmware version 2, you must first flash the board with the line radio.flashNonVolatileMemory(); in the setup() function uncommented    simply means :   "add in the setup function the instruction radio.flashNonVolatileMemory(); and flash the board".

If yes, should we write it before or after the line   radio.begin(OPENBCI_MODE_DEVICE,20) ;   ?     ( the order could be important... )

    Sincerely,
      y.j.

pushtheworld · January 2017

To fix "no target found" aka misaligned radio channels please use the new GUI and simply press AutoScan

http://recordit.co/V7MssXWTUR

mbamonte · July 2019

Hi, I'm also trying to upgrade the RFduino firmware, and also have the same doubt: which order should I add the radio.flashNonVolatileMemory() command? I followed these steps but no sure if it's ok:

step 1):

void setup() {
radio.flashNonVolatileMemory();

radio.begin(OPENBCI_MODE_DEVICE,20);

}

step 2):

void setup() {
//radio.flashNonVolatileMemory();

radio.begin(OPENBCI_MODE_DEVICE,20);

}

Skalbe · July 2019

@mbamonte

http://openbci.com/forum/index.php?p=/discussion/2223/is-my-cyton-broken-non-responsive-after-attempted-firmware-upgrade#latest

mbamonte · August 2019

Thank you @Skalbe!! It worked perfectly!

V2 firmware upgrade questions on Cyton

Comments