I'm using avrdude to program my Arduino. My Ardunio Uno is from China and the programmer reported in the device manager is ch340.
When I first connect the arduino to my computer, avrdude works one time. All subsequent times it fails unless I unplug it from the computer and plug it back in. I tried putting a 10uF capacitor from RST to GND, it didn't help. I also tried a different configuration:
programmer
id = "ch340";
desc = "ttl port banging, reset=!txd sck=!rts mosi=!dtr miso=!cts (invert signals using 74ls04)";
type = serbb;
reset = 3;
sck = 4;
mosi = 8;
miso = 7;
;
That also didn't help. With either of those solutions, I couldn't even get it to work the first time. Only with programmer "arduino" did I get it to work, but then only once.
Here is the output from the first run after connecting to USB:
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: safemode: Fuses OK
avrdude done. Thank you.
All runs after that:
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
avrdude done. Thank you.
I also tried the reset button the board, it didn't make a difference.
It appears to have been my version of avrdude. The one included with an avrgui that I downloaded is 5.6. The one on the arduino website is 6.0.1 and it works.
Related
I am trying to program an AVR ATTiny13A using a USBasp adapter (guloprog) and avrdude. Uploading the program and running it works fine the first time for a fresh ATTiny13A device, but re-uploading again fails. avrdude cannot see/access the device at all. avrdude behaves like the device is not connected.
>avrdude -c usbasp -p t13 -B120 -U lfuse:r:-:b
avrdude: set SCK frequency to 8000 Hz
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
If I reduce the communication speed to the minimum supported by avrdude
>avrdude -c usbasp -p t13 -B2000 -U lfuse:r:-:b
I get set SCK frequency to 500 Hz with the same result as above.
Looking at the programming signals with an oscilloscope, all signals look good, except for MISO which only shows rudiments of communication between 0V and 0.2V.
I have set the CKSEL fuses to 11, selecting the internal 128kHz clock source. In the program I set CLKPR to 8, dividing the 128kHz clock by 256, to get the slowest clock possible. (I have also set CKDIV8 to 1, but that should not matter.)
Have I fuse-bricked the IC? I do not have a HVSP to clear the fuses. What else can I do?
How to unbrick the AVR with a very slow clock divider setting
The problem is caused by writing CLKPR with a very slow clock divider setting (/128 or /256 with the 128kHz clock) in the program. After the program started, programming no longer works (regardless of the -B setting for avrdude).
Solution without HVSP (with pull-down resistor): Put a pull-down resistor between RESET and GND (10k worked for me). Now you can access the AVR again and program a different program, setting the clock divider to at most /64.
The pull-down resistor will keep the AVR in reset after power-up, not allowing the program to run, preventing the slow clock to be set. In order to run the new program you need to remove the pull-down resistor.
Alternative solution with HVSP
If you have a HVSP you can reset the CKSEL to 10 again to use the 9.6 MHz internal clock (and potentially set CKDIV8 to 0 again). This will allow you to access the device again.
Background
avrdude limits the slowest communication speed to a minimum of 500 Hz. This is hardcoded in the source, see https://github.com/avrdudes/avrdude/blob/5cbc9c37fc71c424e99bdcc00bb910fd581c2676/src/usbasp.c#L903
The device must be clocked at least four times faster than this speed. For 500 Hz communication speed this means that the AVR must run at 2000 Hz or higher. This means that the slowest clock-divider setting with the 128kHz clock which is compatible with avrdude is 128kHz/64 = 2000Hz (and this is already on the edge and may fail, but it worked well for me). To get the slowest avrdude communication speed (500 Hz) use the -B 2000 option, e.g.:
avrdude -c usbasp -p t13 -B2000 -U lfuse:r:-:b
which works:
avrdude: set SCK frequency to 500 Hz
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.15s
avrdude: Device signature = 0x1e9007 (probably t13)
avrdude: reading lfuse memory:
Reading | ################################################## | 100% 0.05s
avrdude: writing output file "<stdout>"
0b1101011
avrdude: safemode: Fuses OK (E:FF, H:FF, L:6B)
avrdude done. Thank you.
Uploading programs will be very slow, but for programs which are only a few instructions long this is feasible.
I just installed the latest version of LIRC(0.10.1-5.2) on my Raspberry Pi 3, running Raspbian on Debian Buster.
I am trying to get my Pi to take input from an IR remote using lirc.
I have made the necessary changes to these files :
/etc/lirc/lirc_options.conf
driver = default
device = /dev/lirc0
/boot/config.txt
dtoverlay=gpio-ir,gpio_in_pin=18,gpio_out_pin=17,gpio_in_pull=up
//I set mine on up on GPIO pins 17 and 18 instead of 22 and 23
I have checked and cross-checked my circuit. Everything looks okay.
The challenge I'm facing right now is when I test my IR receiver using the following command,
mode2 -d /dev/lirc0
Nothing happens. There's no output at all. No pulses recorded.
Has anyone else experienced this issue?
Any help would be much appreciated.
After spending a great amount of time, trying to figure out how to solve this issue, I was finally able to resolve it.
So hopefully my answer will help someone else.
First things first, it's important to note that infrared device has changed from lirc-rpi to gpio-ir
Although, I already had this change in my /boot/config.txt
file,like below:
dtoverlay=gpio-ir,gpio_in_pin=18,gpio_out_pin=17,gpio_in_pull=up
// in stead of dtoverlay=lirc-rpi
I just thought it was important to point out.
Since I am trying to get my Pi to take input from an IR remote using lirc, I decided to first test my IR sensor separately, to make sure it works.
To do that, I connected up the sensor like so:
Pin 1 is the output so we wire this to a visible LED and resistor
Pin 2 is ground
Pin 3 is VCC, connect to 3v3
You can find more detailed step by step instructions from this tutorial here which also shows how to wire up your circuit as seen below.
During this test, my LED lit up each time I pointed a remote at the receiver, which gave me hope that it was working just fine.
The next step was to test the IR receiver on my raspberry pi, which is the challenge I had in the beginning.
I re-wired my circuit, this time:
Pin 1 is DATA, goes to RPi pin 12 (GPIO 18)
Pin 2 is GND, goes to RPI pin 6 (GROUND)
Pin 3 is POWER, goes RPi pin 1 (3v3)
Then I ran this command sudo /etc/init.d/lirc stop to make sure that service wasn't running.
I then ran the initial command mode2 -d /dev/lirc0 and now pressed random buttons from my remote at the receiver and violá! I could see some pulses on the screen with each button press now.
Like you I managed to get all the way to receiving pulses/data on the RPI 3, seem to have a problem with the output.
I have the USB strip light and my RPI with the IRC receiver, this is so I can monitor what data captured corresponds with the button pressed on the remote keypad. Works just fine.
However? If I push the ON button - I get data, if I push the ON button again I get another set of data. The two set of data dont match? , in both cases mode2 or mode2 -r.
I get the feeling I'm missing a method to decode the output, I've noticed there's a huge amount of companies and they all have distinct code sets.
Here is one thread that exactly matches what I have (24-Key IR remote).
http://woodsgood.ca/projects/2015/02/13/rgb-led-strip-controllers-ir-codes/
However I dont see the same set codes ???
Try to change the device to mode2 -d /dev/lirc1
I also faced this.
I am trying to use the control bits of a USB serial port adapter as general purpose I/O. This simple example should toggle the DTR line high, then low.
require 'serialport'
DataBits = 8
StopBits = 1
Parity = SerialPort::NONE
Baud = 38400
port = '/dev/tty.usbserial-A100KXWU'
serial = SerialPort.new(port, 'baud' => Baud, 'data_bits' => DataBits, 'stop_bits' => StopBits, 'parity' => Parity)
serial.flow_control = SerialPort::HARD
loop do
p serial.signals
sleep(1)
serial.dtr = (serial.dtr + 1) % 2
end
And the output:
{"rts"=>1, "dtr"=>1, "cts"=>1, "dsr"=>0, "dcd"=>0, "ri"=>0}
{"rts"=>1, "dtr"=>0, "cts"=>1, "dsr"=>0, "dcd"=>0, "ri"=>0}
{"rts"=>1, "dtr"=>1, "cts"=>1, "dsr"=>0, "dcd"=>0, "ri"=>0}
{"rts"=>1, "dtr"=>0, "cts"=>1, "dsr"=>0, "dcd"=>0, "ri"=>0}
As far as Ruby is concerned, serial.dtr is changing, but there is no change on the output voltage of the DTR pin. It's a constant +7V.
Additionally, the serial instance is unable to read any changes applied to CTS, DSR, or DCD coming from other hardware devices.
It is being run with sudo privileges, so it's not a issue with permissions. This is on OS X 10.10 Yosemite.
According to http://www.rubydoc.info/gems/serialport/SerialPort:flow_control=
Note: SerialPort::HARD uses RTS/CTS handshaking. DSR/DTR is not supported.
I'm answering my own question. It turns out that Apple's supplied FTDI drivers are buggy. They don't give any access to the control signals.
I installed the official FTDI VCP drivers (version 2.3 at this time of writing), rebooted, and now I have full control.
I'm experiencing sometimes problems when programming my new ATMEGA1281. It is suposed to be the same as my old one, the only difference I guess is the serial number:
ATMEGA1281 16AU 1104 vs ATMEGA1281 16AU 1304
I'm used to program the ATMEGA1281 with avrdude command, but with the new chip, I have sometimes this error:
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0x0c != 0xff
avrdude: verification error; content mismatch
Do you know why I'm having this problem?
Thanks in advance!
What programmer do you use?
The brand new microcontroler might have lower clock than your previous one and it might be to slow for your programmer.
Try decreasing your programmer bitclock (-B option of avrdude). It should be 4 times slower than the clock. Then you can change microcontroller fuses and use the programmer with the old bitclock.
I am having an odd problem with my PIC16F88. I have an EEPROM connected thru I2C and it works flawlessly until I write to portb.bit6. From that point on, I start getting garbage from my EEPROM. I tried explicitly disabling Timer 1, which uses portb.6 for oscillator-out but that did not help. I tried cutting the trace from the PIC pin (pin 12) so that there is nothing physically connected to it and that did not help. My C code is simple, either portb.6 = 0 or portb.6 = 1. Either way, reading the EEPROM thru I2C fails forever more. The generated ASM code looks fine. The problem occurs on every board that I have tried it on, so it is not localized to one PCB. I am mystified. Any suggestions?
It turns out that it is necessary to write a zero bit to the SCL and SDA pins every time before writing to any bit in portb. FWIW, I was bit-banging rather than using the SSP peripheral of the PIC16F88 for the I2C communicaitons. Thanks to the people on the Yahoo group, Electronics_101, for figuring out this puzzle.