codex653

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 42 total)
  • Author
    Posts
  • in reply to: Binary Flashing the STM32 #20868
    codex653
    Participant

    It’s an MSBuild type.

    in reply to: Binary Flashing the STM32 #20866
    codex653
    Participant

    Ok that is what I thought. Is there a way to check if that setting is enabled after the project is created? I went looking through my project settings and didn’t see anything explicitly labeled for generating/not generating the binary. I know that is an option during set up.

    in reply to: Frequent CLang Engine Crash #19916
    codex653
    Participant

    Interesting! If I manage to get some free time I’ll try and dig into it. Thanks for the update.

    in reply to: Frequent CLang Engine Crash #19905
    codex653
    Participant

    Well, it worked fine enough for about a day or so, but it’s started back up again. I’ve attached the new dump file.

    Attachments:
    You must be logged in to view attached files.
    in reply to: Frequent CLang Engine Crash #19892
    codex653
    Participant

    I’ve installed it and I’ll post back if anything goes awry. Thanks.

    in reply to: Frequent CLang Engine Crash #19871
    codex653
    Participant

    Trying a different file extension…

    Attachments:
    You must be logged in to view attached files.
    in reply to: Point VisualGDB to use git repo for ESP32 build #13464
    codex653
    Participant

    Thanks jsmith. I’ll try that out later tonight. I’ve definitely noticed the lackluster debugging capabilities as compared to ARM. I do most of my projects on some form of an ARM based chip and migrating over to the ESP was a bit of a shock (2 breakpoints?!). Ah well. I’d agree that VisualGDB has done a lot.

    in reply to: Point VisualGDB to use git repo for ESP32 build #13459
    codex653
    Participant

    Support:

    This sounds like a much better solution than the route I was trying to go. I’ve made it through most of the linked tutorial, however building the imported files leads to an error with the toolchain. Upon building, the output windows spits out the message included in the attached file.
    Obviously there is the issue of the toolchain being out of date. I built originally with the latest from Espressif here and tried to update the VisualGDB toolchain from the package manager, but found I had no updates available. I’m guessing that to somehow switch out the toolchain I would need a modified version of that C:\SysGCC\esp32\bin\bash.exe file? Not too sure how to proceed.

    Jsmith:

    What is your setup like for utilizing the external ESP-IDF? Are you debugging inside of the VisualGDB environment? That’s primarily what I am interested in as I can build the code fine with the external tools if need be. I’ve become addicted to the VisualGDB style of interactive debugging as it seriously increases my productivity

    • This reply was modified 6 years, 3 months ago by codex653.
    • This reply was modified 6 years, 3 months ago by codex653.
    Attachments:
    You must be logged in to view attached files.
    in reply to: Point VisualGDB to use git repo for ESP32 build #13441
    codex653
    Participant

    Update 2:

    I discovered the Sysprogs BSP generator project: git repo and the associated wiki here

    This looks promising.     Edit: Some samples of using the generators from scratch would be really nice. The wiki describes how to use the code at a high level, which I understand, but I’m struggling how to parse that down into the details of actually using the tools for my project.

    • This reply was modified 6 years, 3 months ago by codex653.
    in reply to: Point VisualGDB to use git repo for ESP32 build #13440
    codex653
    Participant

    Update:

    I built my project following the Espressif ESP32 getting started tutorial here using the latest commit from the official Espressif IDF github repo mentioned earlier. This verified that my bug was fixed using the updated code, so now I’m quite motivated to figure out how to instruct VisualGDB to utilize the repo source code instead of the default installed BSPs. I’ll post more as I figure things out if I haven’t heard back from the support team.

    in reply to: Point VisualGDB to use git repo for ESP32 build #13438
    codex653
    Participant

    Side note: It’s apparently not as simple as replacing the project esp32-BSPs with the git repo’s version. Any pointers on moving from the repo to a VisualGDB project would be extremely helpful. Judging by the file structure of the included BSPs with a default Visual GDB blinky project for the ESP32, it looks like you guys copied straight from the repo at one point or another as well.

    • This reply was modified 6 years, 3 months ago by codex653.
    in reply to: Possible Bug Found/Feature Request #13298
    codex653
    Participant

    No worries! Thanks for the help.

    in reply to: Embedded Profiler Incredibly Slow #13002
    codex653
    Participant

    Ok I’ll follow that and get back to you.

    in reply to: Embedded Profiler Incredibly Slow #12998
    codex653
    Participant

    Found it. I didn’t realize that to get to the Live Profiling window, an analysis session had to be started through the Analyze->Analyze Performance with VisualGDB. I’ve attached the output of the live session and the diagnostics.

    It would appear that it is profiling usage counts but not execution time since all the “time” columns are zero?

     

    Attachments:
    You must be logged in to view attached files.
    in reply to: Embedded Profiler Incredibly Slow #12987
    codex653
    Participant

    Sorry about the delay. I’ve been out of town for a few days and haven’t had access to my hardware.

    Oddly today, there is suddenly output in the Live Watch window, but it is pretty much garbage. Time flows backwards occasionally and it sometimes shows time stamps in the several hundred mega-second range. There are red bars that show up periodically, but quickly disappear and I am unable to scale or scroll my way to find them again due to the output screen clearing itself.

    I set the break point inside the function you mentioned and verified that the rec.Address variable repeatedly hits the address of the function I’ve attached to the profiler. When running a regular instrumenting profiler session, I wasn’t seeing an option for me to switch the Live Watch window to “Diagnostics”. Do I need that special build you posted in this thread earlier? I’m currently running on my laptop and never installed that version on here due to debugging previously on my desktop version.

Viewing 15 posts - 16 through 30 (of 42 total)