AVR Freaks

Somehow missed the fact that this was an Xmega project and we have a basic prioritised interrupt controller to deal with.

Also struggling to debug this because the ELF contains no debug information:

C:\Users\Nigel\Documents\Atmel Studio\7.0\jgmdesign>avr-readelf -a Debug\Exe\xmega_just_usart.elf

ELF Header:

  Magic:   7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00

  Class:                             ELF32

  Data:                              2's complement, little endian

  Version:                           1 (current)

  OS/ABI:                            UNIX - GNU

  ABI Version:                       0

  Type:                              EXEC (Executable file)

  Machine:                           Atmel AVR 8-bit microcontroller

  Version:                           0x1

  Entry point address:               0x0

  Start of program headers:          52 (bytes into file)

  Start of section headers:          116 (bytes into file)

  Flags:                             0x0

  Size of this header:               52 (bytes)

  Size of program headers:           32 (bytes)

  Number of program headers:         2

  Size of section headers:           40 (bytes)

  Number of section headers:         4

  Section header string table index: 1

Section Headers:

  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

  [ 0]                   NULL            00000000 000000 000000 00      0   0  0

  [ 1] .shstrtab         STRTAB          00000000 000114 00001c 00      0   0  0

  [ 2] .text             PROGBITS        00000000 000130 00049c 00  AX  0   0  2

  [ 3] .signature        PROGBITS        00840000 0005cc 000003 00  WA  0   0  1

Key to Flags:

  W (write), A (alloc), X (execute), M (merge), S (strings)

  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)

  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:

  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align

  LOAD           0x000130 0x00000000 0x00000000 0x0049c 0x0049c R E 0x2

  LOAD           0x0005cc 0x00840000 0x00840000 0x00003 0x00003 RW  0x1

 Section to Segment mapping:

  Segment Sections...

   00     .text

   01     .signature

There is no dynamic section in this file.

There are no relocations in this file.

The decoding of unwind sections for machine type Atmel AVR 8-bit microcontroller is not currently supported.

No version information found in this file.

C:\Users\Nigel\Documents\Atmel Studio\7.0\jgmdesign>

Anyway using the simulator I get this:

The PC is stopped at the loop of interest but the USARTC0 appears to have interrupts disabled despite the comments in the (generated ?) code indicating that low-level was the intention.

{EDIT}

Oh that's just typical: A Refresh bug in  Atmel Studio 7 (Version: 7.0.2397 - )

The I/O registers don't get redrawn after {break} unless you close the fly-out then reopen the fly-out.

That's better.

I cannot be the only one who has been caught with this one.

That all looks pretty reliable.   I don't see where anything can go wrong.    After all,   people have been handling USARTs with interrupts since day one.    And using a similar method to check whether "data is available" in the receive buffer.

In fact CV has provided interrupt-driven Serial comms since CV was first released.    Even for a Tiny2313.

I often change "Mega" device in an AS7.0 project.    It is not so simple with E5, A1, A4, ... which have some subtle differences.

All the same,   you can set up the basics in a CodeWizard file.    And generate for E5, A1, A4, ...

I don't have any hardware E5.   But the E5 appears to be a cut-down Xmega.    32E5 is the biggest in the family.

If there was a 128E5 it would be worth playing with.

David.

Is there some atomic protection that might be starved by the interrupts? The inclusion of a nop() would support that methinks.

Look at the serial code - how is it doing the atomic protection?

>This is a vanilla file

Probably doesn't do much good without the lst file, as some do not have cv to compile with.

Put the nop as the first thing in the while loop, so every read via lds r30 is preceded by the nop. Doesn't seem like the lds r30 likes the back to back reads when no other memory access takes place between reads (lds r30, cpi r30, rjmp, rjmp). The nop does something, and you would think an interrupt that will take place would also 'correct' the problem (but maybe see below).

You could also try to get the buffer count read to use a pointer so the resulting code is not using lds r30, just to see what a different type of access acts like.

This is the end of the isr (from the jgm listing in the zip file, anyway)-

000200 91e9          LD   R30,Y+
000201 bfef          OUT  SREG,R30
000202 91f9          LD   R31,Y+
000203 91e9          LD   R30,Y+
000204 91a9          LD   R26,Y+
000205 9518          RETI

Maybe the the pointer register usage has something to do with it, as the isr leaves with its last memory access as a pointer type access. In the avr0/1, I saw a strange problem where writing to the sleep control register would not work when using a pointer register to access (compiler generated code used pointers for some reason, then the problem showed up), but either adding a nop or getting the compiler to produce lds/sts (normal), or splitting up the write into two ops 'fixed' the problem. Maybe there are combinations of x/y/z pointer use that create a problem, although if so it must be a rare combo or you would think it would be causing problems all over the place.

I'm not sure what can be done in cv, but if a nop could be inserted before the reti, that could also maybe reveal something useful. Maybe.

The Xmega32E5 target is a barrier to many (including me).

I had a thought about using the simulator though. Has anyone been successful using the Atmel stimulus file (.stim) to inject characters into the simulator's USART ? (Documentation on .stim files is sparse)

What I meant by that is, because not many freaks can immediately lay their hands on some real silicon; that it's a barrier to solving the weird problem.

Hence my sub-question about injecting characters into the Atmel Simulator.