I am new in this. Bought Atmega8a mcu to have some fun with it. But I am unable to program it using arduino uno rev-3. Haven't used any external parts to program it. Just connected the chip as below:
Arduino pin 10 to chip pin rst,
Pin 11 to MOSI,
Pin 12 to MISO,
Pin 13 to SCK,
Connected vcc and gnd to chip pin 7 & 8,
Also used an 10 uf cap, arduino rst to gnd.
Trying to upload the bootloader using arduino ide 1.6.9. It says:
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override this check
Am I missing something?
Most minimal AVR setups include a 10k pull-up resistor on the reset pin. Are you sure you don't need one?
Arduino target cpu (or variant) must be ATMega8A.
"Invalid signature" is not so verbose - it says nothing. Enable verbose log for avrdude in Arduino setting.
If signature is slightly different from actual one, it's selected variant problem.
If it's something like 0xFF or 0x00 it's usualy wiring, reset or missing xtal problem.
Bootloader needs correct xtal/resonator (AVR runs from internal 8MHz clock and it's divided by factor 8 by default, but after flashing bootloader it'll be set to crystal oscilator - depends on target/variant)
Remove cap from RST, it might be slowing down reset and cause invalid reading
Currently there's no arduino board with atmega8a as the main microcontroller.
You forgot about pins 20 and 22 -- you must connect them to VCC and GND even if you're not going to use ADC.
EDIT:
Ad. 1. It would be possible to add support for atmega8a to arduino ide, by modifying hardware/arduino/avr/boards.txt file and compiling a bootloader for atmega8a.
Related
Overview
I need to program a recently purchased STM32F407ZGT6 board
In 'normal mode' my computer doesn't recognizing the board as a Ports (COM & LPT)/STMElectronics Virtual COM Port when connected via USB (I'm using a Windows 10 Pro). The LEDs turn on and I can get it into 'DFU mode'. When I try to debug the code, I get the "No ST-LINK detected!" message in either mode.
This is my first time connecting the board and also my first time dealing with STM32
Despite the instructions, I want to program the board using C directly from the STM32CubeIDE
Here is what I found
I found this question [1] where Device Manager reads the STM as Disk drives/STM32. My PC identifies it as mass storage and portable devices on Windows 10 Pro. When in DFU mode, I can see it as Universal Serial Bus Device/STM32 BOOTLOADER on Device Manager.
The tutorial [2] uses Flash Loader Demo and this older tutorial [3] uses STSW-STM32080, but both of the drivers are tagged as obsolete on the ST Website. STM32CuberProgrammer is indicated instead, but I would like to flash and debug directly from the IDE. Another forum reply [4] says that "you need a ST-link V2 programmer to program the brand new chip".
In summary
I can see the solution being one of the following options:
correct answer I need to use the ST-LINK-V2 to program from the IDE and that's the only way
I need to flash a bootloader via STM32CubeProgrammer to get it to work via IDE (is there a standard code for this?)
I have to build the cross-compiler for MicroPython [5] before I get to program it in C
What are your thoughts? Any other driver or idea that I might be missing?
Update
I went on and got my hands on a ST-LINK V2. I made the connection via the JTAG/SWD connector (see schematic) and I also tried connecting directly with the pins:
ST-Link
JTAG/SWD
Pins
SWCLK
9
PA14
SWDIO
7
PA13
GND
10
GND
3.3V
1
3.3V
RST
3
PB4
The ST-Link is not recognized. The ST-Link blinks and the board is powered up, but that's it. Device manager before and after shows the same.
So I went on checking if I was missing any new driver/program. I installed the STSW-LINK004 (STM32 ST-LINK Utility v4.6.0.0) based on these instructions, but no luck, Utility cannot find it either. I've reseted the computer after each driver installation. If I connect my boardvia USB in DFU mode, it is still recognized as STM32 BOOTLOADER, if I do it with the ST-Link, nothing changes.
Update solution
It turned out the ST-Link was faulty and therefore not connecting. After finding another ST-LINK/V2, the computer can recognize the board under Universal Serial Bus devices/STM32 STLink.
Debugging with STM32CubeIDE will always need an ST-LINK or other JTAG or SWD debug probe.
The bootloader allows you to program the microcontroller with a binary image, and that's it. The IDE will happily produce such a binary image, and possibly even have a wizard for transferring it via DFU. But that's only programming, no debugging And only be when the bootloader is running. If you did debug-like things like reading RAM contents, you'd get what the bootloader stores there while it is running, not the variables that your own program uses.
The ROM bootloader supports several ways of receiving new code to flash -- USB (DFU), CAN, I2C, SPI, UART. That last is not a USB Virtual COM port, it is honest-to-God UART using the USART peripheral in the microcontroller and RX/TX pins.
If you want a virtual COM port for your custom firmware to use to send data to the PC, you have to program the USB peripheral.
I needed to change my Brown Out Voltage to 4.3V from the Arduino default. I purchased from Sparkfun the AVR Pocket Programmer and connected as instructed. I have an Arduino 328P with CC3000 wifi shield. All worked perfectly before ICSP fuse change. My default fuse settings as read successfully using the AVRDude cmd,
avrdude -c usbtiny -p atmega328p was H=05, L=FF, E=DE.
I ran the following cmd to change on the BOD setting to 4.3,
avrdude -c usbtiny -p atmega328p -U lfuse:w:0xff:m -U hfuse:w:0x05:m -U efuse:w:0xfc:m as instructed using the Engbedded AVR Fuse Calculator. This appeared to run successfully. I was completely unable to program my board after this and could not run the avrdude -c usbtiny -p atmega328p without getting an initialization failed, rc=-1 error.
Killing me too as I was a hair away from launching my project to an organic farm for the first phase of an innovative irrigation control system.
Hopefully the problem is your connections. Check you connections, and if they isn't the problem, you have some work to do:
After alooked at your fuses, I searched a few things up and saw this. The default fuse values are:
Low Fuse 0xFF
High Fuse 0xDE
Extended Fuse 0x05
You mixed up your fuses above. I used AtmelStudio to check what your fuses would do:
avrdude -c usbtiny -p atmega328p -U lfuse:w:0xff:m -U hfuse:w:0x05:m -U efuse:w:0xfc:m
This would change the RSTDISBL value and enable RSTDISBL. According to the datasheet, doing this will
Setting the reset disable fuse will cause JTAG and ISP programming to stop working. Can only be unset with
high-voltage programming
By doing this, you bricked your chip. Now, you would want to undo this. The only way you could do this for cheap without buying a fancy STK500 is to buy a new Atmega328p or to use another Arduino Uno to use high-voltage programming to completely erase your bricked one.
In order to do this, follow this tutorial to erase your chip. This tutorial uses a perfboard, but you can do the same exact thing on the breadboard.
Now once you erase your bricked Arduino, you have to put the correct fuses.
The default ones are:
Low Fuse 0xFF
High Fuse 0xDE
Extended Fuse 0x05
Now, you want to change the Brown-out Voltage to 4.3V right? Using AtmelStudio, once again, I have come up with the following fuses:
Low Fuse 0xFF
High Fuse 0xDE
Extended Fuse 0x04
Once you program this, you should have a working Arduino!
If you need to program the Arduino using the Arduino software by USB, not by the AVR programmer, you will have to program the bootloader. Reply if you need help with that. That said, if you will always be using the AVR programmer from now, the bootloader may not be necessary.
This will fix your problem and make your brown-out voltage correct!
Always triple check your fuses using something like AtmelStudio, because you could end up doing a lot of extra work like in this case.
I have an arduino uno R3. I am able to upload the programs with no connectivity issues. But there is a problem while executing the program and I don't know what that is. The 13th pin led is not blinking as the default bootloader program comes with preloaded blink program. I am not able to reset the board too. What might be causing the problem?
I even tried to reload the bootloader program. But the same think happens yet again.
Thanks in advance and Regards,
Rishi.
Have you tried to blink one led with pin 2 or 3 ( any of the digital pins ). You might have a working Arduino uno but your led on the board can be broken.
Otherwise,you should try to flash the bootloader with a secondary arduino and check if you get the same issue.
I am using ATMEGA128 to communicate with another device. For this I am using SPI with ATMEGA128 as slave. I use SS, SCK and MOSI pins. The problem I am facing is that when I have to download program, I have to disconnect SPI pins. The ATMEGA128 module I am using uses TXD0, RXD0, SCK(PB1) pins to download program. Why am I facing this problem ? Is it because SPI and downloading circuit uses same SCK pins ? Is there any way to avoid disconnecting SPI pins ?
Does the other device have a chip select input, or could you add one on its VCC pins? If so, you could tie this device's CS (active low) input to an extra AVR port pin with an external pull-up resistor attached (maybe 10k ohms or so), then set this AVR pin low at the start of your code somewhere. The device will be disabled by the external pull-up until programming of the AVR is finished and your code re-enables it when run.
Is it because SPI and downloading circuit uses same SCK pins ?
Yes, you have to prevent any other device from driving the SPI lines during programming.
Is there any way to avoid disconnecting SPI pins ?
Yes. To avoid driver contention, a series resistor should be placed on each of the three dedicated lines if there is a possibility that external circuitry could be driving these lines.
See my answer here.
This is the same question that I've posted on the Arduino Forums, as there could be someone here who could help me :)
I'm using an Arduino Pro Micro 3.3V/8MHz from SparkFun for a project. I've installed the drivers, added support for the board on the IDE and tried uploading a sketch to it - it worked okay. I realize that the bootloader shipped with the board emulates a distinct serial port for uploading, as the normal port is COM5 and the upload port is COM6. Though for this project, code optimization is paramount, so I moved on to the Atmel Studio which I had already used successfully with the UNO. I constructed a simple blinky code for the Micro using the registers and functions:
#define ledpin PC6
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
DDRC |= (1 << ledpin);
while(1)
{
PORTC |= (1 << ledpin);
_delay_ms(1000);
PORTC &= ~(1 << ledpin);
_delay_ms(1000);
}
}
I can upload it okay through Atmel Studio with the following command in avrdude:
C:\Program Files (x86)\Arduino\hardware/tools/avr/bin/avrdude -C"C:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf" -v -v -patmega32u4 -cavr109 -P\\.\COM6 -b57600 -D -Uflash:w:"$(ProjectDir)Debug\$(ItemFileName).hex":i
To be able to do this, I have to press the reset button twice in less than 750 ms, as the hookup guide sugests (https://learn.sparkfun.com/tutorials/pro-micro--fio-v3-hookup-guide/troubleshooting-and-faq#ts-reset).
The code works, but now I notice that the normal serial port (COM5) never comes back. What could be the cause? I can still upload new code to the Micro, so the bootloader should be okay right?
Thanks for the help in advance :)
I have sort of found the solution. As I posted on the Arduino forums:
I was able to revert the pro micro to the state it was delivered to me by SparkFun.
To do that, I used an Arduino Uno as ISP (with the ArduinoISP example) connected to the MISO, MOSI, SCLK and RST pins of the Micro and uploaded the bootloader through the Arduino IDE. At first, I got an error that read:
avrdude: verification error, first mismatch at byte 0x0000 0xfe != 0xce
Then, I went looking into how to set the fuse bits on the Pro Micro when I realized the boards.txt specifies the fuse bits to be used. All I had to do was change the "extended_fuses=0xfe" to "extended_fuses=0xce", restart the IDE and retry the bootloader upload. At last, success!
To test it, I wrote a simple UART "Hello world" application in the IDE, which worked flawlessly.
When uploading the bootloader, make sure you have the correct board selected (SparkFun 3.3V/8MHz) and select the COM port of the ISP Arduino.