[andyjt]

Hi,

This is still an issue 5 years on.

My current project has got up to 1.5Gb which is a bit ridiculous when source files are only 1.5Mb

Is there a clean up button or something ?

I noticed that the projectname.sdf file is getting pretty big as well.

We tend to copy previous projects and manually rename and update the project/solution GUID’s – maybe this is not helping the situation ?

I think our projects also have leftover stuff from pre-msbuild and older versions of visualGDB – any advice on reducing project size would really help us

Thanks

[andyjt]

If anyone else gets the annoying grey text on grey background in Dark Mode, I found the setting for it (see attached)

Change the Background to something other than Default

I’d still like to know how to turn this off though. ALT+Enter or CTRL+. is there if you really want it

Attachments:

You must be logged in to view attached files.

[andyjt]

This is too annoying for words.

Please tell me how to get rid of these daft light bulb moments

Attachments:

You must be logged in to view attached files.

[andyjt]

Try turning on Hardware floating point support in your BlinkLED project.

[andyjt]

Those numbers look suspiciously like Program Counter, Stack or Variable addresses. I guess the bootloader and firmware code is getting mixed up.

I’d be checking the contents of your .lds file is correct and takes into account the bootloader address and firmware address ,eg something like:

MEMORY
{
BOOT (RX) : ORIGIN = 0x08000000, LENGTH = 16K

FLASH(RX):: ORIGIN = 0x08004000, LENGTH = ??K
SRAM (RWX) : ORIGIN = 0x20000000, LENGTH = 320K
}

I’d also double check the lengths and that _estack address is correct – I found  a problem with a lesser used STM32F303C8T6 micro had the estack set above the actual 12K (IIRC?) in the .lds file provided by VisualGDB

 

 

[andyjt]

I’m glad it was of help to someone and thanks for sharing your experiments 🙂

Since playing with the discovery, I moved onto a full blown STM32F7-EVAL board and possibly found the cause for having to disable the caches. For me it was related to reading the NOR flash ID, but could also explain the corrupted images in stemwin with the cache enabled.

You can try turn back on the I and D cache but configure the MPU (Memory Protection Unit) so that it doesn’t cache the (SDRAM?) memory area used for the screen framebuffer or maybe the memory containing the source images? That way the graphics should copy and display correctly but you’ll retain the advantage of faster code execution if the embedded memories are cached.

See this post on the ST forum: https://my.st.com/16aab033

 

 

• This reply was modified 8 years, 11 months ago by andyjt.

[andyjt]

On this same topic, I’m trying to get the QSPI_perfs Application to compile and struggling to get it to create a Hex or Elf file of the image’s data.
(example here: \STM32\STM32Cube_FW_F7_V1.1.0\Projects\STM32746G-Discovery\Applications\QSPI\QSPI_perfs)
If I compile with IMG_NO_DATA defined then the build fails with error VGDB1002: undefined reference to img6
So, if I undef the flag then this is the code in img6.h and I’m guessing it should compile to a different text area (.textqspi)

#ifndef IMG_NO_DATA
#if defined ( __ICCARM__ )
#pragma location = ".textqspi"
#else
__attribute__((section(".textqspi")))
#endif
const unsigned char img6[261120] =
{
0x1E, 0xC7,
0x1E, 0xC7, etc...

At the moment, this won’t compile either, it ignores the section name and fails because the images overflow the STM’s internal flash…
c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/5.2.0/../../../../arm-eabi/bin/ld.exe: Debug/STM32F7QuadSPI.elf section .text will not fit in region FLASH

How do I setup VisualGDB to compile data hex files that I can download to QuadSPI using STLink and then access those data arrays from my program ?
Thanks in advance

[andyjt]

Thanks, the USB driver tool worked.
I can now use STLink Utility and OpenOCD.

Am I right in thinking that the Quad SPI flash can only be programmed from the STLink ?
I don’t seem to be able to ‘read’ memory at 0x90000000 from STlink utility, only erase and program.

[andyjt]

Thanks for the reply.

Using STLink is an issue at the moment as it doesn’t find the board anymore…could this be related to VisualGDB taking control of the driver ?
I have tried it with VisualStudio closed but STLink still wouldn’t find the board 🙁

If you could do a tutorial on reading image data from QSPI flash or the SD card would be very helpful I’m sure!

Regards

 

 

[Author]

Posts