[janulo]

Hello,

First of all, thank you Artem for your posts, it helped me to find out what is the issue in my case

I had similar issue with STM32L471. It turned out, that problem was not with changing of MSI clock (from 4MHz to 24MHz to boost jtag) by debugger, but with disabling instruction cache when writing into FLASH_ACR register (in order to set flash latency and enable prefetch). My init code didn’t set cache on/off at all, and therefore I had different behavior when starting using debugger (which disabled instr. cache) compared to restart by application itself (which kept instr. cache enabled as this is the default state after reset).

So maybe not that much related to your issue Artem, but maybe it’s worth to check if you are configuring everything, what was touched by debuger, in your init code (even something not that much related to clock as instruction cache).

Here is the part of openocd cfg (stm32l4x.cfg in my case), which was modifying cache configuration – first mww instruction touching FLASH_ACR register:

$_TARGETNAME configure -event reset-init {
	# CPU comes out of reset with MSI_ON | MSI_RDY | MSI Range 6 (4 MHz).
	# Use MSI 24 MHz clock, compliant even with VOS == 2.
	# 3 WS compliant with VOS == 2 and 24 MHz.
	mww 0x40022000 0x00000103   ;# FLASH_ACR = PRFTBE | 3(Latency)
	mww 0x40021000 0x00000099   ;# RCC_CR = MSI_ON | MSIRGSEL | MSI Range 9
	# Boost JTAG frequency
	adapter_khz 4000
}

Regards

Jan

[janulo]

Thank you, great

[janulo]

Additional question – how it’s recommended to handle files which differs only by case sensitivity? e.g. ipt_ttl.h vs ipt_TTL.h (usr/include/linux/netlilter_ipv4/)

AFAIK windows NTFS doesn’t support case sensitivity in file names, while ext4 on Ubuntu does.

[janulo]

It’s not so critical for us, so we will wait for official release of device sharing tool.

TinyEmbeddTest works nice so far. If anything occurs, I’ll start new thread to help you with improvements of it. Thanks for your help so far.

[janulo]

Hi,

Our build server is running on Azure cloud, so we can not attach evaluation board directly to it. Tool for sharing the boards could do the job, so we are definitely interested in that tool. Please let me know how shall we proceed to obtain it.

Thanks for nice explanation of testing possibilities without hardware, we will consider it. Hopefully evaluation board solution will do the job.

PS: Bit off topic, but which testing framework would you recommend for embedded devices, e.g.  512kB flash, 128kB RAM CortexM4 MPU (STM32L471)? I was able to start some tests on TinyEmbeddedTest only so far, but it may be just my lack of knowledge. I have some issues with TinyEmbeddedTest as well, but if I won’t be able to resolve it, I will start a new forum thread to not mix topics.

[janulo]

Hi, thanks for your reply.

For beginning, high-level tests without hardware dependency will be fine. But to get higher test coverage, I think hardware-specific test will be nice to have as well. I’m just starting with Unit Tests stuff, so I’m not sure what will be easier to achieve.

Our project is running about 2 years without any Unit Tests, so we would like to add as many tests as reasonable to the existing code, as well as try to cover majority of new code with tests. Any amount of tests should be better than current – zero

[janulo]

Hello, anything new here? I’m also interested in running Unit Tests on windows machine without need for real hardware / debugger – to be able to run it on Windows build server. Our target is STM32 as well. We are just starting with Unit Tests, playing with TinyEmbeddedTest, but we may probably go for any framework.

[janulo]

Thank you for your answer, it helped a lot! Your recommended solution works without problems.

Have a nice day!

[janulo]

Hi,

I’m sorry for my delayed response.

I’ve tried this simple project and _ZSt9terminatev function is linked correctly from libcompactcpp.a. Unfortunately, priorities on project have changed and I have to postpone this downsizing task. I’ll compare main project with the test project and I will come with results, or with full Map and verbose log, ASAP. Thanks for understanding.

Jan

[janulo]

I’m fighting with text editor Using <> for my comments was not good idea, so one more try with { }.

c:\SysGCC\arm-eabi/bin/arm-eabi-g++.exe -o Release/BCR-G2_demo.elf -Wl,-gc-sections -Wl,-q -Wl,  -TSTM32L471VG_flash_wCRC.lds  -mcpu=cortex-m4 -mthumb -mfloat-abi=hard   -Wl,-Map=Release/BCR-G2_demo.map -Wl,--start-group Release/system_stm32l4xx.o Release/stm32l4xx_hal.o
{skipped .o files here}
-lcompactcpp  {local path}STemWin528_CM4_GCC.a  -Wl,--end-group

 

[janulo]

Hi, thanks for trying to help me

I’m not using MSBuild, but when I check output window, the almost last line is quite long (I skipped the .o file and left only some to make this shorter, my comments are inside { }. Also I put this on multiple lines to make it more readable ):

c:\SysGCC\arm-eabi/bin/arm-eabi-g++.exe -o Release/BCR-G2_demo.elf -Wl,-gc-sections -Wl,-q -Wl,  -TSTM32L471VG_flash_wCRC.lds  -mcpu=cortex-m4 -mthumb -mfloat-abi=hard   -Wl,-Map=Release/BCR-G2_demo.map -Wl,--start-group 
Release/system_stm32l4xx.o Release/stm32l4xx_hal.o {lot of other .o files}
-lcompactcpp  
{local path}STemWin528_CM4_GCC.a  -Wl,--end-group

 

• This reply was modified 7 years, 9 months ago by janulo.
• This reply was modified 7 years, 9 months ago by janulo.

[janulo]

Hi,

 

It looks like this _ZSt9terminatev is comming from libstdc++.a:

 .text._ZN10__cxxabiv111__terminateEPFvvE
 0x0804bfc0 0x28 c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/6.2.0/../../../../arm-eabi/lib/thumb/fpu/cortex_m4\libstdc++.a(eh_terminate.o)
 0x0804bfc0 _ZN10__cxxabiv111__terminateEPFvvE
 .text._ZSt9terminatev
 0x0804bfe8 0x14 c:/sysgcc/arm-eabi/bin/../lib/gcc/arm-eabi/6.2.0/../../../../arm-eabi/lib/thumb/fpu/cortex_m4\libstdc++.a(eh_terminate.o)
 0x0804bfe8 _ZSt9terminatev

[janulo]

Hi,

If I’m not wrong, we are already using arm toolchain: VisualGDB properties – Makefile settings – Toolchain: ARM in c:\SysGCC\arm-eabi.

During compilation, I can see in Output window instructions starting with following (so this should not be the case of 3rd-party toolchain):

c:\SysGCC\arm-eabi/bin/arm-eabi-gcc.exe
c:\SysGCC\arm-eabi/bin/arm-eabi-g++.exe
c:\SysGCC\arm-eabi/bin/arm-eabi-objcopy.exe

[janulo]

Hi,

 

thanks for your response. I tried your recommendation, but no change in flash memory used. We are not using any pure virtual methods, but still a lot of classes and std::arrays, it may be related?

I will try to insert screenshot from memory explorer:

 

• This reply was modified 7 years, 9 months ago by janulo. Reason: screenshot edit

[janulo]

I’ve just tried to switch solution platform to ARM and when trying to start debugging I get MessageBox with title “Microsoft Visual Studio” and text: “Unable to start debugging. Check your debugger settings by opening project properties and navigating to ‘Configuration Properties–>Debugging’ “.

If I switch back to Win32 platform, debugging works fine. 

So version fix have stabilized behavior of debugger – it always starts. But you can not use solution platform switch, I always have to use Win32 option. For me it’s not a problem, I just tried this ARM option if it does not help me with disabling _WIN32 symbol, which is defined by default in VS – as described in Predefined Macros

I will create new forum post regarding this _WIN32 symbol.

[Author]

Posts