Data Address Read Exception

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

Hi,

My code is throwing a Data Address Read exception. What might cause that, or what should I look for in the code?

Thanks!

-Colin

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

PS: The offending instruction according to disassembly of the C code is:

ld.w r9,r8[0x04]

r8 = 0x0001
r9 = 0x12b8

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

By the way in case anyone searchs this and finds the same problem:

It was caused by unaligned memory accesses. The code was originally for an 8-bit AVR, and would have structures like:

/** \brief This is the NLME-NETWORK-DISCOVERY.request structure. */
typedef struct nlme_network_discovery_req_tag
{
    /** The total length of this message. */
    uint8_t     size        ;
    /** This identifies the message as \ref NLME_NETWORK_DISCOVERY_REQUEST  */
    uint8_t     cmdcode     ;
    /** Bitmask of channels to scan for networks. */
    uint32_t    ScanChannels ;
    /** Duration to scan for networks. */
    uint8_t     ScanDuration ;
} nlme_network_discovery_req_t;

[/code]

Which were later typecast to (uint8_t *) and accessed with offsets. This meant that it assumed an 8-bit device was used, as on the 32-bit device it would align the 8 bit variables to 32-bit address boundaries. This allowed faster access on the 32-bit machine.

Solved the problem by forcing hte compiler to pack everything together by adding __attribute__ ((packed)) after each variable declaration.

-Colin

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

PS: So the original problem was unaligned addresses, as page 23 of the datasheet says:

Quote:
AVR32UC does not support unaligned accesses, except for doubleword accesses. AVR32UC is
able to perform word-aligned st.d and ld.d. Any other unaligned memory access will cause an
address exception.

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

What do you mean with "after each variable declaration"? One of each part for the struct?

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

Hi, I know this post is old but I am facing the same problem.

My MCU is ATMEGA 0512 UC3A,  _Handle_data_access_read exception is raised whene executing a instruction for serial port initialization . 

 

      opt->stopbits > 2 + 255 ||

8005E994  ld.sh R9, R7[6]  

8005E996  mov R8, 257  

8005E99A  cp.h R9, R8  

8005E99E  brhi 0x8005e9be

 

ld.sh R9, R7[6]  <--------- instruction that raises the error

 

The strange thing is that that code has never been modified and not the structure opt neither.

Furthermore the problem happens on the second call of the function, here are the values of R7 and R9:

 

1st call, works

R7 0x0000FFB8

R9 0x00000004

 

2nd call, EXCEPTION RAISED

R7 0x000000F7

R9 0x00000004

 

Adding packed attribute to the structure opt doesn't work, The problem happens randomly when I do other modification to other part of the code that shouldn't be related to this struct. I tried to revert back to see the disassembly of the same C code and the problem doesn't happen because ld.sh R9, R7[6]  is not generated.

I am using Atmel Studio 6.2.1563 and Atmel avr32 Gnu toolchain 3.4.2.1067.

 

Thank you in advance for anyone could help me !

 

 

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

c_oflynn wrote:
It was caused by unaligned memory accesses.
Certainly in ARM this is almost always the reason for a data exception. I assume that is the same here for UC3 ? So is it an alignment thing? I guess the implication then is that R7 holds an odd number.

 

EDIT: should have read more closely - so, yes F7 *is* an odd number - so this is expected. I guess the real fault is "what is R7 doing holding an odd number at this point?"

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

If r7 is opt, then it looks like opt gets trashed somehow.