AVR Freaks

My Xmega32E5-XPLD board arrived on Monday.

Sure enough.   Jim's UART Codevision code did not work on the 32E5.

But Brian's addition of a single NOP made it work.

The code works fine on a 32A4U chip (with or without a NOP)

I am gobsmacked.   I wrote a similar AS7.0 project using the AVR1307 App Note

It works fine with CV or GCC.    However the DATAAVAILABLE() function has a larger calling overhead cost than simple inspecting a RX_Counter variable.

So I adjusted the ISR() and the getch() function for a RX_Counter variable.

CV worked for 32A4U

CV failed for 32E5

GCC worked for 32A4U

GCC worked for 32E5

If I add the NOP,  CV works for 32E5

I diff-ed the generated ASM and  S files.

Codevision compiles into exactly the same ASM code for 32E5 as for 32A4U.    The interrupt vectors are different.  The USART registers have different addresses.

Likewise GCC compiles into exactly the same S files.

It is a complete mystery.  32A4U and 32E5 have the same internal Core.   I would expect them to behave the same.

It is pretty straightforward to use the AVR1307 driver:

Adjust buffer sizes in the H file

Adjust BAUD,  Clock speed in the Example file

I attach an AS7.0 solution.   All 4 projects share the same source code.   Set F_CPU in Project Symbols for GCC or in CV Project Configure.

David.

Have anyone look into the test I suggested in #83 ?

 I fear that :

LDS R30,0x2425		Load direct from data space

done at at a specific time of the TX will mess up some of the HW flags.

Ok I expected that 

LDS R30,0x2425

was reading a IO 

If it's just a variable we really need to see how the data got there an when. 

add:

This is not to solve it but getting closer to what the real problem is.

Remember that some IO reads actually clear/change HW flags.

So no one want to check if an other BAUD-rate change anything :(

add:

This is not to solve it but getting closer to what the real problem is.

Remember that some IO reads actually clear/change HW flags.

The cv generated code leaves the rx isr with its last instruction as a pointer type instruction (cv uses these in prologue/epilogue, where gcc uses push/pop). Your main loop has a single memory op of lds (and its target reg happens to be a pointer reg also). Maybe there is some internal 'hangup' after the isr reti that causes the lds to fail because of the pointer use (Y), and the nop happens to fix it for some reason.

It would be curious to know if other instructions besides nop fix it (like a lds r16,0x00, sei, whatever), or somehow change the lds r30 to use a non-pointer register, or get somehow get a nop inserted just before the reti, and so on. Would be odd that there would be any interaction problem such as this, but that code may also be quite unique.

If it was a problem as described above, one could create a simple test with asm and you would think it could be duplicated (on that avr anyway)-

#include <avr/io.h>

void test(); //asm code

int main(void) {

    //let tcc4 irq every 60 clocks
    TCC4.INTCTRLA = 1; //intlvl=low
    TCC4.PER = 60;     //give enough time to run through isr
    TCC4.CTRLA = 1;    //div1
    PMIC.CTRL = 1;     //lolvlen
    asm("sei");
    test();
}

;test.S

;isr increments rx_count

;main loop calls the dec_count when it sees rx_count is not 0

.set SREG, 0x3f
.set rx_count, 0x2000 ;first ram address

.global __vector_12 ;tcc4 ovf

__vector_12:
st -Y,r30 ;similar prologue style as cv
in r30,SREG
st -Y,R30

ldi r30,1
sts 0x80C,r30 ;intflags ovfif
lds r30,rx_count
subi r30,-1
sts rx_count,r30

ld r30,Y+ ;similar epilogue style as cv
out SREG,r30
ld r30,Y+ ;last memory instruction
reti

.global dec_count

dec_count:
lds r30,rx_count
subi r30,1
sts rx_count,r30
ret

.global test

test:
lds r30,rx_count
cpi r30,0
breq 1f
rcall dec_count ;breakpoint here, should get here if working correctly
1:
;nop ;fixer
rjmp test

I adjusted your code.  i.e. added a catch-all

.global test

test:
    lds r30,rx_count
    cpi r30,0
    breq 1f
    rcall dec_count ;breakpoint here, should get here if working correctly
1:
    ;nop ;fixer
    rjmp test
    nop
here:
    nop
    rjmp here

If I put a Breakpoint on the RCALL,  it stops reliably.

I always have a Breakpoint on the RJMP here NOP.

If I remove the RCALL Breakpoint,  I eventually fall through to the NOP breakpoint.

I could wiggle a GPIO or start up the RTC Timer to see how long it takes to fall through.   But fall through it does !!!

David.