[karlis77]

It was built. Anyway I made a new project and everything works now. I do not know what was the cause of this. Maybe it has something to do with directory.

[karlis77]

Ok, nvm I solved the issue.

There was hardware bug regarding the Reset signal or MCU

[karlis77]

I found the linker script but I do not have much idea what to do with it.  The flashmemory address and length is shown correctly.

I am not sure about _estack address..

 

[karlis77]

Ok, I think I just found the solution:

Had to click: Rebuild MSBuild & IntelliSense files for toolchain

[karlis77]

Ok I will try that.

How to update the VisualGDB? Should I just download it from http://visualgdb.com/download/ ?

[karlis77]

Thanks for answer.

I can’t seem to find this “Regenerate MCU files” button.  This is how the window appears to me.

[karlis77]

When I make a project with STM32F051R8  then in  STM32f0xx.h file it is highlighted that STM32f051R8 is selected and everything is fine.

When I make project with STM32F030CC then in STM32f0xx.h file it is highlighted that STM32F030 is selected and I can’t access features which STM32f030cc has.

I uploaded 2 pictures below so you can see what I mean.

STM32F030CC

STM32F051R8

[karlis77]

I updated BSP to V3.5, but it still does not work.

This is stm32.mak file of the project

 

#This file is generated by VisualGDB.
#It contains GCC settings automatically derived from the board support package (BSP).
#DO NOT EDIT MANUALLY. THE FILE WILL BE OVERWRITTEN.
#Use VisualGDB Project Properties dialog or modify Makefile or per-configuration .mak files instead.

#VisualGDB provides BSP_ROOT and TOOLCHAIN_ROOT via environment when running Make. The line below will only be active if GNU Make is started manually.
BSP_ROOT ?= $(LOCALAPPDATA)/VisualGDB/EmbeddedBSPs/arm-eabi/com.sysprogs.arm.stm32
EFP_BASE ?= $(LOCALAPPDATA)/VisualGDB/EmbeddedEFPs
TOOLCHAIN_ROOT ?= C:/SysGCC/arm-eabi

#Embedded toolchain
CC := $(TOOLCHAIN_ROOT)/bin/arm-eabi-gcc.exe
CXX := $(TOOLCHAIN_ROOT)/bin/arm-eabi-g++.exe
LD := $(CXX)
AR := $(TOOLCHAIN_ROOT)/bin/arm-eabi-ar.exe
OBJCOPY := $(TOOLCHAIN_ROOT)/bin/arm-eabi-objcopy.exe

#Additional flags
PREPROCESSOR_MACROS += ARM_MATH_CM0 STM32F030CC stm32_flash_layout STM32F030
INCLUDE_DIRS += . $(BSP_ROOT)/STM32F0xxxx/STM32F0xx_StdPeriph_Driver/inc $(BSP_ROOT)/STM32F0xxxx/CMSIS_StdPeriph/Device/ST/STM32F0xx/Include $(BSP_ROOT)/STM32F0xxxx/CMSIS_StdPeriph/Include $(BSP_ROOT)/STM32F0xxxx/CMSIS_StdPeriph/RTOS
LIBRARY_DIRS +=
LIBRARY_NAMES += compactcpp
ADDITIONAL_LINKER_INPUTS +=
MACOS_FRAMEWORKS +=
LINUX_PACKAGES +=

CFLAGS +=
CXXFLAGS +=
ASFLAGS +=
LDFLAGS +=
COMMONFLAGS += -mcpu=cortex-m0 -mthumb
LINKER_SCRIPT := $(BSP_ROOT)/STM32F0xxxx/LinkerScripts/STM32F030CC_flash.lds

[karlis77]

BTW, I just updated my Visual GDB, but it did not update the BSP. It is still version 3.3, and when I choose STM32F030CC for new project, there still is a STM32F030 in the end of preprocessor macros instead of STM32fF030CC

[karlis77]

<h5>I checked the stm32.mak file and it differs from the line you wrote. Here is mine:
PREPROCESSOR_MACROS += ARM_MATH_CM0 STM32F030CC stm32_flash_layout STM32F030</h5>
<h5>
If I change the STM32F030 to STM32F030CC in the end of line it still does not work.</h5>
I guess I am using BSP version 3.3, because this is what I found in BSP file.
<PackageVersion>3.3</PackageVersion>

Yes, this same problem happens when I create a new project with this model. It does not happen when I choose STM32F051R8 for example.

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

[Author]

Posts