Electrical – Atmel ICE SAM connector pinout does not reflect the real pinout

Thank you for posting and linking to exactly which sound-maker you are trying to use: the PB-12N23PW-05Q self-oscillating buzzer. (If you had a raw piezo disk, or a coil speaker, we would use a different drive circuit).

If you insist on using a NPN such as the BD237, you need to add a external resistor between the MCU and the base of the NPN, as joeforker mentioned: 1 KOhm should be adequate. But no matter what resistor or silicon NPN transistor you use, you will end up with (at best) a V_ce_sat voltage drop of around 0.6 V, so the voltage across the buzzer is about 4.4 V -- which is technically outside the "guaranteed-to-work" "4.5 to 5.5 V" operating range in the buzzer datasheet.

If I were you, I would probably throw out the NPN and replace it with a MOSFET. A cheap 2N7000 has an on-resistance of 5 Ohm; at 25 mA that gives a voltage drop of .125 V. (More expensive MOSFETs have an order of magnitude less (better) on-resistance).

The MOSFET should work in the circuit you posted -- it doesn't need a resistor.

I am surprised that you are getting a different sound. The kinds of mistakes I am likely to make (and so the first things I would check) are:

• Did I put the buzzer in upside down? (This doesn't matter much for a raw piezo disk, but it does matter in a self-oscillating buzzer like yours).

• Hook the buzzer up to a bench power supply, and see what it sounds like in the 4 V to 5 V voltage range. Perhaps it's supposed to sound like that at that (5V - transistor drop) voltage?

• What is the actual voltage across the buzzer and across the transistor? I might check this with an O'scope, since it's quite possible that we have an average current of 25 mA, as shown on the graph, but peak pulses of much higher current -- perhaps such a high instantaneous current that your so-called "5 V" power supply is briefly pulled down to such a low voltage that your ATmega resets. If that is the case, you'll need to add some bypass capacitors and perhaps a ferrite bead or resistor.

My next step would be to install the electrolytic capacitors as recommended in the Schematic Checklist you mentioned. If it still doesn't work, I would go ahead and install all the inductors, etc. recommended in the checklist -- maybe there is a reason Atmel published that checklist :-).

If it still doesn't work, I would fall back on the sorts of errors I often make:

• When I probe the VCC and AVCC power pins with a multimeter, does each and every one of them show I have the correct 3.3 V?
• Is each and every one of the GND pins solidly connected to GND?
• Did I maybe install the PDI connector backwards or upside down again ? Or maybe forget to connect one of its pins to the MCU? (Use a multimeter to beep out the connection, one probe directly on the MCU chip pin, the other at the far end of the cable to the part of the programmer that pin is supposed to be connected to)
• Have I used the multimeter beeper to confirm that I haven't shorted any two adjacent pins?
• Is there maybe something wrong with the Dragon programmer or the cable between it and the board? Does the Dragon program work right when I use it to program some other similar AVR chip, perhaps a through-hole chip crammed into a solderless breadboard?

Could you post a photo of your PCB?

With most digital electronics, even if the PCB is known to be incorrect, it's usually quicker and easier to cut traces and add jumper wires on the prototype until you at least get to the "blink an LED" stage than to wait for another PCB to be fabbed that has fewer problems with it.

10 mm extra trace length is irrelevant in this application. I'm almost certain that is not the problem.

After I've exhaustively made sure that everything is connected properly, as recommended by the manufacturer, and there's no shorts between adjacent traces, and the program still doesn't "recognize" the chip, only then would I conclude the chip is a dud and get a replacement chip.

Later, after you get the programmer to "recognize" the chip and start to program it, then you can think about:

Is there a pin that will toggle to show me it's OK? Kind of a hardware "Hello World"?

Yes. Blinking an LED is considered the equivalent of "Hello World" in electronics. a b c d This doesn't happen automatically, though -- you need to connect a pin to an LED and you need to write some code to blink it.

Even after a person programs the other pins to do useful things, they often leave the code in to blink a "heartbeat" LED a b that once a second or so. That makes it pretty much instant to confirm that the program is loaded and running, the right frequency of crystal is connected, etc. (Some people deliberately change the blink rate every time they reprogram the chip, just to reassure themselves that the chip is now running with the latest code rather than the old code).