ATMega324PB Xplained Pro "permanent" programming

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

Hi again everybody!

 

I have a new issue with my 324PB Xpro. I have code that I wrote to monitor the ADCs continuously and write the output to the UART on the USB. I have no problem using this on my own machine, but I want to give it to another person and have them read the data on their computer (where we have a data visualizer he is working on). However, every time the Xplained Pro is disconnected from the computer it seems to lose its programming, and only hooking it back up to Atmel Studio and re-programming it.

 

I know there must be some little thing I have overlooked, but does anyone know how to get the programming of the xpro to stick?

 

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

dtreth@gmail.com wrote:
 it seems to lose its programming

What makes you say that?

 

Please describe the symptoms more fully:

 

  • What, exactly, are you expecting to happen?
  • What, exactly, does actually happen?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I used the microUSB interface (which uses the EDBG chip on-board) to program the board using the Programming dialog in Atmel Studio. When I open a terminal to the board's COM port I see my data streaming out. When I hit the reset button it stops, but then resumes spitting out data. If I unplug and then re-plug it in I can no longer get that data, it's just a constant y with the circle over it like in Angstrom, or a section character. If I re-program it using the Programming dialog it works again.

I want to be able to unplug the board from the Atmel Studio computer and plug it into another computer, and get the streaming data I am getting on the computer I used to program it.

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

What happens if you press the Reset button when it's in the "constant y with the circle over it" mode ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

same thing, it stops for a bit then starts with the unintelligible characters.

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

Is the terminal emulator still open when you unplug the cable?  If so, try closing the terminal emulator, unplugging, re-plugging, and launching the terminal emulator.  If I don't do this using PuTTY it locks up the virtual COM port, although PuTTY is kind enough to indicate a communication error has occurred.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

When you say "it" locks up the COM port, you mean the COM port of the computer? If so, wouldn't plugging it into another computer alleviate the problem?

And yes, I have tried it with the terminal disconnected and with it connected, same result both times.

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

only hooking it back up to Atmel Studio and re-programming it.

What happens if you it plugged in, but perform an external reset?  Does it still work?  Or do you need to reprogram it...?

"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

"external reset" you mean like press the reset button? It resets the code I loaded in and starts over.

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

Nevertheless, I would first suspect an uninitialised automatic. Programming involves issuing a chip erase command over the programming interface. This will erase all memories, including SRAM and the GP register file. Such is not the case for a normal startup, where the contents of SRAM is effectively random. If you have an automatic variable or buffer which your code expects to have a value of zero, it would 'work' after programming (and possibly, depending on the precise code, after an external reset), but generally not after a normal power-up.
Try burning a simple LED blinky test program (one with no variables of any kind), then try out unplugging then replugging the unit. Does your mysterious evaporating program problem persist?

"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]

 

Last Edited: Sat. Jul 30, 2016 - 10:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you tell me what exactly you mean by "normal power-up"? The examples for the 324PB, disconcertingly, don't really work properly as it is, so it's not something I can test easily, so can you tell me what makes an "automatic variable" not have a correct initialised value? The only variables I have with no initialisation are the global variables, which the Atmel documentation assures me will always be set to 0.

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

An automatic variable is one that is local to a function. They are not automatically initialised, unless declared static.
What 324PB examples 'don't really work properly?

"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]

 

Last Edited: Sat. Jul 30, 2016 - 11:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are not losing the program in the micro; this evidenced by the (incorrect) serial stream that you see after power cycling the board.  When you program the device part of process includes zeroing all of the ram; when you power up this does not happen.  Look at your code that initializes the UART.  You have an uninitialized variable that should be zero for correct UART operation.  It works correctly after programming because all ram has been cleared.  It works incorrectly after power up because ram has not been cleared.  Find the variable(s) in the UART init that needs to be zero and initialize it/them to zero.

Letting the smoke out since 1978

 

 

 

 

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

digitalDan, I looked through all the code and I managed to find a single uninitialised variable declaration. It was just before a for loop which set the variable to zero as the opening statement. I set it to 0 anyway. It also wasn't near the UART code. 

The actual UART initialisation code I cribbed from here: https://github.com/tuupola/avr_d... and changed the variables to match the 324PB. I use it like

printf_P(PSTR("%u\t%u\t%u\r"), d1, d2, d3);

to output data to the serial stream.

 

joeymorin, there is a morse code program that demos serial functionality of the chip, but it doesn't compile because Atmel can't make up their minds on register naming conventions. I just tried to re-download the projects to try again when I got the lovely error "The type initializer for 'Atmel.AsIde.AvrStudio.Utils.MemoryPressureReliever' threw an exception...". So I am getting quite frustrated, but will continue along nevertheless.

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

OK, i uploaded my project so you can see if I made some sort of stupid mistake (which I must have, but still).

 

I was finally able to get the LED blinking example to work, and can confirm that it keeps blinking after being disconnected and reconnected.
I also got the REMORSE example code "running", but it only raises further questions: it has a bunch of warnings about undefineds, and I have no clue what the actual CPU frequency is, but the LED flashes WAY too fast when transmitting and way too slow when trying to input morse, telling me some timing variable is off. Even more confusingly, it only works AFTER I unplug it and replug it back in; also known as exactly the opposite behavior as my program....

Attachment(s): 

Last Edited: Sun. Jul 31, 2016 - 02:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK SO! I have it almost solved now. It seems like it is running at 1MHz when I program the chip, but when I power cycle it, it runs at 16MHz. Peculiar....

What happened was I had a terminal running at 9600 baud, and it worked as I described above. I decided, after unplugging and replugging the board, to try to up the baud by 8. Just more garbage. Then I tried 153 600 baud, and lo and behold! it works!

So now i want to know: I thought the fuse bits controlled the clock. I also thought that I cannot manipulate those bits in my C program. Am I incorrect? Is there something with the programming that I am doing wrong? It also seemed to affect the Morse program I mentioned, for what it's worth.

 

EDIT: power cycle, not reset.

Last Edited: Wed. Aug 10, 2016 - 04:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I am still trying to figure this issue out; it always runs 16 times slower when first programmed, then seems to respect fuse settings after a hard power cycle (but not bringing the reset line high). Does anyone have an idea as to why it would do this? And should I mark this one closed and start another topic?

Again, thanks everyone for the help already.

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

Keep this thread going...don't open a new thread.

Jim-moderator

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

stdin and stdout are pointers to a FILE, not pointers to a get() and put() function, respectively.  The way you are using with them could be causing some unintended consequences.  Check the AVR-Libc documentation for FDEV_SETUP_STREAM.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

The usage is correct:

 

uart.h

FILE uart_output = FDEV_SETUP_STREAM(uart_putchar, NULL, _FDEV_SETUP_WRITE);
FILE uart_input = FDEV_SETUP_STREAM(NULL, uart_getchar, _FDEV_SETUP_READ);

uart.c

void uart_putchar(char c, FILE *stream) {
    if (c == '\n') {
        uart_putchar('\r', stream);
    }
    loop_until_bit_is_set(UCSR1A, UDRE);
    UDR1 = c;
}

char uart_getchar(FILE *stream) {
    loop_until_bit_is_set(UCSR1A, RXC);
    return UDR1;
}

main.c

    stdout = &uart_output;
    stdin = &uart_input;

 

"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

Yep, thanks for confirming that for me. I figured that must be right because, like I said, it works if I get the correct baud rate. It just changes by 16x when I power cycle the board.

At this point my working theory is that when it gets programmed it switches to an internal clock for some reason, and doesn't switch back.

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

At this point my working theory is that when it gets programmed it switches to an internal clock for some reason, and doesn't switch back.

I would like to see proof of that.  Clock source is determined by fuses settings.  Fuse settings can only be changed by ISP, JTAG, or HVPP.  They cannot be changed by software running the AVR.

"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

So what is "proof"? I'd be willing to run whatever test on it.

 

When I click the play button or use the device programmer to load my program, it runs and I can connect to it with a terminal at 9600 baud. When I power cycle it, I can still make it work just fine by changing the baud rate to 153600 baud. If I make F_CPU equal to 1000000 and BAUD to 9600 before I call setbaud.h, it will communicate with a 9600 baud terminal correctly upon programming, but not after the power cycle (you need to use 153600 baud terminal settings). If I change F_CPU to 16000000 it doesn't communicate upon programming but communicates at 9600 baud upon power cycle (I assume 600 baud is too slow for UART?).

 

Do you have an alternative explanation as to why this would happen? By the way, it's not limited to my project; after cleaning up the macros in the REMORSE example project it also displays this exact same behavior.

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

The usage is correct

 

Whoops blush

 

Not the way I would have done it: using two FILEs when one would suffice, but I should have looked more closely.  I prefer something like this:

 

FILE uart = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);

...
...
...
    stdin = stdout = stderr = &uart;

 

But, if it works, it works.

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

It's not necessary to change clock >>sources<< in order to change clock >>speed<<. The CLKPR register sets a prescaler for the system clock of between /1 and /256. Perhaps something peculiar about the Xplained Pro board sets the target's prescaler after programming or when debugging. I would create a test program which reports the value of CLKPR. Since you already know how to connect at the various mysterious baud rates, this may help you diagnose the problem.

"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

Ok, I'll try that. I have used the CLKPR to run the chip at 8mhz,and when it's programmed it runs at 500k,so I just assumed it wasn't clobbering the CLKPR, but I'll try your advice.

In response to the FILE thing: THANK YOU! I wanted to do it this way, too, but as you can see I Cribbed the code from someone else, and the examples I found were all like that for some reason. But, as you said, it worked, so I didn't want to fool with it. I have recently moved the assignment of stdin and stdout to the init functuon, which took some doing (I really don't like C, or the preprocessor, very much--mostly because I'm bad at it), so might as well try your suggestion.

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

OK so this seems interesting. I ran the code without the CLKPR setting code, and I got CLKPR = 3 (b0011) when it worked at 9600 baud, and CLKPR = 0 when it worked at 153600 baud.

CLKPR = 3 means CLKPS[3:0] = 0011, which means the prescaler should be 8x. However, the difference between the baud rates is 16x.

Then I tried re-enabling the code for the CLKPR,

	CLKPR = (1<<CLKPCE);
	CLKPR = 0;

I could not, no matter what I tried to set the baud rate to, get this to connect to the board, so I cannot tell what the CLKPR is set to (or really what the clock rate is here). However, I can power cycle it and see that CLKPR = 0, and it connects at 153600 baud.

Hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.

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

Output an endless stream of 'U' characters.  That's 0b01010101.  On a scope it will show a square wave with frequency = BAUD/2.  From this, and your choice of UBRR, you can deduce F_CPU.

 

The x16 instead of x8 is puzzling.

 

Could the extra x2 be due to the use of U2X?  Although that wouldn't explain why it happens only when power cycling after programming, nor why CLKPR appears to be changing on its own.

"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]

 

Last Edited: Tue. Aug 9, 2016 - 10:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmmm...  The MEGA324PB Xplained Mini has a 16MHz XTAL on it.  The Clock Failure Detection switches the clock to 1MHz via the internal RC oscillator and prescaler.   I wonder..?

Greg Muth

Portland, OR, US

Xplained/Pro/Mini Boards mostly

 

Make Xmega Great Again!

 

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

Hmmm...  The MEGA324PB Xplained Mini has a 16MHz XTAL on it.  The Clock Failure Detection switches the clock to 1MHz via the internal RC oscillator and prescaler.   I wonder..?

Good catch.  Well that'll teach me to make assumptions.  I wasn't aware (or failed to recall) that the 324PB had a CFD.

 

You can confirm this by checking the XFDIF bit in XOSC.  Perhaps report it in the same manner you were doing for CLKPR.

 

Now if that turns out to be the case, the question to ask is why the heck is the XTAL failing when plugged in for programming.

"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

Well, well, well... wouldn't you know....

printf_P(PSTR("Clock Pointer: %X. CFD Status: %X.\r\n"), CLKPR, XFDCSR);

Yields this "Clock Pointer: 3. CFD Status: 2."

Then a power cycle gives me "Clock Pointer: 0. CFD Status: 0."

 

So there it is. Why it's happening, I wish I knew, but I have 6 of these boards and they all act the same.

 

But let's make it even more interesting, shall we? Using all this I tried to figure out which baud rates must be coming out (as mentioned earlier I don't have a scope. I may just pick one up on eBay at this point) when I manipulated the CLKPR. At first I thought it was weird that the CLKPR was being set to 8x because I thought I had read that it uses CKDIV8 when reverting to internal clock, but then I remembered that's a fuse setting you can't change at runtime, so maybe it doesn't apply when the internal oscillator gets activated by the failover. Therefore the failover process must be putting the value in the CLKPR. If I set it to 0 I can see it at 76800 baud, which would imply a clock speed of 8MHz.

 

While I am still perplexed as to why this thing is behaving this way, I can debug a lot of stuff more properly now, since it's at the clock speed I was looking for. Thanks for your help so far, I learned a lot about what to expect with these chips.

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

Many apps set CLKPR at the start of main() before interrupts are enabled. Hence there is no worry about the timing.
.
If you are especially unlucky, your CLKPR assignment could fail if init code has enabled interrupts and one occurs exactly in between your two CLKPR statements.
.
Newer chips seem to protect clock setting better. But you can simply read CLKPR back. This will tell you if it succeeded or not.
.
David.

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

David, the issue here seems to be that the 324PB has the capacity to validate the proper functioning of the external oscillator.  If that oscillator is deemed to have failed to start up correctly, or to later falter, the clock source is automatically changed to the internal 8 MHz RC oscillator and CLKPR is loaded with a value of 3 for a prescaler of /8.  It is one of a handful of AVR which are capable of changing the clock >>source<< at runtime.  This fits the OP's symptoms exactly.

 

The challenge now will be to find out why the Xplained Pro fails over in this manner immediately after programming, but then works normally after a reset.  According to the OP, this is consistent behaviour, so I wouldn't immediately suspect a dodgy crystal.  Especially since 6 boards exhibit the problem.

"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

Oops. I did not spot the PB.
So it looks as if you should poll for success when you alter clocks. Just like you do with an Xmega or a Tiny1634.
Now that my XMINI-168PB is operational again, I will see how it works.
I am not at a PC. I am just guessing that the 168PB has the same feature as a 324PB

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

The 324PB seem only able to change clock sources through the hardware CFD facility, the Clock Failure Detection mechanism.  It cannot be done at will by software.  It is a failover mechanism only.  The only way to restore the fused clock source is to apply a reset to the device.

 

I don't know about the 168PB... let me check... looks like it lacks CFD.  Nor does it have the ability to change clock sources at will like some (few) other AVR.

"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

Actually (because the universe hates either you or me, or both) a reset doesn't actually fix the problem. Only with a power cycle will it "behave". I have a USB hub with separate power buttons per port, and I hit that switch up and down to cycle it. Hitting the reset button on the XPRO doesn't resolve the issue, but it does restart the program (I know it resets the program because these don't behave like the arduino boards which seem to reset when a console attaches, so I press that button to see my start up code).

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

 dtreth wrote: 

Actually (because the universe hates either you or me, or both) a reset doesn't actually fix the problem. Only with a power cycle will it "behave".

 dtreth wrote: (emphasis mine)

OK SO! I have it almost solved now. It seems like it is running at 1MHz when I program the chip, but when I reset it, it runs at 16MHz. Peculiar....

So which is it?

 

 

 dtreth wrote:

I have a USB hub

It's a long shot, but what happens if you bypass the hub?

"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]

 

Last Edited: Wed. Aug 10, 2016 - 01:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Damn, I was being so careful. In every other post I talked about how the reset button doesn't solve the problem, that i need to disconnect and reconnect it for the clock to change. You found the one place I screwed up.

And I also have been using these with my laptop, sans hub. Same issue.

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

So I have been working with these chips at 8MHz for a few weeks now; it's not too bad (after calibrating the internal oscillator) but it's still something I am apprehensive about. Does anyone have any ideas about why the crystal is failing when programmed?

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

Most likely you are using the internal oscillator? As mentioned earlier it's possible that the AVR has switched to the internal. Can you verify with a scope that the crystal is oscillating?

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, we have discovered that upon programming the oscillator failure bit is set and it definitely appears to be running off the internal oscillator. Upon power cyclinng it appears to be running on the external oscillator.
 

As I stated earlier I don't have a scope, however given the information we have it's pretty clear that it is running on the internal oscillator after being programmed. The question is why?

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

What are your fuse settings?

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

Which fuses do you want to know? It's set to use the external oscillator according to the Atmel Studio tool. I'm not sure the easiest way to post the fuse settings here.

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

Screenshot?

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

Personally,  I would be happy with the hex values read by your programmer. e.g.

lfuse:0x42 hfuse:0x99 efuse:0xff

or L:0x42 H:0x99 E:0xff

 

This is simple to type.   Less confusing than a screenshot of a GUI.

 

David.

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

Does it really matter why this happens after programming?  That is not a typical use case.  Only a typical development case.  After all, this device has a fall-back clock mechanism for a reason.  Haven't you already determined that it is being engaged?  Simply detect it in software via XFDIF and trigger a WDT reset. 

 

Why does it happen in the first place?  Who knows.  Chip errata?  Design flaw in the  Xplained board?  Noisy or low-voltage USB?  Again, I'd say it doesn't matter, since it only ever happens after a programming cycle.

"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

The external crystal on the XPRO kit is 16MHz. If running at the default voltage at 3.3V, you can't run the device at more than probably 12-13MHz according to spec. You need to set the CLKDIV8 fuse to start the device at 2MHz, and then change the CLKPR to divide by (minimum) 2 to run from the crystal in your code.