Honored Contributor
Honored Contributor>> It only bothers me because I still don't understand what it is
>> I'm being warned about. The warning states that changing the >> exception address will create regions of unusable memory > >It's a somewhat prophylactic warning that you may be creating >"holes" in your memory space where _code_ is never located -- >that's all. Perhaps the wording could be better ;-) It's not just the wording (which is bad), it's the fact that the warning is generated when there is no reason to generate it, and isn't generated when you _are_ creating a hole in memory Placing the exception handler at 0x08000000 creates no holes in memory yet the warning is generated. Placing the exception address at 0x08000020 _does_ create an "unusable region of memory" from 0x08000000 to 0x0800001f, and yet there is no warning in that case. >> How will having the exception address at 0x08000000 cause any >> link-time issues that would be avoided by having it at >> 0x08000020? In neither case will the .exceptions section >> overlap the .entry section. > >The bottom 0x20 bytes is where the default linker scripts want >to put the .reset section. No, the default linker script puts the .entry section (there is no .reset section) wherever the reset address is configured in the design. In our design, the reset address is at 0x00000000, so the .entry section ends up from 0x00000000 to 0x0000001F. That overlaps neither with an exception handler at 0x08000000 nor with on at 0x08000020. >In some cases, this will cause a problem -- if you use your own >linker scripts you can do what you want. You don't have to use your own linker scripts. All you have to do is choose addresses for the exception and reset addresses such that the .entry and .exceptions sections don't overlap. >Just look at the manual for a description of the "possible >issue". It's really not that big of deal. C'mon, admit it, the warning is just plain wrong. It's a bug.
