Weird waveform appearing at pin.

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

This question is sort of a follow up to a post I made here recently. Referencing some of the ideas and code examples provided in that thread, I'm working through the suggestion of making the seven segment driver independant of the rest of the code, but I ended up with some weird issues:

 

(Since I forgot to add verticle cursors for reference, the pk voltage with reference to gnd is ~668mv, also the entire waveform is DC; it never dips negative.)

 

That signal is appearing at the display enable pins for the seven segment displays that I am using. I have absolutely no Idea where it is coming from. I know that the mcu isn't fried, nor is it something to do with the wiring because I can load other code onto it, and it will work as expected, but something in my rewrite of the previous code from the afformentioned post is causing this to happen.

 

Here is the code:

main.c

atmega328p.c, and atmega328p.h

pins.c, and pins.h

seven_segment.h

This topic has a solution.
Last Edited: Sun. May 15, 2022 - 09:43 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was a freak who was particularly scathing about your original code. I guess I owe you a look into this one.

 

I went as far as actually building it but needn't have bothered. The problem is obvious and you'll kick yourself.

 

void init(void)
{
    // Set the seven segment pins as outputs:
    for (uint8_t i = 0; i < NUMBER_OF_SS_SEGMENT_PINS; i++)
    {
        pin_config_output(ss_segment_pins[i]);
    }
    // Set the display_enable_pins as outputs:
    for (uint8_t i = 0; i < NUMBER_OF_SS_ENABLE_PINS; i++)
    {
        pin_config_output(ss_segment_pins[i]);
    }

    _delay_ms(2000);    // Sensor bootup delay.

    sei();  // Enable global interrupts.
}

Do you spot the copy-&-paste error here ??

 

You really meant to use ss_enable_pins[i] in the 2nd loop.

 

<edit>

  1. You really should be initialising to known states when making output pins. You assume they're already low. This will catch you out one day.
  2. I don't think atmega328p.c is a good filename for what are your pin utilities. Hey pinutils.c would be quite a good name.

 

Last Edited: Sun. May 15, 2022 - 09:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Either you have your probe slider switch set to AC coupling, or the the channel set to AC (looks not), or missing a gnd on your probe clip, or you have some averaging turned on.  Or there is a capacitor somewhere on your signal line

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

Izerpizer wrote:

That signal is appearing at the display enable pins for the seven segment displays that I am using.

 

Display enable pins? An ordinary 7-segent display does not have display enable pins, just anodes and cathodes.

 

How about you show us a schematic and point out EXACTLY where you are measuring that waveform.

#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: 1

N.Winterbottom wrote:

Do you spot the copy-&-paste error here ??

 

You really meant to use ss_enable_pins[i] in the 2nd loop.

Oh my goodness. Yup that was it. Problem solved! I knew it had something to do with pull-ups being enabled somwhere accidentally since what I was seeing on the scope was kinda alluding to that, but I could not find it anywhere. Thank you very much!

 

N.Winterbottom wrote:
You really should be initialising to known states when making output pins. You assume they're already low. This will catch you out one day.

Noted! I'll keep that tip in mind.

 

N.Winterbottom wrote:
I don't think atmega328p.c is a good filename for what are your pin utilities. Hey pinutils.c would be quite a good name.

Fair. I'll change it to like `atmega328p_utils` or something like that to be more specific.

 

avrcandies wrote:
Either you have your probe slider switch set to AC coupling, or the the channel set to AC (looks not), or missing a gnd on your probe clip, or you have some averaging turned on.  Or there is a capacitor somewhere on your signal line

Nah, it wouldn't have been any of those, since I hadn't touched any parts of the circuit between when it was working vs when it wasn't. All that was ever modified was the firmware.

 

Brian Fairchild wrote:
Display enable pins? An ordinary 7-segent display does not have display enable pins, just anodes and cathodes.

Ah sorry, I should have been more clear by what I meant. I meant the pins on the MCU that I designated as pins that enable the seven segment displays by turning on transistors (into saturation) that create a path from the tied cathodes of the 7-segments to ground. I'll try to include schematics in future posts that I make.

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


Something is wrong with your circuit, if that wave is your AVR output & you don't think it is any of #3 items.  Or you need to supply more info  ...are you overloading signal levels by not using resistors?

There certainly should be no curvature (unless you have something set to AC coupling).  Also, is your probe properly compensated (hook to scope test signal pin & tune probe for flat response), usually any such improper compensation curves are relatively fast (with a high BW probe).

 

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

Last Edited: Mon. May 16, 2022 - 12:14 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
...are you overloading signal levels by not using resistors?

No. At the base of each transistor (2N2222) there is a 680ohm resistor to allow a current of 5mA into the base (with an applied signal of 3.3V), saturating the trasistor.

 

avrcandies wrote:
unless you have something set to AC coupling

The scope is set to DC coupling.

 

avrcandies wrote:
Also, is your probe properly compensated

Yep, its compensated:

 

 

ASIDE: Keep in mind, this is all on a breadboard (and no guarantee on its quality), so plenty of parasitics involved there.

Last Edited: Mon. May 16, 2022 - 12:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok then your circuit and probe location are needed.  That does not look like an AVR pin you showed in #1

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

avrcandies wrote:

Ok then your circuit and probe location are needed.  That does not look like an AVR pin you showed in #1

 

Attached is a quick schematic.

 

Probe location would have been at, for example, pin 26 (common of probe connected to the ground rail of course).

Attachment(s): 

Last Edited: Tue. May 17, 2022 - 08:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well you certainly have some issue...the AVR output pin wave should look nice and square.  Are you ever accidentally changing DDR direction anywhere after you set it as an output?

If running on battery is your voltage rock solid?  

Zoom in on some edges, say at 1us/div.

Make absolutely sure your scope is set up properly:

   DC coupling

   No averaging

 

Make sure your transistors are installed with the proper pinout...look carefully.

 

If all else fails, just write a 5 line program to cycle the pin hi/lo nonstop...see if you get the desired square wave

That will tell whether you have a wiring issue or some software bug

 

DDRC=0xFF;

while(1) {

PORTC= 0x00;

PORTC= 0xFF;

}

 

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

avrcandies wrote:

Well you certainly have some issue...the AVR output pin wave should look nice and square.  Are you ever accidentally changing DDR direction anywhere after you set it as an output?

If running on battery is your voltage rock solid?  

Zoom in on some edges, say at 1us/div.

Make absolutely sure your scope is set up properly:

   DC coupling

   No averaging

 

Make sure your transistors are installed with the proper pinout...look carefully.

 

If all else fails, just write a 5 line program to cycle the pin hi/lo nonstop...see if you get the desired square wave

That will tell whether you have a wiring issue or some software bug

 

DDRC=0xFF;

while(1) {

PORTC= 0x00;

PORTC= 0xFF;

}

 

The issue was already determined to be software related from this comment on this post (hence why its been marked as the solution). I was under the impression that you thought that even with said software issue, it shouldn't look like that. The issue was that the display enable pins were accidentally being configured as inputs, so whenever I would toggle them I'd be enabling the pullup on that pin.

Last Edited: Tue. May 17, 2022 - 08:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The issue was that the display enable pins were accidentally being configured as inputs, so whenever I would toggle them I'd be enabling the pullup on that pin.

The last handful of posts you don't bother to say you are now seeing actual nice square waves on the pin ??  At least you have them now.

 

I was under the impression that you thought that even with said software issue, it shouldn't look like that. ​​​​​ 

Well, now the irons are out of the fire.

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

avrcandies wrote:
The last handful of posts you don't bother to say you are now seeing actual nice square waves on the pin ??

 

Yes I did:

Izerpizer wrote:

N.Winterbottom wrote:

 

Do you spot the copy-&-paste error here ??

 

You really meant to use ss_enable_pins[i] in the 2nd loop.

 

 

Oh my goodness. Yup that was it. Problem solved! I knew it had something to do with pull-ups being enabled somwhere accidentally since what I was seeing on the scope was kinda alluding to that, but I could not find it anywhere. Thank you very much!

 

 

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

since what I was seeing on the scope [and still seeing?] was kinda alluding to that

 You say the wave was "kinda alluding" to your software change, but never explicitly say the wave itself is now proper.  Remember, people could spot several problems in the program that you might fix along the way.  At least it was not a messy compound problem.  

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