Instruction memory map utility

[Panu]

Here's a small utility to help keep track of how much code space you are using.

ovlinfo.png (57.6 KiB) Viewed 18695 times

[Panu]

And while we're at it, here's another utility to help you keep track of what's using your program memory the most. This command line utility prints out a sorted listing of all sections in a program.

coffinfo.png (35.2 KiB) Viewed 18693 times

[rolffson]

Hi Panu,

thx for providing these tools.

Up to now I always copied the vs3emu -l output to excel to extract the numbers and get a better overwiew of the memory consumption (when I once again ran out of space... ), but this really helps to save time.

Kind Regards
Michael

[pszturmaj]

Thank you for providing these tools, but sometimes the memory map utility is unreadable (see screenshot). I guess vertical scrollbar would solve this problem

Screenshot: http://i.imgur.com/su9yLAC.png

[Panu]

Perhaps, but the memory map in your picture really looks weird as it's in two pieces. What chip are you targetting?

-Panu

[pszturmaj]

Perhaps, but the memory map in your picture really looks weird as it's in two pieces. What chip are you targetting?

I'm targetting the VS1005G.

[Panu]

I'm targetting the VS1005G.

In that case, there is an error in your project's memory description file: you shouldn't have anything below 0x4000 enabled for your app (except vectors).

Please post the memory description file so I can help...

-Panu

[pszturmaj]

Code: Select all

# This is a memory description file for safely portable VSOS 0.2x applications.

MEMORY {
	page 0:
	kernel_iram1: origin = 0x0080, length = 0x0360
	#kernel_iram2: origin = 0x0400, length = 0x3c00
	#kernel_hooks: origin = 0x7fd0, length = 0x0030
	#app_i: origin = 13640, length = 1720
	app_iram: origin = 0x4000, length = 0x3fd0
	
	page 1:
	#kernel_x1:    origin = 0x2100, length = 0x0300
	#kernel_x2:    origin = 0x2500, length = 0x1b00
	#rtos_x:    origin = 0x7fe0, length = 0x0020
	#ethbuf:	origin = 0x2500, length = 0x0C00
	app_xram: origin = 0x4000, length = 0x3fe0
	#app_xram: origin = 0x4000, length = 0x2000
	#app_xram: origin = 7122, length = 9262
	
	page 2:
	#kernel_y:     origin = 0x1800, length = 0x0800
	#kernel_y:     origin = 0x1800, length = 0x0080
	#intv_y:    origin = 0x6fe0, length = 0x0020
	#app_yram: origin = 0x2000, length = 0x4fe0
	#app_yram: origin = 0x3000, length = 0x3fe0
	app_yram: origin = 0x4000, length = 0x3fe0
	#app_yram: origin = 0x2000, length = 0x4fe0
	#perip:		origin = 0xFC00, length = 0x400
	#eth:	origin = 0xFC60, length = 3
	#rtc:	origin = 0xFEA0, length = 3
	#timer0: origin = 0xFE86, length = 2
}

CORE {
	frequency = 12.288MHz
}

I'm using the same memory map file for VSIDE debugging and APP compiling. For this, I debug using c-1005g.o startup module (also linked with rom1005g.o) then for APP mode I remove rom1005g.o and change c-1005g.o to vsos02.o (yes, I should've make a build conf. for this ). It worked most of the time, but sometimes I get some weird errors (I know it stomps on some memory), but then I usually adjust memory desc. file and it works again. Only now, it seems I can not get it to work... (based my project on "VS1005 Hello World")

Could you provide reliable VS1005 mem_desc files for these two working models?

[pszturmaj]

Commented out the 1st line and now the memory map is continuous. I needed that line before to suppress "can't allocate at 0x80" linker error. I don't know why but now there's no error.

[Panu]

Right. 0x80 is the reset vector of SPI bootable code (referenced by such c*.o startup modules) but VSOS v2 apps are loaded from 0x4000 with dynamic main() entry point so they don't need memory below that.

-Panu