How do I check life-signs with a scope? Atmega2560 standalone

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

Good day, everyone.

 

I am a total and absolute imbecile and I forgot to put a programming port for my printed circuit board before sending it for fabrication. As a result I now have to solder in tiny tiny enamel wires onto the pins of the MCU on the board, to program it. I know, I'm a moron, I'm paying for it dearly.

 

So the problem is that I'm having issues programming the Atmega2560 MCU with the USBasp. Now I'm more than confident that the programmer works fine, I'm just not sure if the MCU is properly powered/ installed and emits life signals. I have the 16mhz crystal, caps, reset resistors and everything else set up on the board but I have no way of seeing if the MCU is even alive. I just got my first scope a few days ago (Rigol DS1054Z), this is my first exposure to a piece of professional diagnostics equipment and I feel this would be an appropriate time to test the board for life signs. Question is, where do I poke the proddy sticks (so to speak)?  What should I be looking for as a sign the the controller is alive and well? One way I can think of is that I can try to use AVR ISP MK2 to try and talk to the MCU.

 

(as i'm writing this, it dawned on me that I probably didn't even set the fuses on the atmega as it's a fresh off the package unit. oh lord.)

 

So this would be more of a question of where to probe the scope and what to look for in terms of signs of life, that's really what this thread is about.

 

The Arduino IDE is saying that it can't set the CLK of the MCU and that I should check if the board is connected. The USBasp briefly blinks when I try to upload the blink sketch but then immediately fails wit the error. There's aways a chance that I've botched up the solder job so hence why I'm asking for advice here. 

The error:
Arduino: 1.8.9 (Windows 7), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

Sketch uses 1460 bytes (0%) of program storage space. Maximum is 253952 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 8183 bytes for local variables. Maximum is 8192 bytes.
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
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.

the selected serial port
does not exist or your board is not connected
.

Last Edited: Fri. Sep 13, 2019 - 06:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not toggle a port pin--just make a loop

 

If you can program it, then it is certainly 99% working.

 

Where is your schematic?

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

Last Edited: Fri. Sep 13, 2019 - 06:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I cannot program the controller at all. I don't even know if it is connected. My question right now is how to check if it's even on an operating, which would tell me that it is wired up correctly. Or at least close to be able to show signs of life. If I can probe this controller in places where it matters and collect information then I would know if I set up a correct schematic.

Would you need the whole schematic or the bare minimum stuff? I'm pretty confident that the schematic fits the bare nessesities / needs of the controller.

This is more a hardware debugging question than a check my schematic one. You know, "teach a man to fish" sort of a thing. I just need to learn how to use the tools (the scope)

Although if you have a point that I'm completely missing then I am all ears.

Last Edited: Fri. Sep 13, 2019 - 06:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you cannot program the chip then there is nothing you can probe to see if it is working.

So first you need to solve the lack of programming.

#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

Welcome to AVRFreaks.

 

If faced with this problem I would simply say that the costs to date have been the "entry price" to this wonderful world where experience follows failures. Redo your pcb design and make new boards.

Ross McKenzie ValuSoft Melbourne Australia

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

valusoft wrote:

Welcome to AVRFreaks.

 

If faced with this problem I would simply say that the costs to date have been the "entry price" to this wonderful world where experience follows failures. Redo your pcb design and make new boards.

 

You know, just a few minutes ago, this was just the conclusion I came to. Going to chuck this one up to an expensive lesson and go on from here.

 

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

If willing, you could upload your schematic and a pdf of your pcb layout. There are plenty of suggestions just waiting to flow your way. cheeky

Ross McKenzie ValuSoft Melbourne Australia

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

God gave you the Arduino MEGA2560.   You can prototype many "2560" projects with this hardware.    There is no need to use any specific language e.g. C, C++, BASCOM, ...

 

There are Ebay "breakout boards" or an Atmel STK600.

 

You can develop your project on the proven hardware.

When fully debugged,  you can copy their schematics, pcb layout, ... to suit your final device.

Don't be proud.    If a pcb design is public,  COPY it,

 

Yes,  it is wise to provide a header for ISP or JTAG an the pcb.

If the design has a USB-Serial chip,  you can use a bootloader (like Arduino).    But you still need one-off access to ISP/JTAG to install the bootloader in the first place.

 

David.

 

p.s.   you can develop any "hardware test" program on the Arduino.   e.g. blink LEDs on each GPIO pin.

You can develop more sophisticated sketches and use your Rigol to observe the waveforms.

When your "diagnostics" are proven on the Arduino,  you can run them on your custom pcb.

Last Edited: Fri. Sep 13, 2019 - 07:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TobisRipper wrote:
I cannot program the controller at all. I don't even know if it is connected. My question right now is how to check if it's even on an operating, which would tell me that it is wired up correctly. Or at least close to be able to show signs of life. If I can probe this controller in places where it matters and collect information then I would know if I set up a correct schematic. Would you need the whole schematic or the bare minimum stuff? I'm pretty confident that the schematic fits the bare nessesities / needs of the controller. This is more a hardware debugging question than a check my schematic one. You know, "teach a man to fish" sort of a thing. I just need to learn how to use the tools (the scope) Although if you have a point that I'm completely missing then I am all ears.

 

I'm by no means a professional, so perhaps I have more practice in handling similar situations. Some checks to give the controller a fighting chance to work (note that I am not familiar with this chip, so these are general checks, nothing specific to this controller):

  • Is Vcc within required range for highest clock frequency - measure at Vcc pin(s).
  • Check stability of Vcc at pin(s) - luckily you have an oscilloscope. Try to capture signal from power up.
  • Check resistance from ground pin(s) to power supply ground - should be very low.
  • Measure current to controller.
  • Measure voltage at reset pin, make sure the signal is reasonably stable.
  • Measure signal across oscillator pins to check if oscillator is running.
  • Check datasheet for default fuse settings - ( http://www.engbedded.com/fusecalc/ suggest that it should default to 8 MHz internal osc. with div 8, so the chip should run at 1 MHz)
  • Check SPI pins for activity during attempted programming, including reset.
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
develop your project on proven hardware

Absolutely!

 

Always start on proven hardware to gain experience with the product, the tools, and what a working system should "look" and "feel" like.

 

Then if/when you move to custom hardware, you have a known-good reference to go back to

 

david.prentice wrote:
provide a header for ISP or JTAG on the pcb

Absolutely! 

 

A key consideration of your design from the outset should be, "how will I debug this?"

So other things to consider include:

  • Some LEDs that you can use for status indications
  • Some unassigned IO pads
  • Test Points throughout the circuit
  • Maybe a spare UART for debug/status messages
  • etc, etc, ...

 

#DesignForDebug #DesignForTest

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Jul 10, 2020 - 09:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you give power to the Mega2560? keep in mind the programmer will not do that.

 

Then you can try to measure the ohms on the wires you soldered to see if you soldered a short somewhere.

another common misktake is mirroring the connections,

 

As long as you do not touch the fuses you should always be able to connect to the mega2560 using a programmer.

 

Asuming you use atmel studio, first just try to read the device ID and nothing else. Note that there seems to be a problem when trying to read the target voltage, when you read the device ID the target voltage also gets read and you can see that it is correct.

 

 

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

awneil wrote:

A key consideration of your design from the outset should be, "how will I debug this?"

So other things to consider include:

  • Some LEDs that you can use for status indications
  • Some unassigned IO pads
  • Test Points throughout the circuit
  • Maybe a spare UART for debug/status messages
  • etc, etc, ...

 

I would add one more to Andy's list, for each unused spare pin, connect a via with a hole large enough for a 30 gauge wire (wire wrap wire)

This will allow you to connect a jumper if needed easily to the pin.

 

You have a nice scope, take some time to get to know it.

If your probes have 1x / 10x switch, you will use the 10x setting most often as it loads the circuit under test the least.

Play with the triggering to learn how it works, don't just depend on Auto trigger, know when to use Normal, and Single as well.

Have fun!

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Fri. Sep 13, 2019 - 01:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

ki0bk wrote:
a via with a hole large enough for a 30 gauge wire

Absolutely!

 

It also makes it much easier to locate and keep a scope probe on it!

 

If possible, do it for all the testpoints.

 

Even better:  make the hole big enough to take a 0.1" header pin. Then you can clip a scope probe onto it - without having to hold it:

 

 

You certainly want this on at least GND.

 

 

You have a nice scope, take some time to get to know it.

+1

 

 

EDIT

 

Oh;  another thing: if possible, have all the testpoints on the same side of the board - it's a real pain trying to probe one signal on one side, and another on the other!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Sep 13, 2019 - 01:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

And don't forget to include a ground pin for your scope's connection.

Ross McKenzie ValuSoft Melbourne Australia

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

Oh wow, I actually missed a lot of peripherals I should have put on the board to make my life easier when debugging it. Thanks everyone, really appreciate the wisdom. I definitely need to redesign the board now.

 

Also for those who are familiar with the arduino ide. Is the bootloader only necessary for being able to upload the firmware via the usb - serial? Or is it's job to, all around interpret the C code written in arduino IDE? When I flash a bootloader onto an atmega chip using Atmel studio, does it not get overwritten if I upload a sketch using a programmer instead of the usb port?

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

No, the bootloader does nothing for the running application.
Yes, if you use an external programmer, you will probably erase the bootloader.
.
When you have installed a bootloader, BURY the programmer in a deep hole. Always use the bootloader.
If you want to use JTAG or debugWIRE for debugging, dig up the programmer when you want to re-install the bootloader.
.
A simpliified explanation. You could put useful code into the bootloader e.g. like a BIOS. But most bootloaders are just small and single purpose.
.
David.

Last Edited: Fri. Sep 13, 2019 - 04:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
BURY the programmer in a deep hole. Always use the bootloader.

 

When you say Burry in a deep hole, are you referring to putting the bootloader in a section of persistent memory where it does not get overwritten?

 

I use MISO / MOSI and SCK pins with the USBasp programmer to upload the code directly onto the Atmega so I feel that the bootloader does not server a purpose at this point, no?

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

When you say Burry in a deep hole, are you referring to putting the bootloader in a section of persistent memory where it does not get overwritten?

No, if you throw the programmer in the trash, then you can only use the bootloader & have no chance of destroying it.  Instead, you just talk to he booatloader & tell it "here's my program"

 

 

I use MISO / MOSI and SCK pins with the USBasp programmer to upload the code directly onto the Atmega so I feel that the bootloader does not server a purpose at this point, no?

That's just fine for most work....no bootloader needed & avoids a few complications relating to diagnosing startup (also, now you can wipe the chip 100% clean).

 

The bootloader is mostly convenience... say you give it to your uncle who lacks a programmer...now you can just send him a file & he can do an update.

 

 

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

Last Edited: Fri. Sep 13, 2019 - 04:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh sorry, I mixed up the terms programmer and bootloader.

 

As nice as it sounds, I'd have to then implement additional hardware onto my custom made pcb board. That's another hassle just for a benefit of loading code over usb. (this IS after all a standalone MCU project, not just me working on an arduino board) 

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

TobisRipper wrote:
 is its job to, all around interpret the C code

No:  'C' code is compiled on the host - not interpreted on the target.

 

When I flash a bootloader onto an atmega chip using Atmel studio, does it not get overwritten if I upload a sketch using a programmer

Not if you configure the programmer properly !

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
'C' code is compiled on the host - not interpreted on the target.
fyi, there are C interpreters for MPU.

  • Wind River Systems VxWorks RTOS
  • SoftIntegration Ch
  • Cling

Python is a new arrival to VxWorks.

 

Wind River's IDE :

Workbench | Development Tools | Wind River Systems

Workbench sheet :

https://www.windriver.com/products/product-notes/workbench-product-note.pdf

[page 8, right column]

VxWorks Kernel Shell

...

Both shells include a C and command mode CMD interpreter; the Host Shell also provides a Tcl and a GDB interpreter

...

An instance :

https://github.com/Wind-River/vxworks7-layer-for-iperf#c-interpreter

A use case (patch)

What really happened on Mars Rover Pathfinder

Mike Jones <mbj@MICROSOFT.com>

Sunday, December 07, 1997 6:47 PM

[mid-page]

VxWorks contains a C language interpreter intended to allow developers to type in C expressions and functions to be executed on the fly during system debugging. The JPL engineers fortuitously decided to launch the spacecraft with this feature still enabled. By coding convention, the initialization parameter for the mutex in question (and those for two others which could have caused the same problem) were stored in global variables, whose addresses were in symbol tables also included in the launch software, and available to the C interpreter. A short C program was uploaded to the spacecraft, which when interpreted, changed the values of these variables from FALSE to TRUE. No more system resets occurred.

 

Embedded C programming and scripting with embedding Ch

Instances of Embedded Ch are most likely on Arm Linux and Blackberry QNX RTOS (Microchip SAMA5 and such); 3MB of storage.

 

Cling Documentation | GOREPL

Cling is on ARM64 Linux.

 

VxWorks Now Has a Pet Snake | Wind River Blog (Python)

 

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

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

OH man, 21 posts into a dead PCB Thread and we are missing the most important information needed:

 

Please post a true, accurate, full schematic of your project (PCB), including all of the micro's pins, by-pass caps, etc.

 

Please post a decent photo or two of your PCB.

 

Maybe it is truly a dead board, and not salvageable, but perhaps there is just an simple correction or two that will bring it to life.

It would be nice to bring this board to life as you might well then learn even some more items you wish to include on your Version #2 PCB.

 

As for debugging with your scope, some good suggestions were made above.

Hook the O'scope probe's Ground lead up to the Ground on the PCB, or the Ground on the power supply.

Attach a piece of fine gauge wire to the O'scope's probe, it will be easier to use than the probe itself when checking pins on the micro.

 

Pull out your data sheet for the micro.

Check the power supply's voltage at the input and output of the power supply, if it is on the PCB.

Otherwise check the V+ rail on your PCB.

 

Check the voltage on EACH Vcc and AVcc pin on the micro.

 

Try looking at the Xtal pins, one at a time, with respect to ground.

The O'scope can load the oscillator down, and it can stop oscillating, but in the x10 position you can probably see the clock (oscillator) signal.

It will likely be a 16 MHz, roughly sine wave of a rather low amplitude.

Depending upon the O'scope, the uC, the pin you are looking at, and the probe, the clock signal might look somewhat square-ish.

A squarish-ish or sine wave at 16 MHz is what you want to see, not a flat line.

 

The reset\ pin should be high, (Approx Vcc).

 

You might well have the ISP header backwards, (as was mentioned above), or have a shorted connection when you soldered on your ISP header jumper wires.

 

Don't toss the PCB until you have posted the schematic and the photo (s) !

 

JC

 

Edit:Typo

 

Last Edited: Fri. Sep 13, 2019 - 09:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try looking at the Xtal pins, one at a time, with respect to ground.

 

 

If the chip is still factory-fresh, it will be on int OSC---I don't believe you will see any clock on xtal pins without making fuse adjustments of the default factory config (or maybe I've never looked!). 

 

A schematic was requested in post #2, but we have yet to get it!!!

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

Now 23 posts it I will ask an even more obvious question

if the chip is in factory default it will be running at 1MHz, is the clk rate of the programmer slow enough?

 

i  have to use -B1000 with avrdude  and my APSusb programmer  on 1MHz chips