Device Signature 0x000000, ATMEGA328P-AU

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

Hi all,

 

I am currently building a project from Thingiverse...specifically this project....  https://www.thingiverse.com/thing:3708466

 

Copy of the schematic can be found here...  https://cdn.thingiverse.com/assets/93/15/35/78/c6/Schematic.pdf

 

I am at the stage of uploading the Arduino bootloader via SPI comms to the ATMEGA328 so I can then upload the code via Arduino IDE (UART), however, I am always getting "Device Signature = 0x000000" from avrdude when I try to burn the bootloader. I am using an Arduino UNO as an ISP programmer, I have tried powering my project board from the UNO and from a dedicated power supply to no avail.

 

One thing to note is that the project board does not have any pads or headers broken out to the SPI lines, so I have had to solder some 30AWG, kynar insulated wire directly to the pins of the IC (photo's below).

 

 

 

I have also connected the scope while doing the upload and what I can see is that the MISO line (response from project board to the programmer) doesn't go up to 5v, it peaks at 3.84v when high according to the scope. See screenshots below.

 

Yellow = Clock; Pink = MISO; Blue = MOSI; Green = Reset

 

 

 

 

 

Checked the usual (connections, power, etc, but it is all there)

 

Oh!! One last thing, the 16MHz crystal oscillator is NOT oscillating!! When I put my scope probe onto XTAL2 or even XTAL1, the voltage rises to approx 1V, but it is DC, there is not clock signal.

 

I am assuming this is because the microcontroller is still using the internal clock it is set to use from the factory? For completeness sake, I even uploaded the modified ArduinoISP code which creates a 16MHz clock on pin 3 of the Arduino UNO. I have used this in the past to sort problems when the fuses were set incorrectly, but it did nothing for me here.

 

Any suggestions or thoughts which might help?

This topic has a solution.
Last Edited: Sat. Dec 14, 2019 - 10:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I only see three wires...you need four plus a ground lead.

 

Total 5.

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Well, not apropos the specific question, but I think I see some badly adjusted probes.

 

Have you EVER been able to talk to it? Maybe just once, enough to set fuses? If so, I'll bet that you set the CKSEL fuses for EXT OSC, not external crystal or resonator. What you report is typical of no operating clock. Usually, the default is internal RC oscillator. If it is NOT doing that, and if the crystal is not oscillating, then likely incorrect fuse.

 

A second alternative is that it is still running on the internal RC oscillator and you have the ISP clock too fast. Try setting the programmer SPI clock to 125KHz.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

jgmdesign wrote:

I only see three wires...you need four plus a ground lead.

 

Total 5.

JIm


 

Sorry, forgot to say, I only had to solder the MOSI, MISO & SCK lines, the 5V, GND & Reset lines attach to that 6 pin header, just not shown connected in the pic is all.

 

ka7ehk wrote:

Well, not apropos the specific question, but I think I see some badly adjusted probes.

 

Have you EVER been able to talk to it? Maybe just once, enough to set fuses? If so, I'll bet that you set the CKSEL fuses for EXT OSC, not external crystal or resonator. What you report is typical of no operating clock. Usually, the default is internal RC oscillator. If it is NOT doing that, and if the crystal is not oscillating, then likely incorrect fuse.

 

A second alternative is that it is still running on the internal RC oscillator and you have the ISP clock too fast. Try setting the programmer SPI clock to 125KHz.

 

Jim

 

In what way do the probes look badly adjusted? They are set against the calibration signal on the scope with the probes compensated to provide the sharpest square wave I could get. Then again, it’s only a Siglent 1104X-E, so a lower end scope with most likely budget probes. However it does the job....

 

Back on topic, no I have NEVER communicated with the IC, it’s a virgin chip, only just installed today. When I have had the fuse issue you mention I have managed to get it back and working by using an external signal generated from pin 3 on the Arduino Uno and injecting it into the XTAL1 line on the IC, but as this is brand spanking new, it can’t be that, and I have tried that already just incase, but with no luck.

 

Could we’ll be trying to communicate to it too fast! Will lower the SPI clock in the morning....1:30am in the UK just now. Any other suggestions, please let me know, will be back to it when I get up tomorrow (today).

Last Edited: Sat. Dec 14, 2019 - 01:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A "virgin" 328x has fuses set for internal clock with CKDIV8 set, to produce a 1MHz FCPU. Thus, you will NOT see any clock signal on the crystal. Further, the SPI system MUST run SLOWER than 1/4 of FCPU. I set 125KHz to be certain.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Just checked, looks like the default ArduinoISP code is set to run below 1/4 of FCPU anyway (1/6 of FCPU), I did change it to 1/8 FCPU (125KHz) but nothing changed, he is the part of the ArduinoISP code which refers to the SPI Clock speed....

 

// Configure SPI clock (in Hz).
// E.g. for an ATtiny @ 128 kHz: the datasheet states that both the high and low
// SPI clock pulse must be > 2 CPU cycles, so take 3 cycles i.e. divide target
// f_cpu by 6:
//     #define SPI_CLOCK            (128000/6)
//
// A clock slow enough for an ATtiny85 @ 1 MHz, is a reasonable default:

#define SPI_CLOCK 		(1000000/6)


// Select hardware or software SPI, depending on SPI clock.
// Currently only for AVR, for other architectures (Due, Zero,...), hardware SPI
// is probably too fast anyway.

#if defined(ARDUINO_ARCH_AVR)

#if SPI_CLOCK > (F_CPU / 128)
#define USE_HARDWARE_SPI
#endif

#endif

 

Anything else I can try?

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

One image that keeps grabbing my attention is this one....

 

 

Notice how the MISO line (Pink) comes up on its way to 5V as the reset line (Green) drops, then as the reset recovers the MISO signal begins to fall! Then shortly after the reset line recovers it dips momentarily, and during that period the MISO line jumps up to 5V then drops back down once reset recovers.

 

To me it looks like something related to the reset line is pulling MISO down to just sitting at 3V and if I remember correctly a high value for SPI is VDD x 0.6 which would be 5 x 0.6 = 3V...so the programmer might be seeing all 0's as a response due to the MISO line never getting high enough.

 

The only thing the MISO line connects to is a 74 series IC which controls some LED's. However I did remove this to test and the signal remained identical, so something is pulling down the MISO line in relation to reset, but not sure what.....

 

Or am I going of in the totally wrong direction here? Thoughts?

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

Ok...I have another board here with a different IC. I have just burnt a bootloader onto that using the exact same method.

Reset line drops low and STAYS LOW during the entire process. The fact my MISO line drops down when reset goes high is expected. So the issue is reset is going high when it should be kept low.

The question is why?!

Confident that if I can sort this then it should work.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GOT IT WORKING!! laugh

 

The issue was that I was connecting the reset to the 6-pin header which goes HEADER > 100nF Capacitor > RESET on IC, in the end I just connected a wire directly to the RESET pin on the IC and BOOM, it works AND the RESET line goes low and holds low. The capacitor was basically keeping the RESET line held high, hence it dropped down, then would rise up as the capacitor charged up.

 

Feel a bit stupid for not thinking about that earlier, but oh well, at least it's not some major fault.

 

I also now have 16MHz on the external clock.

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

Please mark post #9 as your solution.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Mario875 wrote:
The issue was that I was connecting the reset to the 6-pin header which goes HEADER > 100nF Capacitor > RESET on IC
Well, it's right there in the schematic you posted.

 

Note the other pins on that '6-pin-header'.  That's what's typically used for a TTL-serial interface for a serial bootloader (like Optiboot).  The serial-USB interface typically connects DTR to RESET via a cap, so dropping DTR pulses RESET and starts the bootloader.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Feel a bit stupid for not thinking about that earlier

Thank you for posting the followup explanation, even if it was embarrassing...  It's harder to learn from other people's mistakes when they don't admit them!

 

For your next rev PCB, you have nice vias for two of the three pins you need, and room for the third.  It'd be easier to attach programming wires to vias, if they weren't covered with soldermask.

(although, I'd probably try to fit in a real 6pin ISP footprint...)

 

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

westfw wrote:

Feel a bit stupid for not thinking about that earlier

Thank you for posting the followup explanation, even if it was embarrassing...  It's harder to learn from other people's mistakes when they don't admit them!

 

For your next rev PCB, you have nice vias for two of the three pins you need, and room for the third.  It'd be easier to attach programming wires to vias, if they weren't covered with soldermask.

(although, I'd probably try to fit in a real 6pin ISP footprint...)

 

 

Well we all make mistakes, as long as we learn from them that’s what matters. To be honest, there won’t be another PCB Rev, this was taken from a thinigverse project where they uploaded the Eagle files. I imported them into EasyEDA and produced the Gerber, but only noticed the missing ICSP footprint after the boards had been shipped out.

 

I (wrongly) assumed the originator of the files would have included ICSP pads for when they built their own one. Obviously not....

 

Reminds me to never assume things about other people’s work, because is just makes an ass out of you & me! wink

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

westfw wrote:
It'd be easier to attach programming wires to vias, if they weren't covered with soldermask.
Scrape a trace.

Excessive heat can damage the die (inter-metallic oxide) whereas a damaged trace (lifted) can be re-glued.

Scrape It

IIRC, Steve scrapes solder mask with a pocket knife.

 

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

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

this was taken from a thinigverse project where they uploaded the Eagle files.

 Ah; i saw the comment on the linked project page about "updated PCB", noticed that the original was hand-etched, and wasn't sure who had done what updating.

Does thingiverse have a "bug reporting" section (beyond just the comments)?  It'd be worth putting up a note for others....

 

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

I see that you have a GND plane on TOP, I suppose there is also one GND in back. In that case to take advantage of a good GND plane you have to put GND vias "stitches" to connect both GND planes.

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

- Try to put the decoupling capacitors more closer to the MCU

- Try to put the XTAL more closer to the MCU

- Add more stitches to connect the TOP GND blane with the BOTTOM GND plane

- You are using a PIR sensor, its better to add an Op-Amp circuit attached as a filtering circuit, look for something like MCP6231. this will give you a clean signal and more robust calculations

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

westfw wrote:

this was taken from a thinigverse project where they uploaded the Eagle files.

 Ah; i saw the comment on the linked project page about "updated PCB", noticed that the original was hand-etched, and wasn't sure who had done what updating.

Does thingiverse have a "bug reporting" section (beyond just the comments)?  It'd be worth putting up a note for others....

 

 

Only thing is the comments section to make notes for others. Once I get this fully assembled I may well add a comment with links to gerber files which have ICSP break pads/headers and info on other issues including a couple with the 3D print itself.

 

I have already had to fix some issues when converting the Eagle files to gerbers. If I had used them as-is there would be a huge cut out in the middle of the board where the entire motor unit would fall through rather than just the spindle poking through as is required.

 

There is also no info on the size of spacers required between the motor > PCB > upper part of the base

 

There may also be an issue with the code where it only works properly when it has a serial connection, but I need to fully assemble my unit to confirm if it is a genuine bug or only there when part-assembled (PIR not connected just now). I have found a fix / work around if it is a genuine bug.

 

Basically the project leaves a lot up to the end user to figure out and / or fix for themselves, so there is a lot of info which needs added to the comments to help out others. Ideally, only after I have completed mine and know exactly what they all are.

 

Moe123 wrote:

- Try to put the decoupling capacitors more closer to the MCU

- Try to put the XTAL more closer to the MCU

- Add more stitches to connect the TOP GND blane with the BOTTOM GND plane

- You are using a PIR sensor, its better to add an Op-Amp circuit attached as a filtering circuit, look for something like MCP6231. this will give you a clean signal and more robust calculations

 

As above, this is not my project, but one someone else has done. While I agree with your comments, I do not / did not have the time to implement them. This is a gift for someone and I aim to get it completed this week. However I may be able to implement the changes later and add them to the comments section of the project if I have time.