Cyton Bricked with 'error at address'

baffo32baffo32 New England, USA
in Cyton
My Cyton recorded fine last night, but I wanted to change the firmware to use the LED to ensure me it was still writing to the SD card and had not crashed.

After trying to upload my new firmware, my Cyton is bricked.  I can't upload my firmware or the example firmware; everything gives this output:

Sketch uses 88632 bytes (72%) of program storage space. Maximum is 122880 bytes.
Global variables use 10948 bytes (33%) of dynamic memory, leaving 21820 bytes for local variables. Maximum is 32768 bytes.
Programmer for Microchip PIC32 microcontrollers, Version 2.1.24
    Copyright: (C) 2011-2015 Serge Vakulenko
      Adapter: STK500v2 Bootloader
 Program area: 1d000000-1d1fffff
    Processor: Bootloader
 Flash memory: 2048 kbytes
  Boot memory: 80 kbytes
         Data: 88632 bytes
        Erase: done
Program flash: ############################################# done
 Verify flash: ##..........................................
error at address 1D0012B4: file=FFFFFFFF, mem=01000301
error at address 1D0012B4: file=FFFFFFFF, mem=01000301

The address of the error, and the point in the verify process that it happens, changes depending on the firmware file, but stays the same for each particular firmware file.  Although it states programming was successful, the board will not function; the only way to get it to do anything is to put it in bootloader mode.

I've rebooted my system, removed possible sources of wireless interference, placed the dongle and the cyton right next to each other, reflashed the dongle firmware, updated all my arduino and openbci libraries, and changed the poll time to 255 ms.  Still gives the same issue.

The only remaining avenues I've come up with are to try another board (which I don't have right now), to try reflashing the cyton radio firmware (which I don't have the tools for right now), or to try bypassing the radios and programming the chip manually (which I don't have the tools or knowledge for, and seems like a lot of work if some piece of the board is just dead).

I found a mention of this issue from 2015 at http://openbci.com/forum/index.php?p=/discussion/208/chipkit-uploading-tips-restarting-bootloader/p3#Comment_3243, but there is no reply regarding it.

I also found this issue described in 2016 at https://github.com/OpenBCI/OpenBCI_NodeJS/issues/87 but the issue was closed without resolving it.

Has anybody else encountered this issue before, or have any ideas or advice?  Could somebody from OpenBCI acknowledge it?

Comments

  • pushtheworldpushtheworld
    @baffo32 I've never seen this problem.

    What firmware did you upload? Normally the system cannot be bricked and can always be reflashed. That is troubling that this stopped working! 

    That poll time seems a bit too long, try moving it down to ~60-80ms.

    Did you open an issue with contact @ openbci . com? Maybe @biomurph has seen this issue before.

    The board never boots? Or the board always fails at the same memory address? 

    You should try using another computer to upload the code!


  • baffo32baffo32 New England, USA
    Thanks a bunch AJ.

    Along with my custom firmware, I’ve also tried the two external buttons example firmware, both of which fail today and worked yesterday. The board never boots; I don’t have a debugger to see at what memory address the boot process fails. The verification failure occurs at the same address each time for different runs, but different addresses for different firmware blobs.

    I’ll lower the poll time, try another computer, and email the contact address next!
  • pushtheworldpushtheworld
    "both of which fail today and worked yesterday." oh my gosh this does not sound good! 

    Yea try the different computer and lowering the poll time. and please email openbci if this persists, something is up!
  • baffo32baffo32 New England, USA
    Well, I contacted OpenBCI, but they didn't provide any help yet.  I also tried other computers, which didn't work, and changing the poll time, which didn't work, and flashing the factory board firmware, which didn't work, and using a new radio dongle, which didn't work.

    I bought a new cyton, and it works, with all the radio dongles.  I can't seem to figure out how I broke my old boards, in order to break the new board in the same way.  It's just working. Which is great.

    I had two Cytons, and both of them broke with the same error.  Maybe some old-age thing?  Maybe some local electromagnetic disturbance fried them?  Maybe the new Cyton has better bootloader code that avoids something that happened to the old cytons?

    But it seems one solution is to buy a new Cyton.  I've also bought a PIC programmer, so if it happens again I'll try to look at the situation in more depth.
  • wjcroftwjcroft Mount Shasta, CA
    Baffo, I see you are in New England, which in the winter sometimes creates situations of considerable static electricity. Are you taking care to ground yourself before touching circuit boards? The channel input pins are protected, but other traces on the board (most of the board's surfaces) cannot be protected in this manner. There are some Cyton case designs out there.

    William

  • baffo32baffo32 New England, USA
    William, thank you. I hadn’t thought about static discharge and have been treating the boards like any old object. I’ll take more care now.

    Do you think there might be some component I could replace on the boards to get them working again?
  • wjcroftwjcroft Mount Shasta, CA
    Mentioning @openbci and @biomurph.

  • wjcroftwjcroft Mount Shasta, CA
    Baffo, I would first try reflashing the chipKIT / PIC bootloader with your PIC programmer. Here's an old thread, kind of long, you might try looking from the last page backward for more recent posts.


    Seems like there should be a more concise and organized PIC programmer tutorial, but I'm not sure where.

    Joel @biomurph may have better suggestions. Unclear if this is confused bootloader firmware, or some deeper hardware damage. But your output on the first post of this thread indicates PIC is somewhat alive. This could also be damage on the onboard RFduino (called the Device radio; vs the Host on the dongle.) The docs site does cover how to reload the onboard RFduino.


  • pushtheworldpushtheworld
    Did you ever try emailing [email protected]? Then joel can help you, because that's the best way to reach biomurph.
  • baffo32baffo32 New England, USA

    They got back to me, but I have a third board now that works. I’m thinking of waiting for it to break too to keep pursuing this, unless I happen to stumble upon a convenient spot to beat my head at it more.
Sign In or Register to comment.

© Vanilla Keystone Theme 2026