Jtagice mk2 will no longer work with Studio 4

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

Will a jtagice mk2 with firmware upgraded by Studio 6 work with Studio 4?

I can't get it to connect.

My worst fears have come to pass. Bootloaders I install with Studio 6 JTAGICE mk2 PDI don't work right. I thought I'd try Studio 4, but the JTAGICE mk2 seems to no longer work with Studio 4.

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

Quote:

Will a jtagice mk2 with firmware upgraded by Studio 6 work with Studio 4?

You will/should get a warning about the JTAG-ICE MKII firmware being too new, and be requested to downgrade it first.

Quote:

My worst fears have come to pass. Bootloaders I install with Studio 6 JTAGICE mk2 PDI don't work right. I thought I'd try Studio 4, but the JTAGICE mk2 seems to no longer work with Studio 4.

That is *definetely* not something that should be happening, if you are programming an identical ELF/HEX file. In what way does it not work?

- Dean :twisted:

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

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

Thanks Dean. I found the problem with the JTAGICE on Studio 4. The JTAGICE driver didn't get installed. A maintenance install fixed that. So I tried installing the bootloader with Studio 4 JTAGICE2 PDI and I still have the same problem.

Back to the drawing board.

The problem is probably staring me in the face but I don't see it. I can put an application on the chip using PDI and it works fine. It's only the bootloader that fails. To be clear, this bootloader worked in the past on my old computer.

I am using a new computer with newly installed Studio 6 patch 2, and now also a newly installed Studio 4.19 on another Win7 installation.

When I try to use the bootloader, the verify fails. Location zero contains 0xff and it should be something else. Interestingly I accidentally found something that makes the bootloader work okay, but this something makes the bootloader useless for normal use.

Near the beginning of the bootloader there is an if statement. It looks something like this:

IF BUTTON PRESSED
  Run bootloader.
ELSE
  Run application.

If I change that if statement to
if(1)
the damned thing works okay. The program gets stored okay and verified. If I exit the bootloader, the application runs okay.

I think what happens is the bootloader code is re-arranged in memory. The ELSE code is not included, because the tool chain knows it will never be executed.

I've been testing with my new Xmega128a4u chip and it fails. This chip is the reason I had to go to Studio 6. Now I'm testing with my old Xmega32a4 chip and it fails. It used to work. I've built the bootloader with the new tool chain, and I've built with the old tool chain. I also tried with a bootloader hex file I saved 10 months ago. All fail the same way.

I just had an idea. My old computer is still sitting here. I will try with that computer next.

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

I tried my old computer. The bootloaders that had worked before on several Xmegas have the same problem.

Something happened in the couple of months that I hadn't installed a bootloader. I can think of two possibilities.

1. Somebody put a hex on me.

2. Something got screwed up in my JTAGICE2 when I upgraded the firmware for Studio 6 and remains after downgrading the firmware for Studio 4. Whatever this something is, it only affects the programming of bootloaders. It programs my applications just fine.

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

Are your fuses set right?

Dr. David Harris OpenLCB Development Team openlcb.org

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

I think so. I never changed any. They seem to be the same on all my boards. Actually SUT was different, but I tried all setting of that one.

That does remind me of something. When I first crossed my fingers and upgraded the firmware and looked at the fuses on my new Xmega128a4, the BOOTRST was set. That struck me as odd because in the past I alwasy had to set it. Anyway I tried with BOOTRST set and unset, with the same problem. I also fiddled with SUT as it was different from another board with the Xmega32a4.

The lock bits are all unlocked.

I think it would be a strange fuse that would cause my problem. My applications run fine when put on the chip by PDI. Only the bootloader acts crazy.

I may not be the only one with this problem. I will look at this thread again.
https://www.avrfreaks.net/index.p...
Note, I erronously reported I got my bootloader working, but I didn't realize at the time, it was the if(1) kludge I put in that made it work. I put that in for testing so I wouldn't have to keep pushing the button to enter the bootloader. ;) Just my luck it made the thing work, sort of.

Attachment(s): 

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

I believe you. (You didn't show the lock bits, though :-p -- just the more-fuses again)

I thought that perhaps you weren't uploading the bootloader because you had locked the bootloader memory.

David

Dr. David Harris OpenLCB Development Team openlcb.org

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

dpharris, I realized that after I posted. I'm having internet troubles. Tonight my lousy internet connection is the worst I've ever seen in. Also I can't do previews today. That might be related to my horrible internet connection.

These views are from my old computer running Studio 4.

Hooray, I just did a preview.

Attachment(s):