davidoz

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 37 total)
  • Author
    Posts
  • davidoz
    Participant

    Hi,

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

    Cheers

    David

     

    davidoz
    Participant

    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 6 months, 1 week ago by davidoz.
    davidoz
    Participant

    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
    Participant

    oops file attached

    davidoz
    Participant

    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

    in reply to: Getting GDB version slow after toolchain update #34647
    davidoz
    Participant

    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

    in reply to: Getting GDB version slow after toolchain update #34643
    davidoz
    Participant

    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

     

    in reply to: Getting GDB version slow after toolchain update #34604
    davidoz
    Participant

    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

     

    in reply to: Getting GDB version slow after toolchain update #34602
    davidoz
    Participant

    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
    
    
    
    in reply to: Semihosting using GDB from the command line #33343
    davidoz
    Participant

    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
    Participant

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

     

    Thanks

    David

    davidoz
    Participant

    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 2 years, 8 months ago by davidoz.
    in reply to: Where did my call stack go? #29992
    davidoz
    Participant

    Looks like you fixed the problem.  Many Thanks.

    in reply to: Where did my call stack go? #29890
    davidoz
    Participant

    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.
    in reply to: Where did my call stack go? #29873
    davidoz
    Participant

    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

Viewing 15 posts - 1 through 15 (of 37 total)