1

I am trying to compile an embedded C code, but small data area overflow occurs. I know what does it mean, but I don't know how to solve it. Can anyone make a suggestion?

So, the problem is there is r13 register that is the base pointer of the sda, and it is 16 bits long. It is signed so it points to the middle of the sda, and it can be used as an offset to get the given variable value.

If a variable is told to be put to the sda by #pragma ghs startsda then it will be addressed by sda_base+r13, if the variable is at an address that cannot be addressed by this base+register offset, then sda overflow is reported.

How can I find what caused the overflow? If I don't have the map file yet I don't know the variable addresses.

Fekete Ferenc
  • 119
  • 2
  • 11

2 Answers2

0

You need to check to see your compiler configuration. The compiler can automatically put data into the .sda area. I forget the exact flag but you can exclude data greater than a specific size from .sda. For example you can say things greater than 64-bits do not go into sda. This way a big buffer that you define do not waste all of your sda space.

Jong Chen
  • 91
  • 2
0

See my answer to the earlier question here: https://stackoverflow.com/a/12305862/1424877

Basically, you should be using link-time -auto_sda and not compile-time #pragma ghs startsda; the latter isn't very useful if the linker (elxr) can do SDAization for you, and it can lead to linker errors if all your .o files summed together put more than 64K in the SDA section.

Green Hills' linker can automatically "SDAize" data that the compiler had assigned to .data; but it can't automatically "de-SDAize" data that the compiler has already assigned to .sdata. (At least, it couldn't in 2011, and I doubt that's changed as of 2014.)

Community
  • 1
  • 1
Quuxplusone
  • 23,928
  • 8
  • 94
  • 159