Can't flash dongle, uart_win.cpp error -> fixed with CDM v2.12.28 driver

edited January 2018 in Cyton
I followed the steps at docs.openbci.com/Hardware/ to program the dongle with the latest firmware, but when I try to upload, I get the following:


Sketch uses 31,108 bytes (23%) of program storage space. Maximum is 131,072 bytes.
Assertion failed: rc == TRUE, file uart_win.cpp, line 107

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I have checked the steps several times, and have performed the entire tutorial on three different machines, each one producing the same result. Is this an indication that the dongle hardware is damaged?
Also: Serial monitor in Arduino shows a constant stream of 0x01 0x60 0x01 0x60 0x01 0x60... from the dongle. Is this normal?



Comments

  • Are you putting the switch on the dongle into the RESET postion?
  • Yes, the switch was as indicated in the instructions.

    What I eventually did that worked was to change the driver and force it (against Windows's protest) to an older one (in particular, it was CDM v2.12.28 that worked).

  • This happens on Linux with Wine now too, after following the instructions to make a script that calls RFDLoader.exe using wine but with forwarding of the COM port. Current radio documentation is missing a link to the script, but some clever googling led me to this comment on a github issue: https://github.com/openbci-archive/Docs/issues/73#issuecomment-288889646 -- it suggests replacing RFDLoader with the following script.

    #!/bin/bash
    mkdir -p ~/.wine/dosdevices
    ln -sf "$2" ~/.wine/dosdevices/com9
    wine "$0".exe "$1" com9 "$3"
    

    Unpacking what this does, it replaces the OSX RFDLoader binary with a linux bash script that uses wine to call the RFDLoader.exe application. It starts by making sure the ~/.wine/dosdevices folder exists within your home directory, then symbolically links the port you selected in arduino to the com9 file in that dosdevices directory. Apparently any windows executable that tries to act upon "COM9" within the wine runtime will be redirected to the port that's been symbolically linked in that directory.

    The current issue is that as of WINE 2.8+ you can no-longer just symbolically link devices in this folder -- it's actually actively managed by the wineserver and you need to execute several "regedit" commands to change the mapping of the devices. Unfortunately this also means that the script probably won't anymore with recent versions of WINE.
    https://wiki.winehq.org/index.php?title=Wine_User's_Guide&oldid=2519#Serial_and_Parallel_Ports

    I'm working around the issue for now by checking which com port is associated with my board by running

    ls -lah ~/.wine/dosdevices
    

    The output shows me that one and only one of these ports is pointing to my board (currently at /dev/ttyUSB0)

    ...
    lrwxrwxrwx 1 username username   11 Aug 26 15:27 com32 -> /dev/ttyS31
    lrwxrwxrwx 1 username username   12 Aug 26 15:27 com33 -> /dev/ttyUSB0
    lrwxrwxrwx 1 username milsagw1   10 Aug 26 15:27 com4 -> /dev/ttyS3
    ...
    

    I've temporarily edited my script as such:

    #!/bin/bash
    wine "$0".exe "$1" com33 "$3"
    

    I don't think this will be robust to changing the USB port I plug the dongle into.. There should be a way to adapt the script to look at the symbolic links in the directory, then fill in the correct com port in the wine command, but I don't have the time for that right now.

Sign In or Register to comment.