new ATMEGA1281 and avrdude - avr

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.

Related

Failing to access AVR ATTiny13A with very slow clock (128kHz/128 or 128kHz/256) (avrdude: error: program enable: target doesn't answer)

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.

Arduino Programmer only works after unlugging and plugging back in

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.

Unable to connect to Atmega328P chip with 16MHz crystal

I am trying to connect to Atmega328P chip through eXtreme Burner. I used 22pf capacitors and 10K pull for reset.
I am able to read the chip if I use 8 MHz Crystal. But cannot read if I connect 16MHz crystal. When I looked at the datasheet, it says fuse bits are same for 8 MHz and 16 MHz. I get "Power On Failed" error message with 16 MHz. I am using USBASP programmer.
Please note: With 8 MHz crystal, though I am able to read the device, I get error message "Incorrect Chip Found! Continue". If I press OK, it reads the data. The fuse bits read using 8 MHz crystal are: Low-- FF, High - DE, Extended -- FD, Lock Fuse - CF and Calibration - FFFFFFB1
What could be the issue?
Attached screen shots in the link
http://www.filedropper.com/extremeburnererrors
Its not in your settings then, so it must be in the setup of your hardware. Try different capacitor values. If I remember correctly, you have to vary the value of the capacitors as the frequency of your crystal varies. Also you have to take in to account the added inductance and capacitance of the breadboard or pcb and solder. So I would suggest just trial and error with different capacitor values.

Arduino Serial transmitting Missing One Charcter

I am using Arduino Leonardo to transmit an string to a wifi module. The format of command that wifi module can recognize is:
AT60,1,content to a server
I am using an virtual server(TCP/IP Builder) to test the content I can received.
Here is the content I want to send:
smart/device/deviceCmd?userId=1010002003&deviceId=A00019999990002&cmd=ON
Since I try to send it again and again, I use a loop to send it. In the virtual server side, the content I got is:
smart/device/deviceCmd?userId=1010002003&devceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&devceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&eviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&devieId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003deviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&deiceId=A00019999990002&cmd=ON
smart/device/deviceCmd?userId=1010002003&dviceId=A00019999990002&cmd=ON
This is the QUESTION: There exist one terrible mistake in the content I received, which is the deviceId part never correct. It's so weird.
Here is part of related code:
//In Uart.cpp
//These three lines can sent a formatted string as "AT60,1,content"
Serial1.write("AT60,");
Serial1.write(channelID); //channel ID = 1 here
Serial1.write(reportIsFire, 76);
//In Uart.h
//Definition of the string I need to send, which has 76 characters.
char reportIsFire[76] = ",smart/device/deviceCmd?userId=1010002003&deviceId=A00019999990002&cmd=ON \n";
Here is few background of this application:
I am using Arduino 1.5.8 IDE with VisualStudio
Since the serial buffer of Arduino is only 64 Bytes, I have already
change the buffer size to 128 Bytes in "HardwareSerial.h" to send
out this large string.
The baud rate is 115200 and I am using Serial 1. I have used Serial 1
to transmit few other characters and it works fine.
I will appreciate that If you have any idea about this question.
I am betting that the serial baud rate of the Arduino is not 100% correct. Increasing the buffer size will not matter if the data is being lost due to a timing issue in the physical link.
I'd recommend double-checking the code that initializes the serial baud rate generator. It may be possible to get a closer rate to 115,200 by either adjusting the available settings, altering the main clock speed (if possible), implementing some form of flow control, or all of the above.
In extreme cases, you may consider using a special-frequency oscillator. Many Microchip PICs use an internal or external 4MHz or 8MHz crystal, but this can produce far too much timing error for lengthy serial transmissions at high speed. In that case, something special, like a 7.3728MHz crystal can be used, bringing the accuracy to exactly 100% (at least on some PIC devices.)
Lastly, another consideration is if any pre-emptive code is running on the device, such as interrupts or timers which could inadvertently interfere with the serial output.
I don't have an answer, but I suspect the most likely problem is that the Wifi card can't read characters at a sustained 115200 baud rate. If possible, set the Wifi baud rate and the Arduino Serial.begin() to a lower rate, such as 57600 or 19200.
If the Arduino baud rate was simply inaccurate, I'd expect to see the problem appearing at random locations in the string, rather than about 40 characters in.

What's CRC with 64b in and 32b out?

I'm developing a software utility to transfer some data to a pci-e board. To avoid the data transfer fault, I've add a CRC field in every packet, so that the pci-e board can verify the received data with the CRC value.
Then we found out that the CRC value failed to pass the verification.
I'm using the boost::crc_32_type to generate the CRC value while the hardware guy told me that the CRC implementation in the board is from http://www.easics.com/webtools/crctool and they're using the 64 data bus width version of CRC32 - ETHERNET / AAL5.
So, is it possible to use boost::crc_32_type to work with the one they're using?
Any suggestions will be greatly appreciated!
[edit 2013.02.20]
the working crc template shall have the following definition:
boost::crc_optimal<32, 0x04C11DB7, 0xFFFFFFFF, 0x0, false, false>
the order of every 8 bytes shall be reversed before being processed
std::for_each is used instead of process_bytes to get the result, I still don't quite understand the difference between them though.
You can use crc_32_type - first you have to make sure your bytes are going in the same order as the bytes the hardware guys are. The convention used by the EASICS code is that the first byte in the stream goes into Data[63:56].

Resources