unrecoverable exception, Software Framwork INTC drivers

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

Hi

I'm writing code for an UC3A0512-ES using an EVK1100 board and IAR EW 3.10A as development environment.

My code run into an "unrecoverable exception" when compiled using any other optimization levels then maximum optimization for size. If I so much as change the optimization settings for one file the application fails. I'm using the interrupt controller drivers in Atmel's Software Framwork 1.2.2.

It happens during the second call to stdlib free() function. A hypothesis has been that an interrupt occurs when executing "inside" free() and that this somehow move the application into this state. I therefore disabled global interrupts before free() and re-enabled global interrupts after but this did not help me.

Anyone who has experienced the same or similar thing? Or know what might be strange? All ideas are most welcome, this is really anoying. Thanks!

/Adde

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

What clock speed are you running at? I have a EVK1100 that isn't stable above 56 MHz. Above 56 MHz I had symptoms similar to yours.

Letting the smoke out since 1978

 

 

 

 

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

If I remember right, certain ES parts will not work over 48 MHz. Read the Errata.

-Deven

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

I have started my system using the pm-drivers in Atmel's Software Framework:
pm_switch_to_osc0(&AVR32_PM, osc0_f, osc0_startup);
I have assumed that the main clock runs with the same frequency as the external oscillator, 12 MHz?
If that is the case the frequency won't be a problem I guess?
/Adde

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

If the PLL is used, then the internal frequency can be higher than the oscillator frequency.

-Deven

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

drt80 wrote:
If the PLL is used, then the internal frequency can be higher than the oscillator frequency.

-Deven


Thanks
What do you mean by internal frequency, do you mean the "Main clock". If so that is set to the frequency of OSC0 which is 12 MHz. I have read the MCCTRL register in order to find this out.
The manual states that the PLL are by default off and I have not turned them on.

Any other ideas? Or could it still be oscillator faults occuring when I turn off max Optimization for size?

/Adde

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

post your code

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

sma wrote:
post your code

#include "env.h"
#include "types.h"
#include "evk1100.h"
#include "gpio.h"
#include "pm.h"
#include "tmrwrapper.h"
#include "uartwrapper.h"
#include "intc.h"

S16 main( void )
{
#ifdef EVK1100

    // Switch main clock to external oscillator 0 (crystal).
    pm_switch_to_osc0(&AVR32_PM, FOSC0, OSC0_STARTUP);

    // Disable all interrupts.
    Disable_global_interrupt();

    // Initialize interrupt vectors.
    INTC_init_interrupts();

    // Enable all interrupts.
    Enable_global_interrupt();

    // Start logging using AVR32 UART0
    UART_Open_HW( LOG_UART_PORT );

....
}

This is how I start up my system. FOSC0 is defined as 12000000 for the EVK1100 board.
Further down the line, after executing some 1000 lines of code I call the stdlib function free() and from "inside" free the processor jumps to address 0x80004000 (EVBA unrecoverable exception). This only happens when I not build fully optimized for size or when I define out all my debug print-outs.

/Adde

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

Well, a 1000 lines is a lot of code and it would be hard to guess what happens in that code. Maybe a bad pointer or something. I feel that the code is not very stable (just an opinion). It should work on all optimisation levels, if it were.

One thing I would suggest is that, if you use interrupts, then you should have all the variables used in the interrupt routine as "volatile".

Also, you code try to debug the value of the address in you pointer OR if it is a string, dump it to the serial port OR if you have a LCD or LED display, show the string on it.

-Deven

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

drt80 wrote:
Well, a 1000 lines is a lot of code and it would be hard to guess what happens in that code. Maybe a bad pointer or something. I feel that the code is not very stable (just an opinion). It should work on all optimisation levels, if it were.

One thing I would suggest is that, if you use interrupts, then you should have all the variables used in the interrupt routine as "volatile".

Also, you code try to debug the value of the address in you pointer OR if it is a string, dump it to the serial port OR if you have a LCD or LED display, show the string on it.

-Deven


Thank you

I'm already using volatile. I have also turned off all interrupts to see if this is causing any problem but no, the same problem occurs. It seems like my compiler is producing code that the processor cannot execute, that a hypothesis at least.

The code runs smoothly on other platforms. Somehowe my tool setup, project settings and my UC3A-ES device in combination with my code are incompatible?

Can it be that the Software Framework is bad for my device? It is quite old, think it's produced in the timeframe 2003-2004.

/Adde

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

Why do not you try the new framework? Is there any specific reason to stick to the old one?

-Deven

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

drt80 wrote:
Why do not you try the new framework? Is there any specific reason to stick to the old one?

-Deven


From what I know the new 1.4 framework is incompatible with the ES part of the processor. So I'm stuck with 1.2.2. Any other suggestions?

/Adde

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

The 1.2.2ES software framework is updated on the 12/08.

http://atmel.com/dyn/products/to...

-Deven