AVR Freaks

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

Posted by frax84: Wed. Sep 16, 2020 - 08:04 AM

Hello,

i know this topic has been covered tons of times on this forum but i'm still not able to find a solution, so here i am :)

As the title says, my problem is that i'm not able to enter program mode trying to program a brand new ATMEGA32u4 on my custom board through the ISP port. At first, let me give you some details:

MCU: ATMega32U4-MU

Programmer: ATMEL-ICE

Software: Atmel Studio 7.0

Notes on the MCU circuit:

- MCU soldered "as is";

- HWB pulled to Vcc;

- Murata resonator 8MHz (capacitors built-in);

- Circuit is based on the schematic of Feather Lora by Adafruit;

- USB and ISP connector available on my custom board. MISO, MOSI, SCK, RST, VCC, GND are connected to a 50mil-spacing 3x2 connector and mapped following ATMEL-ICE Adapter specifics; USB is connected through 22Ohm resistors as required;

- MCU is supplied by a 3.3V regulator (there are capacitors on VCC terminals even if not visible in the following schematic);

This is the schematic i'm using:

MCU_circuit

When i connect my board to PC using USB the device shows up in device manager:

Device_manager

When i use USB i'm able to see the device in Device Programming as "ATmel Mega DFU" and read correctly Device signature ("0x1E9587") but i'm not able to "Read..." memories (Flash/EEPROM). I didn't try to erase or program because i'm afraid to worse the situation.

If i use ISP with Atmel ICE I'm able to read Vcc target and nothing else because of "Cannot enter programming mode..." error.

I checked wiring for ISP and probed the resonator and verified there is a 8MHz at XTAL inputs of MCU.

I think there is a fuses setting problem, but i'm not able to understand if and what i can do to solve. The objective is being able to set fuses (and, lately, to burn a bootloader inside).

Any help is appreciated.

Thx

Frax

This topic has a solution. Jump to the solution.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, solved, ATmega32U4, Atmel-ICE, AVR042

Last Edited: Fri. Sep 18, 2020 - 07:43 AM

Level: Raving Lunatic

Joined: Wed. May 2, 2007

Posts: 6292 View posts

Location: Nieuwegein, Netherlands

Posted by meslomp: Wed. Sep 16, 2020 - 08:26 AM

were is the ISP connector in your schematic?

Have you tripple checked the datasheet that you used the right processor pins for connecting the ISP?

Have you tripple checked the ISp connections. A lot of the cases come tot he conclusion that the ISP connector is mirrorred on the posters board...

What is the programming frequency? and is that in the safe specified area.

I do not know this specific processor, but for other chips there is a clkdiv8 fuse when that is set the actual clock is divided by 8.

With a 8MHz resonator ( is that actually accurate enough to do USB coms???? ) that would give a CPU freq of just 1MHz and then the programming frequency should be below 250KHz ( think from 250K next step is 125KHz.....

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

Posted by frax84: Wed. Sep 16, 2020 - 09:19 AM (Reply to #2)

Hi meslomp,

thank you for your answer.

1) The ISP connector is placed in another sheet, but here it is my connector on the schematic, on the PCB (top view) and ATMEL ICE SPI connector pinout (top view)

ISP ISP_topview spi_header

As Datasheet shows in the pinout at pag. 3 i connected SCK= pin 9, MOSI = pin 10, MISO = pin 11, RESET = pin 13, GND and VCC to respective lines. I checked with tester the MCU pin - ISP pin couples and they're ok. Please notice that ATMEL-ICE adapter has a mark on pin 1 and my connector has a mark on pin 1, so connector is not an issue. Moreover, when i plug USB to supply Vcc the Atmel "target supply" led turns green and i'm able to read Vcc (it would be impossible if i flipped the connector).

2) Programmin frequency (ISP clock) is 125KHz (i tried lower frequencies, no success). Resonator is 8MHz (probed and oscillating, checked for right pins), so this should not be an issue even considering CLKDIV8 fuse

3) Specifics about USB coms with this chip says that no full speed USB can be obtained, but you can use it reliably at lower speed.

Level: Raving Lunatic

Joined: Wed. May 2, 2007

Posts: 6292 View posts

Location: Nieuwegein, Netherlands

Posted by meslomp: Wed. Sep 16, 2020 - 10:30 AM

That all seems to be OK except for 3, that gives me a bit of doubt but that is more to do with you using a resonator that can have a percentage deviation with respect to a crystal that has PPM deviation. The datasheet states that by default the chip runs from teh extrenal XTAL you confirmed that. But then it should be able to do fullspeed USB according to the datasheet.

Interestingly enough according to the datasheet there should not be a bootloader present in the device, but yet it almost looks like you have some sort of bootloader active. I have never used these devices so do not know exactly how they behave out of the box.

You could give the chip a full chip erase. All that should do is clear the entire flash (which should be empty) and reset all the lock bits ( which might be what you are having trouble with at the moment.

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

Posted by frax84: Wed. Sep 16, 2020 - 12:36 PM (Reply to #4)

I'm pretty confident (even if not 100% sure) that USB can work with this setup, even considering i'm able to see the device and its signature correctly using it. PPM deviation should be enough low to allow low-speed USB (1.5MHz).

I tried to give the chip a full chip erase. I'm able to do it using the "ATMega DFU" interface. In this case the chip erases correctly (or, at least, ATMEL Studio states that it succesfully erased the chip). Unfortunately, this doesn't change anything from the ISP side. I'm not able to perform Chip erase from ISP. Even if i do chip erase from "ATMEGA DFU" interface i still cannot access the fuses in the ISP (same error "can't enter programming mode").

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30454 View posts

Location: Wormshill, England

Posted by david.prentice: Wed. Sep 16, 2020 - 01:37 PM

1. it is wise to use a square pad for pin #1 on a header footprint. (as well as the white dot)

2. a box header ensures that your ribbon connects correctly.

The pcb layout "looks" like a through-hole 3x2 male ISP header.

The copper traces would be ok for the component side but I suspect that they actually show the reverse side.

Otherwise, your schematic looks fine. I would expect ISP to work fine.

But since DFU is working, why do you want to mess with ISP ?

David.

Last Edited: Wed. Sep 16, 2020 - 01:38 PM

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

Posted by frax84: Wed. Sep 16, 2020 - 01:58 PM (Reply to #6)

Hi David,

1) i printed a dot on the silkscreen on pin1 of the header footprint exactly to avoid inserting the ISP connector in the wrong direction;

2) i didn't use a box header just because of space, but the dot should be more than enough unless i'm drunk :)

The pcb layout IT IS a trhough-hole 3x2 male ISP header. The picture is TOP VIEW. Moreover, i verified with tester that i have pinout matching so unless i'm stupid (thing that i cannot be 100% sure about) it should be ok.

Still, ISP not working at all...

I'm still almost a newbie about DFU and similar. I'm trying to step deeper inside "how the things work" from few months. I would like to set fuses, burn bootloader or application inside the MCU. From what you say it seems like i can do it with DFU. If i understood well, can you spend some words about how to (i.e.) modify fuses with DFU? Or maybe you can address on some reading about it?

Thank you,
Frax

Last Edited: Wed. Sep 16, 2020 - 02:00 PM

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30454 View posts

Location: Wormshill, England

Posted by david.prentice: Wed. Sep 16, 2020 - 02:31 PM

Ah-ha. I was pretty confident that you did know what you were doing. No harm in "checking".

Likewise, I would check the continuity of each pin on the 3x2 header with the pin in the TQFP. You are relying on a plated through hole to work at the 3x2.

DFU can program the EEPROM and FLASH memories. It can not change the fuses.

In practice, you seldom want to change fuses. You seldom want to change bootloader since the DFU is 100% ok.

If you don't have a DMM to check continuity, you can upload a program (via DFU) to wiggle the pins on the 3x2.

I am 99.5% confident that your schematic, ATMEL-ICE, resonator, DFU, ... should all be fine.

But the problem will be a trivial broken/shorted wire, ribbon, pcb trace, ...

Continuity tests may seem low-tech but that is where I would put my money.

A nice cup of tea helps too.

David.

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

Posted by frax84: Wed. Sep 16, 2020 - 03:29 PM (Reply to #8)

:) I'm actually a bit confident of what i'm doing. Even if it would be surely wrong defining myself an expert i'm not a totally newbie, but i think you can "evaluate me" from my answers. I really don't like "trial and error" approach. I want understand things.

BTW, checking the connections was one of the first things i did and you're absolutely right about being extremely careful about this "trivial" things, even more because i'm not using TQFP package, but VQFN one that is even more dense. Vcc and GND have been "autochecked" by the fact that i'm able to read "Target voltage", while i verified pin by pin SCK, MISO, MOSI and RST. Everything is connected!

In practice, in my project i need to modify the fuses to disable some peripherals and reduce power consumption, so this is a thing i need to achieve.

There is one thing i can add to (hopefully) give anyone an idea to help me. Before integrating everything on my custom board i realized a "breadboard-version" of the board and it works just fine. For this reason the schematic should be fine. From a component point of view the differences are that the breadboard-version uses TQFP and not VQFN package for the Atmega32u4 and the ISP connector is a 100mil 3x2 versus 50mil 3x2 of my board. Of course each passive component is TH type in breadboard and SMD type in board.

Frax

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30454 View posts

Location: Wormshill, England

#10

Posted by david.prentice: Wed. Sep 16, 2020 - 04:08 PM

QFN chips are a nightmare. At least you can poke a probe at a TQFP.

Seriously, you can disable peripherals, prescale clock speed, sleep, ... all in software.

You can even preserve EEPROM contents via software. (I am sure it is part of DFU)

You should be able to do everything with DFU and your program.

What is the specific power problem?

I would feel happier if you could communicate via JTAG or ISP. I am sure that it will be nothing more than a "wiring" problem.

David.

windoze_killa

Level: Hangaround

Joined: Thu. Apr 6, 2006

Posts: 191 View posts

Location: Cairns, QLD, Australia

#11

Posted by windoze_killa: Thu. Sep 17, 2020 - 12:53 AM

Hi All,

Firstly Frax, well done on the very clear first post. So much better when all that sort of info is supplied.

Now. I would try this. I am assuming that if you checked the OSC and it was 8MHz you may own a CRO. If so, whilst trying to access via the ISP check the SCLK signal on the header. If that is there try checking the MISO and MOSI preferably with dual channel and see if it is actually trying to talk to the chip. It may be your ISP.

I have had quite a few ARVISP Mk2's that have failed. They are very flaky IMO.

Level: Raving Lunatic

Joined: Wed. May 2, 2007

Posts: 6292 View posts

Location: Nieuwegein, Netherlands

#12

Posted by meslomp: Thu. Sep 17, 2020 - 07:04 AM

Ok, what happens on the working board when you during programming move the programmer around.

I have had a some what similar problem were it turned out there was a problem with my ISP cable from the SIP MKII to the DUT.....

I would have it on one board worked without a problem. Connect second board ( and thus move cable and connectors) and nothing worked or it intermittently worked.....

Back to the first board again moving things around everything worked again without a problem.

In the end also the second board would start behaving strangely, so I started investigating further ( first board was not nicely soldered so I threw it aside as having a solder problem initially) and only then found out there was a problem with the cable connector at the CPU side. This was because it does not have a strain relief, so you slowly move the cable inside the connector. All it took was a 6pin box header connector with strain relief and all was OK again. But it was a PIA to find out as it was intermittent .

IN your last reply you are only talking about ISP programming.

Have you tried JTAG programming?

This because when using ISP you can disable JTAG, but not ISP itself..

with JTAG you can disable ISP and ultimately JTAG too, but that will have caused a lot of warnings initially.

As already asked you might want to load a small program using DFU ( as you seem to be able to program still that way) that toggles the ISP lines individually and make sure you see the right line toggling ( and only that line ) . Also check the adjecent pins to see if there is not a short there as that could also cause trouble.

As a side note I did a quick second check of your schematic with the datasheet. A couple of things surprise me, now they might be OK, but better check the details.....

1) you have not connected UVCC. This seems to be the USB internal regulator input supply. Not sue but have you checked that you can leave that floating? as it might cause somethings to not be initialized correctly for USB to work properly.

2) you have connected 3V to the UCAP pin. This is the output of the regulator, you are sure that you can connect an external power supply to that pin as again it might cause things to malfunction internally in the chip.

As a side note I read that they are talking about PDI programming and not ISP programming. Wonder... is your programmer capable of doing such? I have no experience with PDI so might be completely off as it is the same, but perhaps another freak can elaborate on that.

and I miss a small capacitor on the Reset line. I would expect a small 1nF - 10nF capacitor connected from RST to GND as to allow the power supply to stabilize a bit before the processor starts running.

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

#13

Posted by frax84: Thu. Sep 17, 2020 - 09:14 AM

Dear all,

at first, let me thank you for the time you're spending to help me. I hope it won't be wasted. At second, let me answer you all:

@david:

- I know QFN chips are harder to manage, but i did it to gain few mms on the board because of some dimensional constraints of the project :( Btw, i made a footprint so that i am actually able to poke QFN pins quite reliably (not so easy, but doable).

- I know i can perform these operations by software, but my project aims to preserve as much (battery) power as possible and, considering how the system works (i sometimes use a reset and i would prefer to not handle the "hardware (fuses) setup" everytime. By the way, for the sake of knowledge, i made some tests in this direction and i'm afraid that even using USB-DFU, something is a bit off. Erasing seems to work (at least, it writes that is ok, but i learned that this is not 100% reliable), but if i try to write an hex and verify, it always fail. I don't feel really knowledgeable for this topic, so this could still be me, but as i said, i would prefer focusing on ISP;

- I didn't implement JTAG connector on the board. I tried to keep things simple. Being "ignorant" i preferred to be conservative designing only things i was sure about (even if it turned out i had not to be so sure :D);

- About the wiring problem, for the sake of my autism, i re-re-re-rechecked it. I verified the continuity among every MCU pin and the corrispondent pin of the male ISP connectorof the board. Moreover, i verified continuity between ISP female connector of the Atmel ICE adapter and the ribbon cable. Finally, i'm able to use the ISP of my breaboard-version of the board, so the Atmel ICE itself should be fine. This should close the circuit about wiring testing, if you think i'm missing something please tell me :)

@windoze_killa

Firstly, thank you :D i usually use my own post to summarize if i did all i could to solve the problem by myself.

You're assuming well, i'm using a CRO. More in details, it is THIS ONE

I did some tests about probing SCK pin and i obtained some interesting result i want to share with you all. I used my DSO (200MHz scope) to perform SCK probing while trying to read chip signature. This is a screenshot of what i obtained (please notice the cursors value on the right).

scope_CLK_board

Here it goes! Both amplitude (~1V) and frequency (8KHz) have no much meaning. I expect them to be respectively Vcc (3.3V for custom board and 5V for breadboard-version one) and 125KHz. To confirm my assumptions i performed the same test on my breadboard-version of the board and this is the result:

scope_CLK_breadboard

As it should be frequency is 125KHz (as set in ISP setting dialog) and amplitude is Vcc (5V in this case).

At this point, this seems to be the issue. In fact, in the custom board both voltage and frequency are wrong (actually with such low voltage is the same as saying that there is no CLK signal at all). Thinking about the differences between the two different setups (custom board and breadboard-version), i wonder if the Vcc voltage could be the issue. I'll try to perform some tests on this, but in the meantime i would like you share your opinions about this with me.

@meslomp

Even if found the problem you can read above, i didn't neglet to perform some tests about what you said. I made some tests on the connector, clipping the pins at the end (or better say to the beginning) of the ribbon cable and probing on the pin of MCU. Even if moving the connector around connection seems to be pretty reliable.

I can't try JTAG programming. Due to some space limitations i did not provide a proper connector on the board for it :(

As i said above, i'm not sure about DFU if it is REALLY properly working, because when i try to program some hex through it verify programming alway fail.

About your circuit notes:

1) Yes, i did not connected UVCC but this should be fine for my configuration. Please watch fig.21-6 of the Atmega32u4 datasheet "Typical Self Powered Application with 3.0V to 3.6 I/O". It clearly show to NOT connect UVCC

2) Yes, i am sure. Please check the exactly same figure of 1)

About the side note about PDI/SPI programming. As i stated before i have the exactly same circuit (working at different Vcc - to be exact there are some slight differences due to different Vcc, but this should not apply to programming) and i'm able to program it, so as things are i don't get a reason to doubt that this dshould work.

About the small cap, this gave me a bit of headache during board design. In fact, there are many different opinions online regarding the use of a cap on the RST line, that could cause some issues. Honestly, i got a huge help on my design from Feather Lora from Adafruit, and they don't place the cap, so considering they're far more reliable than me, i just did the same :D

That's all folks for now,

please let me thank you again for the neurons you're sharing with me

Frax

Level: Raving Lunatic

Joined: Wed. May 2, 2007

Posts: 6292 View posts

Location: Nieuwegein, Netherlands

#14

Posted by meslomp: Thu. Sep 17, 2020 - 10:46 AM

Do you apply power to your board at all?

Keep in mind that the programmer is not going to provide power to your board, so you have to apply it yourself.

When you apply power to your board is the working voltage of the processor then 3,3V as you state in the schematic?

What is it when you connect the programmer?

And what is happening to it when you actually start programming.

Keep in mind that the actual working voltage is related to the programming in that with lower voltages the maximum operating frequency gets lower( at least for the standard mega and tiny chips it odes, so see datasheet if I am correct or not)

Now having written that, a 1V supply voltage is to low for the processor to work anyway......

Think you might need to get the power supply sorted first.

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

#15

Posted by frax84: Thu. Sep 17, 2020 - 01:17 PM (Reply to #14)

Do you apply power to your board at all?

Yes, i keep USB connector connected while programming just to provide Vcc

Keep in mind that the programmer is not going to provide power to your board, so you have to apply it yourself.

I'm aware about that. This is clearly stated in the ATMEL ICE manual. This is not the case

When you apply power to your board is the working voltage of the processor then 3,3V as you state in the schematic? What is it when you connect the programmer?

Yes, when i read "Target voltage" using ATMEL-ICE the reading says "3.3V". I confirmed it probing with a DMM: 3.3V

And what is happening to it when you actually start programming.

I measured it while programming using my DMM. Perfectly stable at 3.3V up to the third decimal :D

I know that, but 8MHz at 3.3V is quite standard for such devices isn't it?

Now having written that, a 1V supply voltage is to low for the processor to work anyway......

Think you might need to get the power supply sorted first.

I agree. I'm spending my time investigating about this issue, but everything is connected according to datasheet Fig. 21-6. It should be fine...

Frax

jgmdesign

Level: Moderator

Joined: Mon. Mar 19, 2007

Posts: 17735 View posts

Location: Long Island New York

#16

Posted by jgmdesign: Thu. Sep 17, 2020 - 01:27 PM

Heres an idea, that probably has been tried....then again....

Slow your ISP clock frequency down to the lowest setting - I believe 8Khz and see if you can red the device signature. If yes, then try programming. If no, then there is something in the wiring.

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

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

#17

Posted by frax84: Thu. Sep 17, 2020 - 01:38 PM (Reply to #16)

Hi jgm,

every idea, even the simplest one, is well accepted :D

By the way, yes, i already tried to lower che ISP clock at minimum. As you can see in a previous post (one with oscilloscope screenshot) i found a problem on SCK line that has a wrong voltage and frequency when trying to program. I suspect being something related to power, but i can't find any error by now.

Frax

ki0bk

Level: Raving Lunatic

Joined: Mon. Sep 8, 2014

Posts: 8400 View posts

Location: Olathe KS

#18

Posted by ki0bk: Thu. Sep 17, 2020 - 03:20 PM

frax84 wrote:

i need to modify the fuses to disable some peripherals and reduce power consumption,

Huh, say what? With the exception of turning off the BOD, I don't know of a fuse that would reduce power consumption? What are you talking about?

One disables or shuts down peripherals using the enable/disable bits of the control reg, or the PRR reg to turn on/off power to peripherals, using software, not fuses.

but that is secondary to the problem of not getting the PDI to work.

Can you read the device signature? Nothing else will work until this does.

Can you post a clear picture of your setup, showing the programmer connected to the board?

Not having a jtag connector on a prototype was a mistake, you may want to see if you can patch in a connector for that, or do another board spin to add one until your software issues have been resolved and your ready for a production pcb.

Designing a low power project takes some trial and error, for both the h/w and the s/w, so having a jtag connection is recommended during that process.

Jim

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

Shared Use of SPI Programming Lines | AVR® Microcontroller Hardware Design Considerations

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

#19

Posted by frax84: Thu. Sep 17, 2020 - 03:51 PM (Reply to #18)

Hi ki0bk,

Turning off the BOD, as you stated, is one of the things i need. Disabling JTAG, Watchdog and OCD reduces consumption too. It's a bunch of uA for each device, but i have a project where i need to keep device in sleep for (possibly) long times, so power consumption during sleep is a huge fraction of the total consumption. You're absolutely right, most of these operations can be performed by software, but i don't want to worry about this part and having the possibility to set it by fuses, why not? You think is a wrong approach? I have not so much experience to evaluate why i should avoid using fuses for such things but, whatever, this is off-topic right now and i don't wont to bore you with my noob-like statements :)

No, i can't read the device signature, as i already wrote. As you correctly state, nothing else will work until this does, so that's why i'm here.

You're right, having a JTAG would have been better, but i had to choose. I want to underline that i already tested the same circuit on with the exactly same components (except for resistors and capacitors), so it's not a v0 prototype. In any case if you read the post where i show screenshot about scope, you will see that there is a major issue with SCK line. I suppose that JTAG could not be helpful in this case. In any case, the more interfaces, the better, i totally agree on this.

Last Edited: Fri. Oct 2, 2020 - 10:48 AM

jgmdesign

Level: Moderator

Joined: Mon. Mar 19, 2007

Posts: 17735 View posts

Location: Long Island New York

This reply has been marked as the solution. #20

Posted by jgmdesign: Thu. Sep 17, 2020 - 04:12 PM

What do you have attached to that SCK line.

Just for future reference, if you are using the SPI bus for anything other than ICSP I would suggest you put some 220 ohm resistors in series with the AVR pins, and put the ICSP pins directly to the AVR. THis isolates the AVR in case one of the SPI devices is holding the line hostage.

Right side 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

Last Edited: Sat. Sep 19, 2020 - 02:55 AM

gchapman

Level: 10k+ Postman

Joined: Tue. Jan 9, 2007

Posts: 13180 View posts

Location: Clay County, Texas, u.S.A.

#21

Posted by gchapman: Thu. Sep 17, 2020 - 05:57 PM (Reply to #20)

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

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29973 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

#22

Posted by js: Thu. Sep 17, 2020 - 10:04 PM

So you are using the 0.050" spacing connector for ISP, do you have some other board with the "standard" 0.1" spacing connector? You could try that to verify correct operation of the ICE.

And now for silly questions time: You do have the ribbon plugged into the AVR and not the SAM socket...just in case...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

windoze_killa

Level: Hangaround

Joined: Thu. Apr 6, 2006

Posts: 191 View posts

Location: Cairns, QLD, Australia

#23

Posted by windoze_killa: Thu. Sep 17, 2020 - 11:14 PM

frax84 wrote:

Do you apply power to your board at all?

Yes, i keep USB connector connected while programming just to provide Vcc

Frax

I am not an expert on AVRs but just a thought. Remove the USB connector and power it from an external 3.3V or 5V. Maybe the USB port is hanging the device somehow.

Level: New Member

Joined: Wed. Sep 16, 2020

Posts: 10 View posts

#24

Posted by frax84: Fri. Sep 18, 2020 - 07:56 AM

jgmdesign wrote:

What do you have attached to that SCK line.

Just for future reference, if you are sing the SPI bus for anything other than ICSP I would suggest you put some 220 ohm resistors in series with the AVR pins, and put the ICSP pins directly to the AVR. THis isolates the AVR in case one of the SPI devices is holding the line hostage.

Right side Jim

And that's it! This was the problem! For the sake of knowledge this is what i tried. There is an SPI device on my board. I built a pull-up network on the CS line to make it "non active" believing that MCU had "high impedance" on that pin. Unfortunately i was wrong and CS line is actually pulled low so that the SPI peripheral is "Active". To make a test i shorted the CS pin of the SPI peripheral with Vcc to force the device to be "Not active" and, luckily, that was enough to read MCU signature and fuses, etc.

Because of my poor experience didn't know about isolating the SPI lines using resistors as suggested by both jgmdesign and gchapman. This will be surely part of the next board rev.

Thank you all for the support you provided me. I not only was able to solve the problem, but also learned many things.

Frax