Embedded Memory explorer uncorrect memory name visualization

[pierantonio.brea@sitecsrl.it]

Good morning

I’m using a board with stm32f429 MPU with an external 16M RAM memory placed at 0xc0000000.
For application purposes, I have to use the external memory as main memory.
By appropriately modifying the startup files and the  linker script , the program is compiled
and executed correctly .

the memory section(inside linker script) is described in this way
MEMORY
{
FLASH (RX): ORIGIN = 0x08000000, LENGTH = 2M
RAM2 (RWX): ORIGIN = 0x20000000, LENGTH = 192K
CCMRAM (RWX): ORIGIN = 0x10000000, LENGTH = 64K
/ * — begin generated external memories – * /
SRAM (RWX): ORIGIN = 0xc0000000, LENGTH = 16M
/ * — end generated external memories – * /
}

However, the Embedded Memory window does not display the memory Names  and sizes as they were
configured in the script linker; but keeps the NAME and dimension as default (eg. SRAM 192k at 0x20000000 instead 16384k at 0xc0000000) (see attached file)

Is it a wrong configuration /usage ?

How can these descriptions be modified/correct?

Thanks for your help

Pierantonio

Attachments:

You must be logged in to view attached files.

[support]

Hi,

Please ensure you are using the VisualGDB Project Properties -> External Memories page for defining the external memories. This mechanism automatically updates the memory layout definition used by the Embedded Memory Explorer.

We are also working on experimental support for parsing the linker scripts and detecting custom modifications to the memory list, however it will take a few weeks before we release a preview build with this functionality.

[davidoz]

G’day all,

I also have an issue with the Embedded Memory Explorer when using Extra Memories.  The static stack analysis is such a great tool, I’m really eager to get it working.

The Extra Memories were created successfully.  Code and data was relocated to the new addresses.  The Embedded Memory Explorer Summary/Detail view shows all the right addresses.

The problem is every function in the Static Stack Analysis is red flagged as containing jumps to an invalid address (as seen in the screenshot).  The strange thing is even empty functions that don’t call anything are still red flagged.

Any suggestions appreciated.

Cheers

David

p

 

Attachments:

You must be logged in to view attached files.

[support]

Hi,

The “jumps to invalid address” would happen if the target address of a jump instruction was not listed in the disassembly output produced by the objdump tool. This might indeed happen with some combination of section flags and linker script rules, however we would need to know more details in order to reproduce/fix it.

If you could attach a basic repro project (ensure you remove the .vs and VisualGDB folders containing large generated files), or describe the exact repro steps (the address of the new memory, the exact changes to the source files), we should be able to reproduce and fix the problem promptly.

[davidoz]

Hi,

Thanks for your prompt reply.

I generated the FlashingLED (with RTOS) project for the SM32H7.  I then created two external memories:  NOR_FLASH and SDRAM.  These appeared as new memories in the Linker Control script.  I then manually placed all output sections into these memory locations.  Note that I did not use the newly created input sections (e.g  <span>.nor_flash_text).  It is impractical to apply the section attribute to every variable and function in the project.</span>

Note, you can not run the output directly (you need a bootstrap to configure the external memory first).  However, you can still see that the Static Stack Analysis does not work.  All function are flagged as containing jumps to invalid addresses  (even empty functions with no jumps 🙂  )

Cheers

David

 

 

Attachments:

You must be logged in to view attached files.

[support]

Thanks, looks like this memory layout slightly changed the format of the output from objdump that was used by VisualGDB to gather disassembly data.

We have fixed it in the following build: VisualGDB-5.5.1.3299.msi

[davidoz]

Awesome turnaround.  It works really well now.

Cheers,

David

 

[Author]

Posts