kowalski5233

Forum Replies Created

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • in reply to: VisualGDB issues and feature requests #7818
    kowalski5233
    Participant

    Ah, ok, yes, we have the Embedded version, so manual override then 🙂

    Thanks for the feedback

    in reply to: VisualGDB issues and feature requests #7807
    kowalski5233
    Participant

    Hi support

    Thanks so much for the quick feedback, even after the post resurrection.  That seemed to have done the trick!  I downloaded the ‘trial’ from the download site and took a chance and installed it, but it retained the license, and all seems well.  It now says v5.1 build 660.

    I just thought I should mention that we’ve ran into another snag.  We want to stick to a specific version of the BSP and not run the risk of conflicting versions, so the BSP is also added to the repository.  The problem is that the compiler (intellisense seemed to have had that down) kept looking for the BSP in the C:\Users\myuser\AppData\Local\VisualGDB\EmbeddedBSPs.  With a lot of toying and trying to figure out what is defined where, etc, etc, I finally changed the BSP_ROOT definition in nrf5x.mak from a ?= to a =, which solved the problem.  It just feels like there’s no obvious place in the environment where it can be overridden/set, unless you go and scratch in the .mak files, which has the following line in it “#DO NOT EDIT MANUALLY. THE FILE WILL BE OVERWRITTEN.”.

    Have a good weekend!

    in reply to: VisualGDB issues and feature requests #7791
    kowalski5233
    Participant

    Good day people

    Resurrect after so nearly a year.  Sorry about that, but point #1 deals exactly with an issue we’re experiencing, albeit with v5.1, and don’t want to repost if it is already in discussion.

    So, same, as described, a co-developer created the project, but when I try to do anything make.exe related, it complains that
    “‘$’ is not recognized as an internal or external command, operable program or batch file.”

    The Toolchain is set as “ARM in C:\SysGCC\arm-eabi”, nfr5x.mak contains “TOOLCHAIN_ROOT ?= C:/SysGCC/arm-eabi”, so all seems in order.  We’ve even tried the workaround suggested by swineone, but no luck.  We’ve tried added ‘set’ to the makefile, under all: and clean: and nothing there either.
    What does work is if I explicitly direct the make.exe location to C:\SysGCC\arm-eabi\bin\make.exe instead of $(TOOLCHAIN_ROOT)\bin\make.exe, but for obvious reasons we’d prefer it if it was not a static address, as install locations can vary.

    Any feedback regarding this on the latest version, or is there something silly we’re missing?

    Regards

Viewing 3 posts - 1 through 3 (of 3 total)