AVRISP MKII / Atmel Studio - Another problem with ISP clock speed.

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

Hi there.

 

Here's the good old error:

Timestamp:    2014-10-28 16:37:56.891
Severity:        ERROR
ComponentId:    20100
StatusCode:    131101
ModuleName:    TCF (TCF command: Device:startSession failed.)

Unexpected signature 0x00000000 (expected 0x001e9311).

 

Windows 8

Atmel Studio 6.2.1153

AVRISP MKII

Attiny 88

 

Recently reinstalled Windows and AtmelStudio along with it. Copied my "projects" from the old installation and have continued working with them since the reinstallation, programming no problem etc. Today I started a new project and get this error when I try to program the device ( Attiny88 ). I am actually able to program using "Device Programming" and manually resetting the god damn ISP clock every time(from 1MHz to 125kHz. Default fuses on Attiny, 8MHz clock, divide by 8 = 1MHz). When I push "F5" the isp clock goes back to 1MHz and I get the error. Can't help thinking it's a software problem, since the old project continues working fine and doesn't change the isp clock setting. Programming same chip, not messing with the breadboard, so no cable problem.

 

Found a similar problem on EEVBLOG forum. Poster claims to have opened a thread about this here, but I can't find it. http://www.eevblog.com/forum/mic...

 

Anyone else getting this problem?

 

EDIT: https://www.avrfreaks.net/forum/a...

Last Edited: Tue. Oct 28, 2014 - 04:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just installed latest version of Atmel Studio. Tried AVR-ICE too. Problem continues, now also with old "project". Programming still works through "Device programming" as long as I manually set the ISP clock lower. With the new version of AtmelStudio I get a different error message:

 

Failed to launch program.

 

Error: Failed to start programming session before chip erase with eeprom preserve: Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xcc, expected 0x00(Unknown status message)

Last Edited: Tue. Oct 28, 2014 - 06:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anybody have a solution for this?

 

Same problem - F5 doesn't program the chip - it gives:

Failed to start programming session before chip erase with eeprom preserve: Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xcc, expected 0x00(Unknown status message)

 

Where Device Programming always works.

 

This is on AVR-ICE. The project setting clock speed keeps resetting and never saves.

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

I think I figured out the solution.

In the .proj file, ATMEL stores the setting as IspClock, but they don't read it back as IspClock. They try to read it back as DebugWireClockDiv, but that never exists.

 

So just open the .cppproj file and search for the following, and add the element to match your IspClock.

 

    <com_atmel_avrdbg_tool_atmelice>
      <ToolOptions>
        <InterfaceProperties>
          <IspClock>50000</IspClock>
          <DebugWireClockDiv>50000</DebugWireClockDiv>
        </InterfaceProperties>
        <InterfaceName>ISP</InterfaceName>
      </ToolOptions>

 

<com_atmel_avrdbg_tool_atmelice>
  <ToolOptions>
    <InterfaceProperties>
      <IspClock>50000</IspClock>
      <DebugWireClockDiv>50000</DebugWireClockDiv>
    </InterfaceProperties>
    <InterfaceName>ISP</InterfaceName>
  </ToolOptions>

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

I had the same problem for days but just now i changed the ISP clock in interface settings to 32kHz and works perfectly.

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

Can someone tell me why the Atmel Studio ISP clock speed default is 125kHz, and what the advantage is to using a low speed?  I am using at ATmega328P and it seems to download code just fine at an ISP speed of 1 MHz, which is what the ICE seems to reset the clock speed to when using debugWIRE.  I don't know if I should leave things at 125kHz, or bump it up to 1MHz to make installing code faster.  I don't understand this at all.

 

thanks for any help,

mark

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

The ISP clock MUST BE 1/4 (or lower) than the system clock. As chips come out of the factory with 1MHz clock by default the maximum ISP can be 250KHz for a new chip.

125KHz is safer to accommodate clock variations.

 

Once you set the main clock faster than 1MHz then you can change the ISP frequency somewhat higher. But then you will have problems programming new chips.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

OK, thanks John.  That's what I thought, but wasn't sure.  I will have to be careful with new chips if I increase it.  Thanks for that.  smiley

 

mark

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

Hello, I am having the same problem:

Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xcc, expected 0x00 (Unknown status message)

 

I tried to lower the system clock frequency and I unchecked the CKDIV8 fuse. I lowered the ISP clock to even less than 1/4 but to read the signature I must use the lesser frequency 8kHz. Once I press F5 i get the message even if I restore the CKDIV8 fuse....

 

I am desperate.

Georgios Karanicolas

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

What kind of microcontroller are you using?  Have you chosen debugWIRE on the Tool tab?  Have you tried starting the debugger from the debug tab and clicking on "Start Debugging and Break"

 

Try rebooting your machine. 

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

When I set ISP speed to 8kHz it times out trying to download code.

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

Lowest clock is NOT always best, in fact some AVRs (or most??) will not program the flash at around 8HKz or lower.

 

Error status received: Got 0xcc, expected 0x00

 

I started to get the same message with the Atmel Ice and the Xmega 32E5 with AS7 beta, but it turns out that the chip does not get fully erased in the Xmegas and I have the lock bits set.

 

Simply manually erasing the chip fixed my problem. Maybe you can try that, interesting to see if it works.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I don't think the ICE likes it if lock bits are set

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

Then it's a bad design. smiley It seems that for the Xmegas ONLY it behaves like that because of some issue of erasing the user area.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The ICE user manual says this at the end of Section 9.2.2: 

 

Never program the lock-bits on the target device. The debugWIRE interface requires that lock-bits are cleared

in order to function correctly.

 

I don't know if it is a bad design or not, but it is what it is.

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

The debugWIRE interface requires that lock-bits are cleared

There is no debugWire in the Xmega, the chips needed to simply be reprogrammed with newer firmware and they are not in any debug mode either.

 

Anyway I never set the lock bits unless boards are going out into the field.

 

This is the discussion with Morten in relations to the Xmegas https://www.avrfreaks.net/comment...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

O, sorry.  I always forget the Xmega doesn't use debugWIRE.  This is the second time you had to tell me that.  I should just stay out of these conversations.  I thought we were talking about an Attiny.

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

 I am using ATtiny44a and I want to set 128 kHz low power internal oscillator. I went through the device programming window and set the fuse bits SUT_CKSEL to WDOSC_128KHZ_6CK_14CK_64MS. In other words, I have set the system clock to be at 128kHz, 6 cycles start up time from power-down and 14 cycles + 64 ms additional delay from reset. I have unprogrammed the CKDIV8 as well as id doesn't make any sense. I set the ISP clock frequency to 32 kHz which is 1/4 of the system frequency but it fails to enter to programming mode. I then use little lower at 25 kHz and is able to read the device signature but still is unable to be programmed returning a message that reads 0xcc instead of 0x00.

Georgios Karanicolas