Avrdude GPIO programming not sending signals.

Go To Last Post
24 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am working on a project using the ATmega16U2 microcontroller, which (long story short) requires a program-measure-repeat cycle to properly calibrate the internal RC oscillator. To accomplish this, I am using avrdude on a Raspberry Pi 3 to program the microcontroller and an accurate frequency-measuring IC that I have connected to the Raspi via SPI.

 

Months ago, I got avrdude working with 4 GPIO connections and was able to successfully program the ATmega16U2 with a hex file, which I was very happy with. I don't remember too much issue, just remember needing to make sure the GPIO pins were connected correctly.

 

I worked on some other stuff in the last few months, including a script to perform the measure part of the cycle, and now that I have come back and tried to use avrdude again it doesn't work. I figured I had just connected it wrong or something, but I have tried several different GPIO pins and spent multiple days triple-checking connections and I am confident that my physical connections are not the issue. Furthermore, when I tried reading the connections between the Raspberry Pi and the microcontroller with a logic analyzer, the analyzer doesn't detect any signals on the lines at all. That really confused me, is it possible that the Raspberry Pi could just not be sending signals but thinking that it is? Could something be fried?

 

Please let me know if there is any more information that would be useful. I am stuck. Thanks!

 

Summary:

  • Trying to program an ATmega16U2 using avrdude on Raspberry Pi 3
  • It worked in the past with the same setup but isn't now
  • Double-checking connections and changing GPIO pins don't fix the problem
  • Logic analyzer shows no signals on any of the signal lines (RESET tied high, MISO, MOSI, and CLK tied low)
  • Using the -F option when running avrdude causes it to read a somewhat random device signature (usually looks like 0x10?8??, where '?' is different every time)

 

avrdude_gpio.conf programmer entry:

programmer
    id      = "gpio_connection_1";
    desc    = "Raspi gpio interface";
    type    = "linuxgpio";
    reset   = 6;
    sck     = 14;
    mosi    = 2;
    miso    = 3;
;

Screenshot of avrdude output:

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I tried a number of things and still no success. I tried a complete reinstall of the OS, a complete reinstall of avrdude, turning on and off the different interface options, a bunch more different GPIO pin combinations, I tested my logic analyzer to make sure it wasn't misreading. I even tried disconnecting the pins from my breadboard and directly measuring the pins on the pi with a logic analyzer and they don't change at all when avrdude runs.

 

I thought I was out of ideas before, but I really have no clue here.

 

Another thing that has been convincing me that the problem is with avrdude is that the pattern I noticed before, where the reported "received device signature" value seems to be somewhat consistent, doesn't hold between restarts of the pi. I think it is really just pulling this value out of never never land, which is confusing. Does anyone know more about how avrdude works? Any information or general troubleshooting advice would be greatly appreciated.

 

Thanks!

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dr Tesla wrote:
Trying to program an ATmega16U2 using avrdude on Raspberry Pi 3

Are all grounds connected to each other?

 

Use an actual cheap USBasp programmer to do this job, which will connect to your raspberry pi 3 via USB and you can still do your program-measure-repeat cycle. If all of that is working then you are sure that the problem is with the avrdude / raspberry pi.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

Last Edited: Sun. Jan 16, 2022 - 08:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Using avrdude -F with an unreliable target is a recipe for resulting in "wrong fuses" being programmed.   Even if you have not specified any fuse arguments.

 

-F is almost always unwise.   It is a bit like driving on a motorway with your eyes shut.

 

Don't do it.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisen,

 

Thanks for your response! Yes, the grounds are connected together, I have been running the breadboard off of the Raspberry Pi's 5V VCC and GND pins. I have also tried it with only common ground and separate supply voltages, still no dice.

 

I can still successfully program the Atmega16U2 with an Atmel Ice, which is usually how I program and debug my projects, but I did that from Microchip Studio on my PC. I could try using my Ice from the pi, I will see if it can do that, but that would not be the best solution for me overall.

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Haha, yes David, I normally wouldn't try to force it, but since I was detecting no signals at all I wanted to see if I could get it to do something. Unfortunately, still nothing. Thanks for the advice!

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dr Tesla wrote:

...since I was detecting no signals at all...

No signals at all?  How are you determining that?  What tools are you using?

 

From https://www.avrfreaks.net/forum/... :

theusch wrote:
I've done this so many times over the years, it is getting hard to find my "best" checklist. Maybe I should make a signature block like Cliff. Here is one of the more complete checklists: https://www.avrfreaks.net/index.p...

Quote:
...before worrying about completing a full programming sequence correctly, one must be able to hammer the Read Signature button and get consistent and reliable results. If you cannot do that, then ISP will probably not succeed. If you can do that, ISP will probably succeed. Go back to the standard checklist:

--AVR has proper power? (All Vcc pins hooked up, all Gnds hooked up, good clean power)

--AVR has proper /RESET circuit? (And even with a voltmeter one should be able to "see" /RESET move during ISP operations such as Read Signature) --AVR has a clock source?

--ISP speed is not too fast for the AVR clock?

 

Then you start 'scoping the signals on the target during Read Signature repeats. Vcc staying stable? /RESET acting properly? SCK getting to the target pin? Clean? Then MISO/MOSI, same. Then SCK in relation to MOSI/MISO. [I've never had to go that far--it was always an earlier item on this checklist.]

 

Be sure to check right at the target AVR's pins to ensure the signals are getting all the way through. What AVR model? How far do you get in the checklist? Lee

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. Jan 17, 2022 - 12:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dr Tesla wrote:
Does anyone know more about how avrdude works?
re AVRDUDE on Raspberry Pi, Ron.

Verification Error when programming from Raspberry Pi (avrdude with linuxgpio bitbang) | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is not AVRdude "just" software? If there are no signals, then it must be a problem with the RPi or software running on it. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am working on a project using the ATmega16U2 microcontroller,

What about all of the caps at the AVR?  Do you have plenty?  What other loads are on the said programming lines?  Are ALL AVR power & gnd pins connected?  using long wries where short ones are needed? show a photos  & schematic---maybe something will become discovered. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dr Tesla wrote:

... I have been running the breadboard off of the Raspberry Pi's 5V VCC and GND pins. ...

 

What voltage is your 16U2 running on? If it's 5V then it's unlikely that the 3.3V I/O from the Pi will work.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Theusch, I am measuring the signals with my Logic Analyzer. I have attached a screenshot of the output of the analyzer while measuring the four programming signals (D0 - D3, connected directly to the pi and disconnected from the IC) and the 10 kHz calibration signal (D6) I programmed my chip, the atmega16u2, to output. This logic capture was taken such that it captures all of avrdude's activities when it is run, and the output resembles my screenshot from my initial post. I don't understand why there are flat-out no signals on any of the lines.

Attachment(s): 

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim,

 

That is my thinking as well, although that is what I am afraid of. I currently have no idea exactly how avrdude operates on the software side, so I don't exactly know where I would start looking.

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What happens if you do >sudo avrdude (the rest of the command)

Do the lines wiggle now?

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

If you want something you've never had...

...you must be willing to do something you've never done!

Lets go Brandon!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian, that is a really good point, I hadn't considered that. I do have the 16U2 running on 5V from the pi, but measuring that voltage it is even closer to 5.2V, so I switched it to run off of 3.3V VCC and... still nothing. No signals, no change in the report from avrdude. In addition, I definitely had avrdude working a few months ago and it would have been on 5V then anyways. I appreciate the suggestion!

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jim, yes, I have been doing >sudo avrdude (yada yada), unfortunately still no wiggle.

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies,

 

Good question, I will attach a picture of my circuit for people to look at (the wires going to the Raspi make it a bit tricky to look at, apologies). The design includes a 10 uF capacitor across VCC and GND, which has been sufficient so far. There is also a 1 uF capacitor between GND and the UCAP pin on the atmega16u2, which is necessary for the onboard USB module. I have placed no loads on any of the programming signals. All the connections to the microcontroller are modeled after Figure 20-3 (page 186) and Figure 25-7 (page 259) of the atmega16u2 datasheet. Again, I have been able to program the microcontroller with my Atmel-ICE, it is purely when I try with avrdude that it doesn't work.

Attachment(s): 

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't understand why there are flat-out no signals on any of the lines.

Could be some acquisition setting or the connection of the analyzer is kaput.  Since you are connected to the pi, make a little 5 line program to toggle these lines. Flip line A,  and each time A flips low, flip B. Each time B flips low, flip C, etc...    ...then try to capture something, anything.  That will show the analyzer and setup is good & connections to the rpi are good..  Then you can go back to AVRdude and see if it is really dead (with more confidence).  If the analyzer is not working/not set, you could be really misled.

 

 

you breadboard lookos really nice!  A couple o  notes:

 

The 1 and 10uF caps are needed & great for voltage stabilization, but useless for the real high freq hash. They are fine where they are and are like putting water towers on your property.  You need some  0.1 uF cap(s) right at the AVR power pins (or as close as possible).  Any lead length (even the leads of the caps!!) has inductance which "ruins" the filtering effect of the cap.  That was a big leap forward with surmount parts---lower inductance.   Anyhow, keep it short.

 

Those header jumpers can be complete trash, so beware.  The wrong ones are made from steel and have no springiness, compared to beryllium copper (by far the best).  I had some, that after one use would fall off the header pins if you blew on them.

A magnet can at least find the worst suspect contacts, though even then you can get lousy materials.   If you see no signal on any header jumper, that is not likely your issue.

Also note the breadboards are also cheap nowadays---you can get pretty breadboards with lousy contacts... Looks great, no connection!  Sounds like you are having an issue with AVRdude itself on the rpi.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Mon. Jan 17, 2022 - 10:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies, thanks for your feedback! I am typically more cautious with my decoupling capacitors, but after testing this arrangement out it seemed fine for my prototyping setup. I do plan on placing the capacitors much closer to the uC when I eventually design my PCB. And funny you should mention, these header jumpers in fact are complete trash! I got these ones a few years ago during my undergrad (before I even knew the difference) and they are definitely pretty lousy, though I can confirm they do still carry a signal.

 

Following your advice, I wrote a basic python program to toggle each of the pins in question here to try and concretely rule out anything obvious like fried IO ports, and the IO pins I am using do in fact seem to be functional (Screenshot attached). However, when I was writing the script I accidentally set it up to use the board pin number instead of the gpio port number, which caused me to notice some unusual behavior. 

 

It is my understanding that the pin definition for the linuxgpio programmer is supposed to use the GPIO number (the 13th pin on the raspi 3 header is GPIO 2, etc), not the header pin number. However, I had two of my logic analyzer probes connected to the physical pins 3 and 5 (which would be GPIO 8 and 9, respectively), and I was able to see these two emit signals whenever I ran avrdude (Screenshot attached). They look kinda like they're supposed to if they were the Reset and SCK signals, which would make sense if avrdude were interpreting my GPIO pin numbers as physical pin numbers (See my pin number assignments in my original post if interested). However, I changed the numbers in the avrdude_conf file to match the physical pin numbers I want to use and I still measure nothing on them when I run avrdude.

 

So, let me make sure I am not completely misunderstanding something: Does avrdude want the header pin number or the GPIO number when you assign pins for a linuxgpio-type programming interface? Are there any other rules that need to be taken into consideration when selecting the GPIO pins you want to use (i.e. no power or ground pins)?

Attachment(s): 

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Unfortunately , I don't use AVRdude, so others will certainly weigh in...sounds like you are getting some issues unraveled.

 

I did want to clarify about the caps...the 1, 10 uF electrolytic caps are terrible at high (RF)  freq, regardless of where they are---they are like bulk water tower charge storage (still needed). The high freq 0.1uF  caps are ceramic caps (or some other materials).. ceramics can work up to GHz operation for cleaning up digital noise.   In fact, nowadays you can get ceramic caps in a handful of uF...to do both jobs at once. Twenty years ago, a ceramic cap was big or big $$ when you went to values more than around 0.47 uF.  You would not go around looking for a 10uF or 100uF ceramic cap.

Just make sure your high freq caps use short leads and traces, so they have the most effect.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Tue. Jan 18, 2022 - 12:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is fine, you are right, I think I am close to getting things figured out. I appreciate everyone's help!

 

About the capacitors, I understand that electrolytic capacitors aren't ideal for high-frequency noise filtering, so I plan to use ceramic capacitors (X5R) when the design is ready for PCB. You mentioned I shouldn't go looking for a 10uF capacitor, but I guess I don't quite understand why? I already have a bunch of 0603 10uF ceramic capacitors, they seem to work pretty well and I haven't found any reason why they might cause a problem (other than any piezoelectric effects, but that seems like an extreme niche case and shouldn't affect my project). Here is a link to the ones I have, do you think these may bite me unintentionally somehow? My preemptive PCB layout has very short trace lengths, falling within 8 mm from the supply connection to the microcontroller, so I don't think there will be too much inductance.

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


ceramic caps are great...these electrolytics you used aren't much for high freq, they are bulk storage.  I'm saying:

 

  • you can use 10uF electrolytic you have , but also need 0.1 uF ceramic     ..you would HAVE to do it this way not too long ago, because larger values were not readily available.
  • Nowadays you can buy 10uF ceramics and more or less ditch the electrolytics.   They do have some funky voltage sensitivity...always use a much higher rated cap than you need (like a 16V or 25V  part for your 5V circuit, if you want larger uF)
  • As you apply voltage close to the rating, the cap's actual uF takes a nosedive (for these high value uF parts)  a 0.1 will have much less variation.
  • That's the next thing cap people are working to improve!  Be sure to shake their hand.

 

Electrolytic

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, yes, I understand, you were just talking about the electrolytics that I had on the board. Yes, I know those don't work so well for high-frequency filtering, I just put them on the board cause it's what I have. The voltage sensitivity of the 10uF caps shouldn't be an issue, mine are rated for 20V or 25V or something like that, well over the 5V they should ever see. Thanks for the advice!

If learning is done best through failure, then I must be one of the most well-learned people on the planet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The following is a great comparison & something def worth looking at:

https://product.tdk.com/en/techl...

 

see table 2:

https://fscdn.rohm.com/en/produc...

 

You may be interested in reading about the ongoing ceramic capacitor revolution...a lot of cool stuff is hitting the bench now & more to come

https://avx.com/docs/techinfo/EB...

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Jan 19, 2022 - 12:30 AM