LUFA hangs AT90USB1287?

Go To Last Post
84 posts / 0 new

Pages

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

Quote:

Any suggestions what to look at?

Well the _RESET signal for one. Make sure that when ISP starts it is successfully being pulled low. At the same time look at SCK, MOSI, MISO used for ISP. Do you see commands clocked out on MOSI and response back on MISO at the SCK edges?

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

When it was hanging it had 2.71 volts on reset PIN. We're gonna look at it with an oscilloscope.

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

clawson wrote:
Quote:

Any suggestions what to look at?

Well the _RESET signal for one. Make sure that when ISP starts it is successfully being pulled low. At the same time look at SCK, MOSI, MISO used for ISP. Do you see commands clocked out on MOSI and response back on MISO at the SCK edges?

We'd want to see why it hangs in the first place. The programmer is another story, we'll lay it off for the moment.

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

ixremedy wrote:
cli(), sei() - kind of a mutex. prove it wrong

That can certainly work, but you need to be careful not to nest such locks.

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

rryles wrote:
ixremedy wrote:
cli(), sei() - kind of a mutex. prove it wrong

That can certainly work, but you need to be careful not to nest such locks.


volatile is a programming cheat of the C language, badly documented in the standard. You cannot base your work on cheating. Likewise mutexes are the only normal way of synchonising threads, whatever other way your compiler may provide you with.

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

Quote:

Likewise mutexes are the only normal way of synchonising threads,

What about sem4's ?

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

clawson wrote:
Quote:

Likewise mutexes are the only normal way of synchonising threads,

What about sem4's ?

Used for IPC, not multithreading.

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

ixremedy wrote:

volatile is a programming cheat of the C language, badly documented in the standard. You cannot base your work on cheating.

You cannot program an AVR in C without using volatile somewhere. Without it the optimizer would be correct to remove all of your code.

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

That would mean that compiler is crap, not to say worse.

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

So long as the compiled program has the same side effects as the abstract machine defined by the C standard it is correct.

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

rryles wrote:
ixremedy wrote:

volatile is a programming cheat of the C language, badly documented in the standard. You cannot base your work on cheating.

You cannot program an AVR in C without using volatile somewhere. Without it the optimizer would be correct to remove all of your code.


And I must say that our project doesn't use volatiles and currently we suffer from just one problem that we still havent tracked down. Otherwise, it works perfectly well.

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

ixremedy wrote:
And I must say that our project doesn't use volatiles

I bet it does. Do you use any standard header files?

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

Quote:

I must say that our project doesn't use volatiles

You mean it does not use *ANY* of the AVR SFRs like PORTB, TCNT1, UCSRA, etc, etc? They are all volatile sources or destinations. They have to be or the optimizer might simply discard any access to them:

int main(void) {
  int n, m;
  n = 37;
  m = n * 53;
}

generates:

  92:	80 e0       	ldi	r24, 0x00	; 0
  94:	90 e0       	ldi	r25, 0x00	; 0
  96:	08 95       	ret

(which is just the return 0 of an empty main()). While:

int main(void) {
  int n, m;
  n = 37;
  m = n * 53;
  DDRB = m;
}

generates:

  92:	89 ea       	ldi	r24, 0xA9	; 169
  94:	87 bb       	out	0x17, r24	; 23
}
  96:	80 e0       	ldi	r24, 0x00	; 0
  98:	90 e0       	ldi	r25, 0x00	; 0
  9a:	08 95       	ret

True m and n still don't exist because they are pointless and not needed but something other than the "return 0" code is present because of the volatile DDRB. (0xA9 is (37 * 51) & 0xFF)

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

The whole thing is meaningless.
And in the whole thread there is nothing which could point us at why the whole thing may hang so firm so that even hardware reset can't help it.

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

Quote:
And in the whole thread there is nothing which could point us at why the whole thing may hang so firm so that even hardware reset can't help it.

* Bad choices : if one knows that gcc is bad, bad, BAD, why chose it? why rely on it and write thousands of lines on it? This is the worse strategy one could figure out in the most unpleasant nitemares....

* Bad methods : hobby users have oscilloscopes... a bunch of programmers do not have (or need days to get a hand on it)...

* Very bad monologue (was it
*** to get help
*** or to prove gcc_is_bad_bad_bad_crap)

Quote:
cool monologue bro...
how about some schematic and codes so other people could join in?

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

We didn't know it was so bad, we'll buy a paid compiler.

We've got an analogue oscilloscope and it is good for many things as well as it was enough so far. We'll buy a digital oscilloscope, that's for sure, but that doesn't happen in one day.

Everything was going smoothly well, we didn't need any external help so far till we bumped into this problem.

We've asked for help, so far I've seen ppl not even aware that such problems exist.

So we'll continue to boil within our group and I am sure we'll find a solution. I was guessing someone may find this discussion useful if we could come to a solution. But sure you won't get to know about it in a manner like that.

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

ixremedy wrote:
We didn't know it was so bad
It isn't. It was you that said it was bad. But it will not help to buy a compiler if you don't bother to (or don't want to) learn the language.

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

How does that have to do with learning the language? Or perhaps you think that people have made this hardware, produced it, programmed it, came across a problem and they understand what they do worse than you?:) Well, that's a very positive way of thinking.
If some practises are bad, they are bad, regardless of whether you do or you don't like it.
Now coming back to the point we haven't even neared the place where we may have the problem, discussed everything else, but not what is the case.

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

We've finally found the source of the problem of why the AVR hung so much so that even HW Reset didn't help.

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

Well done! So, was it a compiler bug?

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

No, it was an Atmel hardware bug. Switching off the watchdog in software made it possible to reset. Also we've changed the capacitor to 1500 from 1000. And now we are monitoring the 3.3V line with a digital oscilloscope.

Last Edited: Fri. Nov 23, 2012 - 09:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, is this what you experienced?

Quote:
"Note that for newer devices (ATmega88 and newer, effectively any AVR that has the option to also generate interrupts), the watchdog timer remains active even after a system reset (except a power-on condition), using the fastest prescaler value (approximately 15 ms). It is therefore required to turn off the watchdog early during program startup"

http://www.nongnu.org/avr-libc/u...

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

I will try and tell you. Funnily how I didn't pay attention to it when I read that doc for the first time.

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

Yes. That has helped, thank you a lot!

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

But surely it was a compiler bug? I've heard the compiler is full of bugs.

Failing that was it not a an Atmel hardware bug?

No?

Quelle surprise.

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

What do you mean - not an Atmel HW bug?

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

And what do you mean by "I heard the compiler's full of bugs"? There are still dozens of problems that we mitigate by dancing with optimization levels. And those are not fully covered.

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

So the program hangs on USB_USBTask() and afterwards gets reset by the internal watchdog

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

BTW: I've trapped a linker bug: there was a variable defined in three source files as extern and wasn't actually declared anywhere and still that would compile into an .elf file.

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

Quote:

BTW: I've trapped a linker bug: there was a variable defined in three source files as extern and wasn't actually declared anywhere and still that would compile into an .elf file.

Test case?

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

I am not able to reproduce that case on three dummy files with one extern in each.

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

How I got to know about this is that I was looking at objdump printout and spotted a variable that wasn't used in a long time in the .data section. I found it in three .c project files and everywhere it was extern uint8_t with this varible being assigned a value in a function in the .c file

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

I've downloaded a fourth toolchain, this one from the Atmels website. I've tried WINAVR 2010, the one coming with AVR Studio 5.0, the one based on GCC 4.7.2.

And this one is based on the GCC-4.6.2. I must say it is much better than any of the three mentioned above. I am happy.

Pages