avatar

bboyho

Member Since: August 22, 2011

Country: United States

Profile

Bio

Engineer by day, bboy by night.

Organizations

Delta Chi Fraternity Inc. Worm Tank Crew

Universities

Electrical & Computer Engineering, Dec. 2011 College of Engineering and Applied Science University of Colorado at Boulder

Websites

https://sites.google.com/site/bcelement/home https://www.facebook.com/bboyho

  • When you repower the Logomatic without the USB connector attached, the board will start recording. The STAT0 AND STAT1 LEDs will start logging data.

  • Bricked Atmega32U4

    The ATmega32U4 is more for advanced users so the board can brick you are note careful. I know there are issues that happen when messing with the watchdog timer and sleep modes with the built in CDC driver for USB communication with the Atmega32u4. There might be something similar that is happening in the code using the timer interrupts. I am unsure of how to fix this issue if you continue to use the code. I recommend trying a different method than using the interrupt timers.

    It’s possible that you have used the wrong board selection that also had the wrong frequency which bricked your FioV3. For example, if you upload the wrong frequency, the IC will not be able to understand any new code that is being uploaded to it because it expects to have code that is compiled for the 16MHz bootloader, instead of using the 8MHz frequency with the oscillator on your board. When either of these cases happens, the device manager is not able to recognize the device and is seen as an unknown device when it runs the sketch. There are ways to recover the FioV3 though. Check below for more information:

    Upload when Pro Micro/FioV3 is still in Its Bootloader

    You can try the double reset method by tapping the RST pin to GND twice (since there is no reset button on the board) as indicated in the Reset to Bootloader and How to Revive a “Bricked” Pro Micro section of the FAQ => https://learn.sparkfun.com/tutorials/pro-micro–fio-v3-hookup-guide/troubleshooting-and-faq. As you are still in the bootloader, you can upload code and see it enumerate on a COM port within a 8 second window. This will give you time to select the COM port that the board’s bootloader enumerated to in Arduino IDE. Opening up the device manager on you operating system will help to see when it pops up and disappears. On Windows, this takes about 20 seconds to compile and upload. Trying this on a Mac seemed a little faster to compile and upload.

    I used the Pro Micro test code that was in the tutorial https://learn.sparkfun.com/tutorials/pro-micro–fio-v3-hookup-guide/example-1-blinkies to upload. After selecting the correct board definition and timing the double reset correctly, I was able to upload successfully in the bootloader after bricking it. It took me a couple of tries before I could get this right because of the timing.


    If board is showing up as Arduino Micro (COM##) or Pro Micro (COM##), try the double reset method and updating the drivers while still in bootloader mode:

    1) Use the double reset method while having the device manager open

    2) When the board entered the bootloader mode, I right-clicked on the

    Arduino board in the device manager as shown in this screen shot: http://puu.sh/iaYYC/d45153914c.png

    3) I updated the driver for the board

    4) Once the update was completed, I compiled and uploaded the code. When the uploading status bar was half-way through, I did double reset again and the problem was fixed


    Reinstalling the Bootloader

    As a last result, you can always try to reinstall the bootloader. The tutorial is designed for the Arduino Uno, but we’ve had a lot of people asking about uploading code to the Pro Micro and Leonardo. The idea is the same but the specifics are different. Start by reading the tutorial => https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader. The first thing you are going to need is a programmer. You can use a standard AVR programmer or any Arduino with the ISP code on it (the standard code will not work with the Leonardo). You will then need to connect it to the Pro Micro or Leonardo and upload the code. Don’t worry about the fuse bits or even the avrdude commands (they’re great, if you are installing third party stuff, but this will work just fine).

    Step 1: Get a programmer

    This you can do by following the directions in the tutorial.

    Step 2: Connect the programmer/Arduino as ISP to the Pro Micro, Fio V3, Makey Makey, or Leonardo

    You will need to connect the same pins, on the Leonardo you can connect it just like the Uno, but the Pro Micro does not have an ISP header and the pin numbers are different. Check the tutorial for location of the pins on the programmer. Here are the pins for the Pro Micro Board:

    GND, RST, VCC, MISO (D14), SCK (D15), MOSI (D16)

    Step 3: Program

    Using Arduino v1.6+ go under Tools and select the correct programmer (if your programmer uses a COM port select that too), and the correct board (Pro Micro, FioV3, Makey Makey, or Leonardo). Then select Burn Bootloader. For the Pro Micro, this will use the bootloader in the addon file, so make sure you have the correct addon file installed.

  • Bricked Atmega32U4

    The ATmega32U4 is more for advanced users so the board can brick you are note careful. I know there are issues that happen when messing with the watchdog timer and sleep modes with the built in CDC driver for USB communication with the Atmega32u4. There might be something similar that is happening in the code using the timer interrupts. I am unsure of how to fix this issue if you continue to use the code. I recommend trying a different method than using the interrupt timers.

    It’s possible that you have used the wrong board selection that also had the wrong frequency which bricked your Pro Micro. If you upload the wrong frequency, the IC will not be able to understand any new code that is being uploaded to it because it expects to have code that is compiled for the 16MHz bootloader, instead of using the 8MHz frequency with the oscillator on your board. When either of these cases happens, the device manager is not able to recognize the device and is seen as an unknown device when it runs the sketch. There are ways to recover the Pro Micro though. Check below for more information:

    Upload when Pro Micro/FioV3 is still in Its Bootloader

    You can try the double reset method by tapping the RST pin to GND twice (since there is no reset button on the board) as indicated in the Reset to Bootloader and How to Revive a “Bricked” Pro Micro section of the FAQ => https://learn.sparkfun.com/tutorials/pro-micro–fio-v3-hookup-guide/troubleshooting-and-faq. As you are still in the bootloader, you can upload code and see it enumerate on a COM port within a 8 second window. This will give you time to select the COM port that the board’s bootloader enumerated to in Arduino IDE. Opening up the device manager on you operating system will help to see when it pops up and disappears. On Windows, this takes about 20 seconds to compile and upload. Trying this on a Mac seemed a little faster to compile and upload.

    I used the Pro Micro test code that was in the tutorial https://learn.sparkfun.com/tutorials/pro-micro–fio-v3-hookup-guide/example-1-blinkies to upload. After selecting the correct board definition and timing the double reset correctly, I was able to upload successfully in the bootloader after bricking it. It took me a couple of tries before I could get this right because of the timing.


    If board is showing up as Arduino Micro (COM##) or Pro Micro (COM##), try the double reset method and updating the drivers while still in bootloader mode:

    1) Use the double reset method while having the device manager open

    2) When the board entered the bootloader mode, I right-clicked on the

    Arduino board in the device manager as shown in this screen shot: http://puu.sh/iaYYC/d45153914c.png

    3) I updated the driver for the board

    4) Once the update was completed, I compiled and uploaded the code. When the uploading status bar was half-way through, I did double reset again and the problem was fixed


    Reinstalling the Bootloader

    As a last result, you can always try to reinstall the bootloader. The tutorial is designed for the Arduino Uno, but we’ve had a lot of people asking about uploading code to the Pro Micro and Leonardo. The idea is the same but the specifics are different. Start by reading the tutorial => https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader. The first thing you are going to need is a programmer. You can use a standard AVR programmer or any Arduino with the ISP code on it (the standard code will not work with the Leonardo). You will then need to connect it to the Pro Micro or Leonardo and upload the code. Don’t worry about the fuse bits or even the avrdude commands (they’re great, if you are installing third party stuff, but this will work just fine).

    Step 1: Get a programmer

    This you can do by following the directions in the tutorial.

    Step 2: Connect the programmer/Arduino as ISP to the Pro Micro, Fio V3, Makey Makey, or Leonardo

    You will need to connect the same pins, on the Leonardo you can connect it just like the Uno, but the Pro Micro does not have an ISP header and the pin numbers are different. Check the tutorial for location of the pins on the programmer. Here are the pins for the Pro Micro Board:

    GND, RST, VCC, MISO (D14), SCK (D15), MOSI (D16)

    Step 3: Program

    Using Arduino v1.6+ go under Tools and select the correct programmer (if your programmer uses a COM port select that too), and the correct board (Pro Micro, FioV3, Makey Makey, or Leonardo). Then select Burn Bootloader. For the Pro Micro, this will use the bootloader in the addon file, so make sure you have the correct addon file installed.

  • Bricked Atmega32U4

    The ATmega32U4 is more for advanced users so the board can brick you are note careful. I know there are issues that happen when messing with the watchdog timer and sleep modes with the built in CDC driver for USB communication with the Atmega32u4. There might be something similar that is happening in the code using the timer interrupts. I am unsure of how to fix this issue if you continue to use the code. I recommend trying a different method than using the interrupt timers.

    It’s possible that you have used the wrong board selection that also had the wrong frequency which bricked your Pro Micro. If you upload the wrong frequency, the IC will not be able to understand any new code that is being uploaded to it because it expects to have code that is compiled for the 8MHz bootloader, instead of using the 16MHz frequency with the oscillator on your board. When either of these cases happens, the device manager is not able to recognize the device and is seen as an unknown device when it runs the sketch. There are ways to recover the Pro Micro though. Check below for more information:

    Upload when Pro Micro/FioV3 is still in Its Bootloader

    You can try the double reset method by tapping the RST pin to GND twice (since there is no reset button on the board) as indicated in the Reset to Bootloader and How to Revive a “Bricked” Pro Micro section of the FAQ => https://learn.sparkfun.com/tutorials/pro-micro–fio-v3-hookup-guide/troubleshooting-and-faq. As you are still in the bootloader, you can upload code and see it enumerate on a COM port within a 8 second window. This will give you time to select the COM port that the board’s bootloader enumerated to in Arduino IDE. Opening up the device manager on you operating system will help to see when it pops up and disappears. On Windows, this takes about 20 seconds to compile and upload. Trying this on a Mac seemed a little faster to compile and upload.

    I used the Pro Micro test code that was in the tutorial https://learn.sparkfun.com/tutorials/pro-micro–fio-v3-hookup-guide/example-1-blinkies to upload. After selecting the correct board definition and timing the double reset correctly, I was able to upload successfully in the bootloader after bricking it. It took me a couple of tries before I could get this right because of the timing.


    If board is showing up as Arduino Micro (COM##) or Pro Micro (COM##), try the double reset method and updating the drivers while still in bootloader mode:

    1) Use the double reset method while having the device manager open

    2) When the board entered the bootloader mode, I right-clicked on the

    Arduino board in the device manager as shown in this screen shot: http://puu.sh/iaYYC/d45153914c.png

    3) I updated the driver for the board

    4) Once the update was completed, I compiled and uploaded the code. When the uploading status bar was half-way through, I did double reset again and the problem was fixed


    Reinstalling the Bootloader

    As a last result, you can always try to reinstall the bootloader. The tutorial is designed for the Arduino Uno, but we’ve had a lot of people asking about uploading code to the Pro Micro and Leonardo. The idea is the same but the specifics are different. Start by reading the tutorial => https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader. The first thing you are going to need is a programmer. You can use a standard AVR programmer or any Arduino with the ISP code on it (the standard code will not work with the Leonardo). You will then need to connect it to the Pro Micro or Leonardo and upload the code. Don’t worry about the fuse bits or even the avrdude commands (they’re great, if you are installing third party stuff, but this will work just fine).

    Step 1: Get a programmer

    This you can do by following the directions in the tutorial.

    Step 2: Connect the programmer/Arduino as ISP to the Pro Micro, Fio V3, Makey Makey, or Leonardo

    You will need to connect the same pins, on the Leonardo you can connect it just like the Uno, but the Pro Micro does not have an ISP header and the pin numbers are different. Check the tutorial for location of the pins on the programmer. Here are the pins for the Pro Micro Board:

    GND, RST, VCC, MISO (D14), SCK (D15), MOSI (D16)

    Step 3: Program

    Using Arduino v1.6+ go under Tools and select the correct programmer (if your programmer uses a COM port select that too), and the correct board (Pro Micro, FioV3, Makey Makey, or Leonardo). Then select Burn Bootloader. For the Pro Micro, this will use the bootloader in the addon file, so make sure you have the correct addon file installed.

  • Don’t expect to directly connect the 5V FTDI breakout board to the bottom FTDI header pins on the BC127 breakout board. The Eagle board layout & schematic files show that the Tx pin would connect to your Tx on the FTDi and the Rx to the Rx pin on the FTDI. If you place it on a breadboard or wired the pins appropriately from Tx to Rx and vice versa, you are able to go into command mode with the BC127 through the serial terminal (with settings 9600 8-none-1-none) after entering “$$$$”.

  • Don’t expect to directly connect the 5V FTDI breakout board to the bottom FTDI header pins on the BC127 breakout board. The Eagle board layout & schematic files show that the Tx pin would connect to your Tx on the FTDi and the Rx to the Rx pin on the FTDI. If you place it on a breadboard or wired the pins appropriately from Tx to Rx and vice versa, you are able to go into command mode with the BC127 through the serial terminal (with settings 9600 8-none-1-none) after entering “$$$$”.

  • I think I just responded to your email in tech support after testing it out. You should read my comment https://www.sparkfun.com/products/11447#comment-55d616ab757b7fe5058b4567.

  • To configure the settings of the Wake on Shake, you must power the Wake on Shake with a LiPo or some other power source. A 3.3V FTDI connected will not provide power because the 3.3V pin is not connected. The engineer that designed it this way so that two power sources would not conflict with each other. Your serial terminal output will constantly look like this if you do not power it sufficiently:

    00150
    05000
    :-)
    

    After powering the Wake on Shake and connecting it to your computer’s serial terminal at 9600, 8-none-1-none, it will be actively listening for commands to change the settings. Just start typing the commands and values to configure the settings.

    For example, if you are changing the threshold value as stated in the tutorial, you would start typing “t10010” and hit the enter button (essentially the carriage return or line feed) on the keyboard. Once the Wake on Shake receives the commands, it will return with the happy face:

    :-)
    

    If the command is not properly sent to the Wake on Shake, it will not respond too well and output an unhappy face:

    :-(
    

    After a certain period of time, the microcontroller will go back to sleep and respond with this character output:

    z
    
  • To configure the settings of the Wake on Shake, you must power the Wake on Shake with a LiPo or some other power source. A 3.3V FTDI connected will not provide power because the 3.3V pin is not connected. The engineer that designed it this way so that two power sources would not conflict with each other. Your serial terminal output will constantly look like this if you do not power it sufficiently:

    00150
    05000
    :-)
    

    After powering the Wake on Shake and connecting it to your computer’s serial terminal at 9600, 8-none-1-none, it will be actively listening for commands to change the settings. Just start typing the commands and values to configure the settings.

    For example, if you are changing the threshold value as stated in the tutorial, you would start typing “t10010” and hit the enter button (essentially the carriage return or line feed) on the keyboard. Once the Wake on Shake receives the commands, it will return with the happy face:

    :-)
    

    If the command is not properly sent to the Wake on Shake, it will not respond too well and output an unhappy face:

    :-(
    

    After a certain period of time, the microcontroller will go back to sleep and respond with this character output:

    z
    
  • I was able to read the flashed contents of an ATmega328P in the the" Flash Reading" section of this tutorial https://learn.sparkfun.com/tutorials/pocket-avr-programmer-hookup-guide/using-avrdude. To flash the contents onto another Atmega328P, you would just set the fuse bits, write the saved .hex flie to the target Atmega328P, and set the lock bits. This is similar to what is explained in the tutorial for installing an Arduino bootloader => https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader#uploading-code—hard-way.