no manually locate button in toolchain selection dropdown

Sysprogs forums Forums VisualGDB no manually locate button in toolchain selection dropdown

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #28431
    Banxian
    Participant

    Hi
    I want to use the manually locate IAR/Keil compiler function in visualgdb,
    I start visualgdb MDK import wizard, and select use MDK toolchains, when I click “next” button,
    the toolchain documentation https://visualgdb.com/documentation/toolchains/ told me there should have such a “Locate an IAR/Keil compiler installation” button in dropdown list.
    but I can’t found it.
    my visualgdb subscription plan is custom, I think it should contains iar/mdk support.

    I tried to import same mdk-arm project with sysprogs gcc build, but just get inclusion header missing error.

    Attachments:
    You must be logged in to view attached files.
    #28435
    support
    Keymaster

    Hi,

    This feature is very new and requires installing the latest development build. You can download and install it here: VisualGDB-5.5.7.3682.msi

    #28443
    Banxian
    Participant

    thanks your reply.

    I got new problem.

    when I upgrade my 5.5.4 to 5.5.7, I can add toolchains from same UI.

    but after I import the correspond toolchains, the wizard hit me there no device supported for these toolchains.

    I can specify right device if I change project compile type to GCC in previous step, but when I switch to Keil variant, the device support disappeared magically.

    I am sure I installed Keil::STM32F7xx_DFP in Pack Instaler and the original projects just build&run fine in MDK.

    I think the parser for MDK packs may have some hard coded path problem (I customized Packs folder in TOOLS.ini).

     

    I can confirm the IAR importer can recognize device list in EWARM and built fine in my test application, but the semihost console is extreme slow, just one character in one second.

    the jtag probe in onboard stlinkV2 of F723e-disco,

    I guess it should caused by openocd layer, it have overhead in each operation, because same project debugging in EWARM with native st-link support have fast terminal I/O experience.

    Attachments:
    You must be logged in to view attached files.
    #28445
    support
    Keymaster

    Indeed, VisualGDB does not read folder overrides from tools.ini and uses the default folder location. You can find out the paths used by VisualGDB by enabling the diagnostic output in View->Other Windows->VisualGDB Diagnostic Console and then opening Tools->VisualGDB->Manage VisualGDB Packages.

    You can also try posting your tools.ini file and the exact path where the STM32F7xx_DFP package got installed here and we will try to update VisualGDB to handle it correctly.

    Regarding semihosting, please try enabling the VisualGDB’s Advanced Semihosting framework via VisualGDB Project Properties -> Embedded Frameworks. It works much faster than the regular semihosting and does not require stopping the target to handle the output.

    #28446
    Banxian
    Participant

    thanks for you reply.

    I followed your instruction and got these logs:

    Looking for Keil packages for T:\Apps\Keil_v5\ARM\ARMCC…
    Scanning T:\Apps\Keil_v5\ARM\pack…
    Found 0 packages in T:\Apps\Keil_v5\ARM\pack.
    Skipping missing E:\Users\azsd\AppData\Local\Arm\Packs…
    Looking for Keil packages for T:\Apps\Keil_v5\ARM\ARMCLANG…
    Scanning T:\Apps\Keil_v5\ARM\pack…
    Found 0 packages in T:\Apps\Keil_v5\ARM\pack.
    Skipping missing E:\Users\azsd\AppData\Local\Arm\Packs…

    During installation, I was changing Packs path from %localappdata% to mdk folder inside keil_v5 directory, because I have old MDK co-exists in same PC, and I don’t want they conflict  by sharing packs folder.

    RTEPATH=”T:\Apps\Keil_v5\Arm\Packs”

    I choose Packs instead PACK which have pre-installed caches by installer, to avoid conflict.

    I noticed that VisualGDB lookup “PACK” installer, in my condition it only have *.pack and *.pdsc caches. maybe lots people chioce use it as packs folder.

    I will give a try later to check if it harmless for mdk pack installer

    #28448
    Banxian
    Participant

    Hello, I triggered new bug for MDK project importer.

    how to reproduce:

    1 checkout teenyusb project

    git clone https://github.com/xtoolbox/TeenyUSB.git
    <span class="pl-k">cd</span> TeenyUSB
    git submodule update --init
    
    2 open demo\host\host.uvprojx, in project navigator add tusbh_cdc_acm.c and tusbh_cdc_rdnis.c into usb_host group.
    3 create an Embedded project, select another place for solution, in next step, import demo\host\host.uvprojx in visualgdb, select GCC toolchains. check move and rename options, then next.
    4 select ARMGCC by sysprog, click next.
    5 select stlink as debuger, then click finish.
    
    6 after a armgcc protect generated, repeat 1~5 but select Keil ARMClang toolchain instead sysprogs ARMGCC in step3&4.
    7 it does not simply overwrite previous generated project but generate an error in step 5.
    
    bug2:
    delete all generated project and repeat 1~5 with Keil ARMCC. in visualgdb project properties, enable CMSIS::Core in Keil component property page.
    build and visualgdb told me sys/stat.h is missing here.

    #if defined ( __GNUC__ )

    #include “sys/stat.h”

    I am sure in MDK IDE, If armcc compiler 5 selected, the __GNUC__ is just undefined.

     

    #28449
    Banxian
    Participant

    if disable gnu extension in project properties, it will cause invalid macro definition: $$com.sysprogs.bspoptions.primary_memory$$_layout while build.

    I am not sure if it safe for remove it in definitions.

    my previous post have some wrong code highlight, and I can’t find an edit button to fix my reply

    #28488
    support
    Keymaster

    It looks like you are comparing ARMCC (version 5) with the MDK IDE against ARMClang (version 6) with VisualGDB. Please note that these are 2 different compilers and ARMClang indeed defines __GNUC__, even if used with MDK IDE. Please make sure you use the same compiler in both cases.

    Regarding the import errors, indeed trying to create the imported project file in a location where it already exists will result in an error message. If you would like to overwrite the imported project, please make sure you delete the previous project file before re-importing it into the same location.

    The “$$com.sysprogs.bspoptions.primary_memory$$” error would appear if you select GCC on the first page of the Embedded Project Wizard, and then use the Keil toolchain instead (that does not provide this variable). Please do not do this. Instead, please make sure you select the same compiler type on both pages.

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.