[davidoz]

Hi,

Thanks for the explanation.  It all makes sense and I’ll start using the new version.

Cheers

David

 

[davidoz]

Hi Support,

I’m starting a new STM32Cube project and will be using CMake to build for the first time.  I’ve noticed some issues with the generation of the filters in VS:

1. I create STM32Cube project and import it into VS.  I then build the project successfully.  Later, I add a new middleware module (e.g FreeRTOS) in STM32Cube and re-generate the stm32Cube project and code.  The next time I open the VS project, it detects the STM32Cube project has changed.  I hit the resolve button.  It imports the new files ok, but they are not under any filters.  When using GNU Make, this process worked correctly.  Btw, the filters are created correctly if I had included FreeRTOS in the initial project creation.  It is only adding it later is a problem.

2. When I add a folder recursively (Add -> Import Folder Recursively) it doesn’t add them under any filter (like above) even though that option is selected in the dialog.  I don’t think this process worked with GNU Make either.

3. I’m not sure if this next issue is by design or a defect.  When it initially imports the STMCube project, and it comes across a folder (say “Inc” containing *.h files), it creates two filters called Inc under the Source Files and Header Files.  However they are not independent.  The one under Source Files is empty and if you delete it, the one under Header Files (which contains actual files) is also deleted.  I can see this might be advantageous if you have a folder containing both source and headers files, but when they are already separated, it is confusing having an empty Inc filter under Source Files.

I can fix all the problems manually, but regenerating a project or dragging in existing code with complex directory structures will be time consuming.

Can you let me know if I’m doing something wrong or if there is a workaround?

 

Cheers

David

• This reply was modified 1 year, 3 months ago by davidoz.

[davidoz]

Sorry the file is too big.  I’ve removed most of the source files so it wont compile, but it should still show you how the import works.

Attachments:

You must be logged in to view attached files.

[davidoz]

oops file attached

[davidoz]

Hi Support,

Importing an STM32CubeIDE project with MSBuild or GNU Make populates the filters incorrectly.  Using the CMake method imports correctly (although it still creates unnecessary empty filters e.g. an “Inc” directory will create an empty “Inc” filter under the Source Code filter – no bid deal).

I have attached an example STM32Cube project for you to try.

I have been resisting the move to CMake because it has more out-of project dependencies than GNU Make, but it looks like I will need to make that leap.  Is there a tutorial on how to setup up a build server with a CMake build? installations, command lines,  etc.  If not, I will ask my questions on a separate log.

Cheers

David

[davidoz]

Hi Support,

I understand.  The gcc 12.3.1 came from the released source, and gdb 13.2.1 came from the pre-release.

The GDB binary that ARM released is definitely a debug build, so it must be an issue with their deployment process.

 

Thanks

David

[davidoz]

Hi Support,

I can also confirm the new build is working correctly.  Thanks for the update.

Is the source code you used to produce the build an official release from ARM?  i.e. not a beta?

 

Cheers

David

 

[davidoz]

Hi Support,

Thanks for letting me know.  We don’t use windows defender (it’s disabled), but we do use other virus software that isn’t visible to me (I can’t disable it).  I haven’t found my situation to be intermittent, it is consistently 42 seconds.  I did find typing the commands directly into the gdb shell was a bit faster, but still a lot slower than instantaneous.

I noticed the 12.2.1 version of arm-none-eabi-gdb.exe is 260KB while the 10.3.1 is 6KB.  It looks like they released the debug version by mistake.  I don’t think that is the issue since the patched version 12.3.1 is 8KB and is still slow.

Another dev has reported the same problem on the ARM Forum, but no answers yet:

https://community.arm.com/support-forums/f/compilers-and-libraries-forum/54939/the-latest-arm-none-eabi-gdb-version-12-3-rel1-takes-20-seconds-reading-symbols-from-elf-file

 

I’ve replaced the new gdb with the old gdb as suggested and that is working.  Thanks for letting explaining the “not implemented” issue.

 

Cheers

David

 

[davidoz]

Hi Support,

The new gdb didn’t help.  It is still slow.  I have sent you the ELF in the support ticket as requested.  I did try an old ELF with the new toolchain but that also was slow.  I don’t think the issue is with reading the ELF, but I’ll let you have a look.

Btw, the new toolchain is expecting _fstat, _getpid and _kill to be implemented.  Will dummy functions of these be added to the profiler code?

c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-fstatr.o): in function `_fstat_r':
fstatr.c:(.text._fstat_r+0xe): warning: _fstat is not implemented and will always fail
c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-signalr.o): in function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): warning: _getpid is not implemented and will always fail
c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-signalr.o): in function `_kill_r':
signalr.c:(.text._kill_r+0xe): warning: _kill is not implemented and will always fail

[davidoz]

Hi Support,

Thanks for your quick reply.  I was using your version of OpenOCD but there must be more to it than I thought.

Cheers

 

[davidoz]

Thanks for your reply.  I’ll get the hardware guys to look into it.

 

Thanks

David

[davidoz]

I should also point out, the exception usually occurs at the spot shown in the screenshot.  However, it is not always the case.

• This reply was modified 3 years, 5 months ago by davidoz.

[davidoz]

Looks like you fixed the problem.  Many Thanks.

[davidoz]

Again sorry I didn’t see your last reply.  I don’t know why I’m not getting email notifications when you reply.

He is the diagnostic data.  I’ve zipped the trace and the screenshot.

There does seem to be an issue in the trace, but hopefully you have a better understanding of what it means 🙂

[+452] Reading disassembly stream (0/0): 447 msec
[+15] ExecuteRawCommand(x/62xb 0x8001902, d)
[+3] ExecuteFrameSensitiveCommand(-stack-list-frames, 1, -1)
[+0] ExecuteRawCommand(-stack-list-frames –thread 1, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteRawCommand(-thread-select 1, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteFrameSensitiveCommand(-stack-list-frames 0 0, 1, -1)
[+0] ExecuteRawCommand(-stack-list-frames –thread 1 0 0, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteRawCommand(-thread-select 1, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteFrameSensitiveCommand(-data-evaluate-expression “\$pc”, 1, -1)
[+0] ExecuteRawCommand(-data-evaluate-expression –thread 1 “\$pc”, c)
[+0] Cannot accept command: another command is already running
[+0] ExecuteRawCommand(-thread-select 1, c)
[+0] Cannot accept command: another command is already running
failed to query the frame list
at yu1.EnumFrameInfo
at System.Threading.SynchronizationContext.WaitHelper

Cheers

David

Attachments:

You must be logged in to view attached files.

[davidoz]

Hi Support,

Sorry, some how I missed your last reply.

When I download the new build, I get a file called VisualGDB-5.5.104.3970.msi.  That’s not the same text in the link  VisualGDB-5.5.104.3941.msi.  I am assuming that is just a typo.

After installing the new build, unfortunately I still have the same problem.  When clicking on a method in the stack trace, often the whole stack trace list disappears.  I have to step to the next instruction in the program for the stack trace to be repopulated.

I have discovered if I double click a function in the stack trace and the list survives then that function always works.  If I double click a function and the list disappears, then that will always happen when I double click that function.

 

Thanks for your assistance.

 

Cheers

David

[Author]

Posts