RAM Guard

The idea is to create a dummy “guard” section and locate it at the first location after the physical RAM on the device. For example, in the case of this project, for an R8C/35A with 2.5 K RAM starting at 0x400, this would be located at 0x400+0xA00 = 0xE00. In order to provide a bit of a heads-up when the data space is coming close to filling available RAM, I have located this guard section a bit lower (using 0xDC0 warns when there is less than 64 bytes available).

If there are additional non-contiguous blocks of physical RAM, this can be done with multiple such guard sections.

Details:
The assembly language file (RamGuard.a30) does the trick for the scenario described above.

;
; Calculate boundaries
;
RAM_START .equ 0400h
RAM_SIZE .equ 2048 + 512 ; 2.5 K
RAM_END .equ RAM_START + RAM_SIZE ; first non-RAM location
HEAD_ROOM .equ 64

; Use section type of "ROMDATA" instead of "DATA",
; if you want to get an ERROR instead of a WARNING.
; (but then you'll get "invalid memory location" download errors
; even if memory sections do not overlap)
.section guard_section,DATA

.glb _guard ; so that it will show up in HEW's "Map Symbol Information" window,
; and we can see it from C.
.org RAM_END - HEAD_ROOM
_guard:
.blkw 1

.end

Including the above assembly language file in a HEW project (as in teh attached demo project for an R8C35A with 2.5K of RAM (R5F21356)) causes a warning to be generated at link time when less than 64 bytes of RAM is available for expansion. Set HEAD_ROOM to 0 if you only want a warning when RAM is completely exhausted.

To see this in action, download the attached project, open it in HEW and build it. There should be no errors or warnings. Then in Guard.c (the main module), uncomment the "MoreRAM[8]" array definition and build it again. There will still be no errors but you'll get a warning that sections have overlapped. To see teh intimate details of how the memory footprint has changed, looking at the .map file generated with and without the "MoreRAM[8]" array (or diff the two map files I generated and renamed: Guard2Kplus.map and Guard2Kplus.map).

A Long Term Solution:
It is expected that at some future date, Renesas will be rolling out a unified linker that is already part of the default H8 tool chain. This linker has a feature for validating that occupied memory sections fit into available regions of physical memory. This feature (when activated and set up correctly) can be made to generate warnings at link time if any data items would be located outside of available RAM. This H8 linker feature is called “Verify”, and it allows you to define an address map and generate warnings if sections get linked outside it. (see attached screen dump).