chipKIT uploading tips & restarting bootloader

roman3017 · December 2014

I have bricked my 32 bit board. Can you please post instructions to do factory reset? I do have a JTAG for ChipKit.

roman3017 · December 2014

I have uploaded unaltered OpenBCI_32bit_16chan.pde sketch to the board from mpide. The board was set to chipkit-max32-usb for serial. Afterwards board is dead, leds are off. Is there a way to reset/reprogram it? What is the correct board setting?

roman3017 · December 2014

I was able to program bootloader UDB32-MX2-DIP.hex from:

https://github.com/chipKIT32/PIC32-avrdude-bootloader/tree/master/BootloadersCurrent-hex

using PICkit3. The blue LED is happily blinking when I power up the board and board is waiting to be programmed from mpide. Can someone please let me know which board configuration should I choose in mpide in order to program 32bit OpenBCI? I have tried also Fubarino SD (1.5) with no luck, even though this time at least chips match. If there is a need to create a new configuration, please let me know as well that I do not have to try existing ones in vain.

Regards,

Roman

roman3017 · December 2014

I started to create a new configuration based on Fubarino Mini. In order to finish it, I need the current schematics or at least pin out for OpenBCI v3 board. Unfortunately, I cannot locate it. Can you please let me know the location of it? This was advertised as an open source project. Is it not anymore?

Thanks,

Roman

admin · December 2014

Hi roman3017,

Can you describe how you bricked the board??

Is there an issue that could trap other users?

Please go here for the latest OpenBCI 32bit code

https://github.com/OpenBCI/OpenBCI_32bit

There are two changes that you need to make to the mpide in order to work with our system.

Notes in the read me and at the top of the main code page describe the adjustment to mpide library file DP32/Board_Defs.h

Those changes need to happen, otherwise there will be no useful spi communication

The 'board' selection from the tools menu should be 'chipKIT DP32'

Thank you for hacking our harware!

roman3017 · December 2014

Thanks, your instructions work and the board is up and running again. Changing DP32/Board_Defs.h did the trick. One can brick the board by uploading sketch with board selection 'chipKIT DP32' without changing MISO and MOSI pins. When that happens, one needs to use a programmer like PICkit3 and flash the bootloader. Afterwards mpide will work again.

Regards,

Roman

biomurph · December 2014

We had this problem once here in the lab.

We were able to re-program the 32bit boards without needing to re-flash the bootloader.

Here's how you put the PIC into bootloader mode:

Press the RESET button, and hold it down.

Press the PROG button and hold it down.

Release the RESET button, then release the PROG button.

The blue LED will blink pleasantly, and the PIC will be happy to take new code.

Or, press the RESET button again to restart with the code that's already on there.

When the PIC comes out of RESET with the PROG pin closed, it will enter bootloader mode.

Arale · January 2015

Hi All,

I'm interested in the way you reflashed the bootloader into the PIC.

I'm using mplab ipe and a pickit 3, I could program the bootloader UDB32-MX2-DIP.hex without any problems.

However when I try to upload the openbci_32bit program throw the RFduinos into the PIC with mpide I get this message :

avrdude: verification error, first mismatch at byte 0x4500

0x21 != 0xff

avrdude: verification error; content mismatch

I was wondering if there were some special options I had to select in mplab before programming the bootloader?

Thanks!

Arale.

roman3017 · January 2015

There was nothing special.

I connected pickit3:

pickit3 pin -> openbci pin
1 ~mclr/vpp -> j4.2 rst
2 vdd -> j3.3 vdd
3 vss/gnd -> j3.4 gnd
4 pgd/icspdat -> j4.4 d11
5 pgc/icspclk -> j3.2 d12
6 pgm/lvp -> open

when powering the board I followed:

http://www.microchip.com/forums/m593399.aspx

I redefined miso/mosi pin as described in:

http://docs.openbci.com/tutorials/02-Upload_Code_to_OpenBCI_Board

Regards,

Roman

roman3017 · January 2015

As admin wrote: the 'board' selection from the tools menu should be 'chipKIT DP32'

biomurph · January 2015

Hi Arale,

We have found that some of the 32bit boards will present an error after uploading.

Errors can happen because we are doing the programming over-air with avrdude.

The avrdude process is to first, make contact and verify the target part, then the code uploads in pages (for PIC, the pages are ~256 bytes. for ATmega, the pages are more like ~128 bytes).

Then, the avrdude verifies the code by getting the PIC to send it back.

On the occasions where there was a content mismatch, the problem could happen in either the upload, or the verification part.

If the mismatch is on the verification, then it's likely that the code was uploaded ok. Check to see if the blue LED is on, and if it is, try to run the board.

If the blue LED is not on, then the mismatch happened during upload. You will need to try to upload again. Try and try again, and it will eventually stick. We were able to load code on all the boards we shipped, so it will work, please be patient.

Some things that we found help:

Turn on the board after the dongle is plugged in (start the Host radio before the Device radio)

Hold the RST button down, turn on the board, then press the PROG button and hold it while releasing the RST button.

(that last one is alittle bit 'baseball superstition, but anyway...)

Keep the board and the dongle in close proximity with the radios facing eachother.

Arale · January 2015

Hi, thanks for your answers.

When I flashed the bootloader a few days ago I used exactly same setup you proposed and I had a message saying the process went well. I think this was OK.

After uploading with mpide, the blue led wasn't on when I switched on the board.

I was going to upload until it was OK as you proposed. I did your "baseball superstition trick" before uploading but something very strange happened. After pushing the reset button the led became and remained blue after an OFF/ON...

I guess the last upload I did yesterday was ok after having a verification error.

I can't explained what happened but anyway, every thing is ok now!

Thanks again.

Arale

alfahad · January 2015

Hi everyone,

I am having a trouble uploading new firmware to my 32-bit board. I followed all the steps mentioned here:

http://docs.openbci.com/tutorials/02-Upload_Code_to_OpenBCI_Board#upload-code-to-openbci-board-32bit-how-to

but I am getting the timeout error. I have tried to do it both on Mac OS X Yosemite & Windows 7 PC.

Binary sketch size: 53996 bytes (of a 122880 byte maximum)

avrdude: stk500_2_ReceiveMessage(): timeout

avrdude: verification error, first mismatch at byte 0x00fc

0x58 != 0x5c

avrdude: verification error; content mismatch

Before Upload: Dongle has blue LED steady, & board blink pleasantly (in programming mode).

During upload: The dongle start blinking (red & green) and the board blink rapidly (after it starts receiving new data)

Then the dongle stop blinking (red & green) and the board stop blinking (no LED light).

I don't know how to solve this issue?

Also, is there any other way to upload firmware by wire to overcome these issue?

It's good to mention that it doesn't even work with original sketch found here:

https://github.com/OpenBCI/OpenBCI_32bit

One last thing: I tried to upload the blink sketch below, but I didn't work.

/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.
This example code is in the public domain.
*/
void setup() {
// initialize the digital pin as an output.
// Digital pin 24 has the LED connected to it
//For more information including a pin diagram please visit www.chipkit.net/diy-chipkit-board
pinMode(24, OUTPUT);
}
void loop() {
digitalWrite(24, HIGH); // set the LED on
delay(1000); // wait for a second
digitalWrite(24, LOW); // set the LED off
delay(1000); // wait for a second
}

The error for all sketches is the same. I am guessing it has something to do with bootloader (which I am not really familiar with).

Any help is appreciated.

wjcroft · January 2015

I merged the post above from @alfahad re: "avrdude: verification error", into this thread. Where Joel has some related uploading tips.

alfahad · January 2015

This hint solved my problem

Some things that we found help:

Turn on the board after the dongle is plugged in (start the Host radio before the Device radio)

Hold the RST button down, turn on the board, then press the PROG button and hold it while releasing the RST button.

Also, I placed the board close to the dongle.

Thanks a lot

alan_zhang · February 2015

Hi,

We get similar error:

avrdude: verification error, first mismatch at byte 0x125c

0xff != 0x01

avrdude: verification error; content mismatch

Tried multiple times as hinted and did not work.

biomurph · February 2015

It is known that there may be sometimes a verification error when uploading to the 32bit board.

We know that uploading will work, because we were able to upload to all of the boards before we shipped them to you.

Please be patient and try again. It is bound to work.

@alfahad, The upload process happens over the serial connection between RFduino and the PIC.

It may be possible to green wire the board and use a wired connection, however the RFduino pins will also be connected. The RFduino in that case would need firmware that puts the RX|TX pins in highZ so they don't interfere.

refurbished · March 2015

We get the similar error:

avrdude: verification error, first mismatch at byte 0x125c

0xff != 0x01

avrdude: verification error; content mismatch

Tried more than 15 times and did not work. Put the antennas close together, wrap everything in ALU,go to a room with

no 2.4 GHz sources: no change; error again.

Then we connected the chipKIT Programmer to J3/J4, but no way to load

because we have no binary.

At last we wired the dongle withe the board: RFTx -> FTDI_Rx RFRx -> FTDI_Tx and the two GND's.

The RFRST -> GND and the Dongle RESET to GND (afterwards RESET to GPIO6).

But there is no transmission, only FTDI_TX will show some Bytes every 10 seconds or so.

We have ordered 5 more boards, but we need this one very shortly having it running again.

refurbished · March 2015

Or could somebody

make a image of his system with picit3 or the chipkit pgm

with MPLAB IPE (the Flash-Program software)

and load the image to github

(and/or please send it to my gmail: asec14)

for use with the MPLAB IPE

by using the picit3 or the chipkit pgm?

I see no other way for the problem

to solve today and get the OpenBCI alive again!

Fast help is so apreciated!

refurbished · March 2015

First had to start a praise session,

then I discovered my error,

now downloaded,

and it runs again (Blue LED is ON!)

I had to connect to:

OpenBCI 32 Bit Board Pin 3 RFduino -> Dongle FTDI_TX

OpenBCI 32 Bit Board Pin 4 RFduino -> Dongle FTDI_RX

OpenBCI 32 Bit Board AGND to Dongle GND

Dongle RESET to GND elsewhere

OpenBCI 32 Bit Board RFRESET to AGND

alfahad · April 2015

Hi guys,

How can I upload the code to Chipkit board (OBCI V3) directly without relaying on Rfduino?

would it help expedite the process? because I am having a lot of erros when I try to upload it. Once every 15, I get it to work.

Also, what is the best way to debug a Mpide sketch?

Thanks

biomurph · April 2015

@alfahad The way we have the boards set up, it is easiest to upload over the RFduino link.

You could, of course, hack the board and do it directly over wires.

Also, we have more tutorials up about putting signals into the OpenBCI, and making the OpenBCI generate signals.

http://docs.openbci.com/tutorials/04-External_Trigger_8bit_Example

alfahad · April 2015

@biomurph Do you think hacking the board using @refurbished 's way below, would make the uploading process easier and more reliable?

refurbished 's way :
//////
I had to connect to:

OpenBCI 32 Bit Board Pin 3 RFduino -> Dongle FTDI_TX
OpenBCI 32 Bit Board Pin 4 RFduino -> Dongle FTDI_RX

OpenBCI 32 Bit Board AGND to Dongle GND
Dongle RESET to GND elsewhere
OpenBCI 32 Bit Board RFRESET to AGND
//////////

biomurph · April 2015

I'm not sure, alfahad.

refurbished, can you show a picture of the setup and/or some kind of schematic?

jgottlieb · April 2015

I have a 32 bit board. I have previous successfully streamed ECG and EEG data to the OpenBCI GUI. I am using a Mac.

I was going through the instructions to make sure that I could flash new firmware. I successfully flashed the firmware from GitHub with no problems, and the board still worked.

I then made one minor change, commenting out line 112: sampleCounter++;

When I tried to load that, I had a bit of trouble in that I kept getting timeout errors. Eventually, I got it to start loading, but it didn't look like it finished. However, I was able to connect the board to the GUI and stream data with the appropriate change in the output reflecting that my code had been uploaded.

I uncommented that line and tried to flash it again. I have had no success, and now the blue LED does not light up and I cannot communicate with the board at all. When I tried this second flash, it seemed to work for a while and then I got this error:

avrdude: verification error, first mismatch at byte 0x1d00

0x70 != 0xff

avrdude: verification error; content mismatch

Since this point, I can get the blue LED to slowly flash by holding down the RST and PROG buttons as per the instructions, but after a few seconds the LED starts flashing very quickly and mpIDE just reports a bunch of timeout errors:

avrdude: stk500_2_ReceiveMessage(): timeout

If I let it just keep running, eventually I get the same verification errors I posted above.

The GUI can no longer detect the board. I have power cycled the dongle and the board several times with no success.

Thoughts?

wjcroft · April 2015

@jgottlieb , thanks for your post. I've merged it into this existing thread.

jgottlieb · April 2015

Okay. I can at least get it to talk to the board now, but after flashing the firmware straight out of the repo about 20 times now, I still get the verification error.

To head off some of the common suggestions I keep reading - I have put new batteries in the batter pack, the board the the dongle are roughly 0.5 cm apart with the radios directly facing each other, and after I get the error the blue light is off.

Is there a way to re-flash the bootloader without a picKit3? I might have a 2 somewhere, but I know I don't have a 3.

I'll keep trying, but if anyone has a better suggestion than "cross your fingers and pray" I'm all ears.

alfahad · April 2015

I don't think you need to flash the bootloader, I suggest you try this trick:

Turn on the board after the dongle is plugged in (start the Host radio before the Device radio)

Hold the RST button down, turn on the board, then press the PROG button and hold it while releasing the RST button.

One thing I usually try is uploading the "Blink Example" using LED=11. Usually it's a good indicator for me before trying to upload the "large" code. If the blink example doesn't upload, I usually restart the MPIDE program (since I'm using 32-bit board), and try to re-upload the blink example.

http://chipkit.net/arduino-blink-sketch-chipkit-dp32/

biomurph · April 2015

@jgottlieb, why do you want to comment out the sampleCounter++ ?

That is a super important line of code...

In regard to all of the issues with timeouts and mismatches, we are working closely with the folks at Microchip chipKIT to get this issue resolved. I believe that it has to do with the code uploader (avrdude) that is used with the current release of mpide.

the chipKIT folks are in the process of changing that in the new chipKIT core. And they will also include OpenBCI 32 as a selection in the Board drop-down menu selector {exciting!}

In maybe a few days (next week?), I will reach out to this thread with instructions and links to ask you all to test the new setup.

Thanks for your patience with this!

jgottlieb · April 2015

I was only doing it to test and make sure I could properly do a firmware flash.

Out of curiosity, why do you think it is an important line of code? The only utility, so far as I can tell, is to allow the receiving computer to determine if any packets have been dropped. My long-term goal is to use the OpenBCI alongside experiments manipulating cognitive state. In this context, a one-byte counter is not nearly as important as the need for a millisecond timer that can be synchronized with the computer so I can align data collected by the OpenBCI with events taking place in the experiment.

This was ultimately what I was going to try to implement yesterday, but instead I spent the afternoon trying to figure out why the board failed after only the second time I tried to flash new firmware.

biomurph · April 2015

Well, it's important because it is our sample counter, and it is the way that we keep track of data packets to know if any have been dropped, etc. Because we are sending data over air, there may be some latency that a timer on the computer would throw a flag over.

chipKIT uploading tips &amp; restarting bootloader

Comments

chipKIT uploading tips & restarting bootloader