no reset after JTAG programming ?

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

Hi people,

again I'm sitting on a new board this time with an Xmega and an AVRJTAGICE MK2. And I was wondering why the controller isn't reset after the re-programming. I was used to the behaviour of the AVRISP MK2 which I just could leave plugged to the board, program and then the new code starts. This doesn't work with the current configuration, I have to unplug the ICE and powercycle the board to start the code. Why is that ? I'm not sure about the reset thing at the JTAG and I should mention that I'm using a reset-controller on the board. Is it possible that the ICE actually tries to reset but can't pull down the line ?
Thanks very much for your hints and comments
Mat

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

Which tool are you using to program the device?

Doesn't really sound like a GCC thing.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

AVR Studio 4.16, yes, maybe this is more general, sorry

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

you want to move the thread ?

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

Hey,

Are you using AVR Studio 4.17? I have seen the same there with a JTAGICEmkII, so it seems like this is a bug with XMEGA on 4.17... I've downgraded to 4.16 :-)

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

Quote:

Are you using AVR Studio 4.17? I have seen the same there with a JTAGICEmkII, so it seems like this is a bug with XMEGA on 4.17... I've downgraded to 4.16 Smile

I had the opposite problem -- the reset wasn't issued until I closed the AVRStudio programming window in 4.16, but now works as advertised in 4.17.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

kris10an wrote:
Are you using AVR Studio 4.17? I have seen the same there with a JTAGICEmkII, so it seems like this is a bug with XMEGA on 4.17... I've downgraded to 4.16 :-)

I have the same problem. With 4.16 the board reset, in 4.17 it does not. Also be aware that the BOD voltage values are off by one for the XMega 128A1 in 4.16, so you could lock yourself out of programming a unit, as it will be permanently stuck in reset. This is fixed in 4.17. Also with 4.17 it doesn't crash every few minutes, like 4.16 did.
Quote:
(ATTicket:556383) AVRStudio 4.17 build 666 holds reset until power is cycled avr[at]atmel.com to me Aug 3

Dear Customer,

I can not reproduce this issue on my STK600 + TQFT100 socket + JTAGICE mkII + ATxmega128A1 + AVR Studio 4.17 build 666. Is it possible to check with STK600? Also please check the Reset pin connectivity on the hardware.


Nothing change in "reset pin connectivity" between 4.16 and 4.17 in my setup.

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

Also be aware that the "old" JTAGICE mkII (rev 0?) does not work well with the Xmega series. Although I don't think it affects the reset behavior, it definitely affects the debugging behavior.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

stu_san wrote:
Also be aware that the "old" JTAGICE mkII (rev 0?) does not work well with the Xmega series. Although I don't think it affects the reset behavior, it definitely affects the debugging behavior.

Mine says:
Hardware Revision: 0x01
Firmware Version: 0602 0602

What kind of speed did you get when single-stepping?
It might take 10 to 30 seconds to step between
a couple of NOPs on my setup. Was the same with 4.16 and 4.17.

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

bpaddock wrote:
stu_san wrote:
Also be aware that the "old" JTAGICE mkII (rev 0?) does not work well with the Xmega series. Although I don't think it affects the reset behavior, it definitely affects the debugging behavior.

Mine says:
Hardware Revision: 0x01
Firmware Version: 0602 0602

What kind of speed did you get when single-stepping?
It might take 10 to 30 seconds to step between
a couple of NOPs on my setup. Was the same with 4.16 and 4.17.

That's the latest version of the JTAGICE - just wanted to be sure since we got some really squirrelly behavior with the rev 0.

We have not seen the kind of "slow stepping" you describe, or at least I don't think so or I would have heard about it. You've been around long enough, Bob, that I know you've tried all the basic stuff.

I do wonder if AVR Studio is not happy with the disassembly view. It seems they have been putting a lot of work on making the C source line debugging faster at the expense of the disassembly performance. Of course, if your source is assembly, YMMV.

I will check with the guy who has the most Xmega experience here to see if he has any suggestions (or commiserations).

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

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

Hi, I'm still using 4.16 and my JTAGICE mk2 is Hardware Revision: 0x01 and Firmware Version : 052c 052c . I didn't get the BOD thing, how can I lock out myself ? The fuses show BOD disabled.

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

I think the idea was that if you design an 3.3V system (where BOD, if used, would usually be set to 2.7V) that if you had it set to 4.x V as might be used on a 5V system that the Vcc would never get that high supplied from 3.3V so the CPU would never come out of reset.

To be honest I *think* you'd still be able to ISP it but I guess it's one of those experiments someone would need to do to see if that really is the case.

Obviously if there's a bug in the programming dialog in Studio for the Xmega parts and it actually sets a different BOD combination than you actually asked for then, if nothing else, this would be confusing and may mean you don't have the BOD protection you were hoping for. Wonder if anyone's reported this direct to Atmel?

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

clawson wrote:

To be honest I *think* you'd still be able to ISP it but I guess it's one of those experiments someone would need to do to see if that really is the case.

You have to get Vcc above the BOD voltage, from experiance.

Quote:
Wonder if anyone's reported this direct to Atmel?

They know, as it is in the release notes for 4.17.

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

Quote:

You have to get Vcc above the BOD voltage, from experiance.

For ISP--no. For JTAG, I don't know.

From experience, I might have my STK500 set with VTG of 3.3V working on a dev project. Sally might walk in with half-a-dozen pre-production boards for another app that need new firmware. That app is a 5V app, with BOD set at 4.xV.

So I just jam on the header, and ISP away without changing VTG (during ISP the app is programmer-powered). No real problems, except that the app doesn't start after ISP 'cause it never comes out of reset.

Now, that is with my ISP programming software. I suppose that the ISP software could be written to check /RESET after it is released to see if it goes high. (IIRC /RESET goes low when in BOD?)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
Quote:

You have to get Vcc above the BOD voltage, from experiance.

For ISP--no. For JTAG, I don't know.

True. I'm dealing with XMega 128A1 with PDI and JTAG,
not ISP. Don't know about PDI. I do know with JTAG
you have to get Vcc above BOD, otherwise I'd have
some dead board, due to Studio's bad settings.

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

Hi, I know, this is an old thread, but I just updated to AVRStudio4.18 SP2 and the same thing happens again, I have to power cycle my board to start the new code. D.mn! Why isn't this solved/changed by now ? Or is there any special reason why this is supposed to be like that ?