Только что проделал следующее:
1) На чистый компьютер с Win7 Pro установил Guardant SDK 6.1 - с сайта скачал для чистоты эксперимента
2) Установил последние версии YAGARTO Tools и YAGARTO GNU Toolchain с сайта http://www.yagarto.de/#download
3) Открыл наш самый наглядный пример C:\Program Files (x86)\Guardant\Guardant 6.1\DEMONVK\Samples\ARM\05 - LED Control\Loadable Code
Здесь загружаемый код заставляет ключ моргать с определенной периодичностью. Очень просто отследить работоспособность
4) Запустил команду make template, затем make all. Скомпилировалась пара файлов bin/bmap
5) Загрузил bin в ключ, маска по умолчанию.
6) Все работает, при вызове GrdCodeRun ключ моргает, никаких ошибок на всем пути.

Доброго времени суток.
Сделал как написано, только с Guardant SDK 6.31.
Бинарник получился, led_control.gcexe получился, и он даже загружается и вроде как выполняется, о чем свидетельствует лог из NetBeans'a 7.4:
Working Directory = D:\Guardant\GuardTest\GuardantDongleTest
Loading led_control.gcexe: No errors
Loading GCEXE File to Dongle: No errors
Run Code LED:No errors
Waiting... LED Control in process...
Press Enter to continue.

Однако при всём при этом никакая индикация на ключе не моргает. Как горел светодиод, так и горит.

P.S.: Ключ прошит файлом mask2.nsd, который лежит там же, где и примеры, т.е. в папке ..\Samples\ARM

Спасибо за обратную связь.

Ну вот вам ещё. Исправлено две проблемы:
1) Сообщение "cc1plus.exe: warning: command line option '-Wimplicit' is valid for C/ObjC but not for C++ [enabled by default]" при компиляции исходников на C++
2) Проблемы с компиляцией исходников, расположенных в нескольких каталогах.

Сравнение файлов Makefile.code и C:\PROGRAM FILES\GUARDANT\GUARDANT 6.1\5EC003K\SAMPLES\ARM\00 - TEMPLATE\LOADABLE CODE\MAKEFILE
***** Makefile.code
#JEF CFLAGS += -Wall -Wcast-align -Wcast-qual -Wimplicit 
CFLAGS += -Wall -Wcast-align -Wcast-qual
***** C:\PROGRAM FILES\GUARDANT\GUARDANT 6.1\5EC003K\SAMPLES\ARM\00 - TEMPLATE\LOADABLE CODE\MAKEFILE
CFLAGS += -Wall -Wcast-align -Wcast-qual -Wimplicit 
*****

***** Makefile.code
#JEF CONLYFLAGS += -Wmissing-prototypes -Wnested-externs 
CONLYFLAGS += -Wmissing-prototypes -Wnested-externs -Wimplicit 
***** C:\PROGRAM FILES\GUARDANT\GUARDANT 6.1\5EC003K\SAMPLES\ARM\00 - TEMPLATE\LOADABLE CODE\MAKEFILE
CONLYFLAGS += -Wmissing-prototypes -Wnested-externs 
*****

***** Makefile.code
OBJ0 = $(notdir $(OBJ))
#JEF OBJ1 = $(OBJ:.o=1.o)
OBJ1 = $(OBJ0:.o=1.o)
#JEF OBJ2 = $(OBJ:.o=2.o)
OBJ2 = $(OBJ0:.o=2.o)
***** C:\PROGRAM FILES\GUARDANT\GUARDANT 6.1\5EC003K\SAMPLES\ARM\00 - TEMPLATE\LOADABLE CODE\MAKEFILE
OBJ1 = $(OBJ:.o=1.o)
OBJ2 = $(OBJ:.o=2.o)
*****

***** Makefile.code
        @if [ -e ".obj/1" ]; then \
#JEF      $(CC1) -c $(ALL_CFLAGS1) $(CONLYFLAGS) $< -o .obj/$(@:.o=1.o) ; \
          $(CC1) -c $(ALL_CFLAGS1) $(CONLYFLAGS) $< -o .obj/$(@F:.o=1.o) ; \
        else \
#JEF      $(CC2) -c $(ALL_CFLAGS1) $(CONLYFLAGS) $< -o .obj/$(@:.o=1.o) ; \
          $(CC2) -c $(ALL_CFLAGS1) $(CONLYFLAGS) $< -o .obj/$(@F:.o=1.o) ; \
        fi;
#JEF    @if [ -e ".obj/2" ]; then $(CC2) -c $(ALL_CFLAGS2) $(CONLYFLAGS) $< -o .obj/$(@:.o=2.o) ; fi;
        @if [ -e ".obj/2" ]; then $(CC2) -c $(ALL_CFLAGS2) $(CONLYFLAGS) $< -o .obj/$(@F:.o=2.o) ; fi;

***** C:\PROGRAM FILES\GUARDANT\GUARDANT 6.1\5EC003K\SAMPLES\ARM\00 - TEMPLATE\LOADABLE CODE\MAKEFILE
        @if [ -e ".obj/1" ]; then \
          $(CC1) -c $(ALL_CFLAGS1) $(CONLYFLAGS) $< -o .obj/$(@:.o=1.o) ; \
        else \
          $(CC2) -c $(ALL_CFLAGS1) $(CONLYFLAGS) $< -o .obj/$(@:.o=1.o) ; \
        fi;
        @if [ -e ".obj/2" ]; then $(CC2) -c $(ALL_CFLAGS2) $(CONLYFLAGS) $< -o .obj/$(@:.o=2.o) ; fi;
*****

***** Makefile.code
        @if [ -e ".obj/1" ]; then \
#JEF      $(CPP1) -c $(ALL_CFLAGS1) $(CPPFLAGS) $< -o .obj/$(@:.o=1.o) ; \
          $(CPP1) -c $(ALL_CFLAGS1) $(CPPFLAGS) $< -o .obj/$(@F:.o=1.o) ; \
        else \
#JEF      $(CPP2) -c $(ALL_CFLAGS1) $(CPPFLAGS) $< -o .obj/$(@:.o=1.o) ; \
          $(CPP2) -c $(ALL_CFLAGS1) $(CPPFLAGS) $< -o .obj/$(@F:.o=1.o) ; \
        fi;
#JEF    @if [ -e ".obj/2" ]; then $(CPP2) -c $(ALL_CFLAGS2) $(CPPFLAGS) $< -o .obj/$(@:.o=2.o) ; fi;
        @if [ -e ".obj/2" ]; then $(CPP2) -c $(ALL_CFLAGS2) $(CPPFLAGS) $< -o .obj/$(@F:.o=2.o) ; fi;

***** C:\PROGRAM FILES\GUARDANT\GUARDANT 6.1\5EC003K\SAMPLES\ARM\00 - TEMPLATE\LOADABLE CODE\MAKEFILE
        @if [ -e ".obj/1" ]; then \
          $(CPP1) -c $(ALL_CFLAGS1) $(CPPFLAGS) $< -o .obj/$(@:.o=1.o) ; \
        else \
          $(CPP2) -c $(ALL_CFLAGS1) $(CPPFLAGS) $< -o .obj/$(@:.o=1.o) ; \
        fi;
        @if [ -e ".obj/2" ]; then $(CPP2) -c $(ALL_CFLAGS2) $(CPPFLAGS) $< -o .obj/$(@:.o=2.o) ; fi;
*****

***** Makefile.code
        @if [ -e ".obj/1" ]; then \
#JEF      $(CC1) -c $(ALL_ASFLAGS1) $< -o .obj/$(@:.o=1.o) ; \
          $(CC1) -c $(ALL_ASFLAGS1) $< -o .obj/$(@F:.o=1.o) ; \
        else \
#JEF      $(CC2) -c $(ALL_ASFLAGS1) $< -o .obj/$(@:.o=1.o) ; \
          $(CC2) -c $(ALL_ASFLAGS1) $< -o .obj/$(@F:.o=1.o) ; \
        fi;
#JEF    @if [ -e ".obj/2" ]; then $(CC2) -c $(ALL_ASFLAGS2) $< -o .obj/$(@:.o=1.o) ; fi;
        @if [ -e ".obj/2" ]; then $(CC2) -c $(ALL_ASFLAGS2) $< -o .obj/$(@F:.o=1.o) ; fi;
***** C:\PROGRAM FILES\GUARDANT\GUARDANT 6.1\5EC003K\SAMPLES\ARM\00 - TEMPLATE\LOADABLE CODE\MAKEFILE
        @if [ -e ".obj/1" ]; then \
          $(CC1) -c $(ALL_ASFLAGS1) $< -o .obj/$(@:.o=1.o) ; \
        else \
          $(CC2) -c $(ALL_ASFLAGS1) $< -o .obj/$(@:.o=1.o) ; \
        fi;
        @if [ -e ".obj/2" ]; then $(CC2) -c $(ALL_ASFLAGS2) $< -o .obj/$(@:.o=1.o) ; fi;
*****

Путем экспериментов выясняется, что команды отдавались CMD.exe вместо SH.exe. А причина простая - не надо было кавычки в PATH ставить. Не понимает их MAKE. И SHELL не понимает. И MAKESHELL не понимает.
3 дня коту под хвост :-(

Спасибо за обратную связь.

Спасибо Вам за мощную обратную связь.

Ну вот вам ещё хинт.

В итоге получаем

Путем экспериментов выясняется, что команды отдавались CMD.exe вместо SH.exe. А причина простая - не надо было кавычки в PATH ставить. Не понимает их MAKE. И SHELL не понимает. И MAKESHELL не понимает.

3 дня коту под хвост :-(

Информация в данной ветке, особенно найденная Phaza7 нам очень поможет в этом деле.

Мы постараемся придумать, как отблагодарить Вас за помощь и такое глубокое вникание в наши технологии (особенно учитывая что в данном случае оно далеко от беспроблемного).

Как оказалось, разработчики были не при чём, makefile отрабатывают хорошо. Единственная вина разработчиков в том, что они оставляют нас один на один с проблемой отсутствия yagarto-tools. На указываемом в документации сайте его уже нет. Мне кажется, было бы правильно выкладывать на сайте в разделе загрузок как инсталлятор библиотек и компиляторов (yagarto), так и инсталлятор инструментальных утилит (yagarto-tools), с которыми примеры бы компилировались, а так же, как уже предлагалось, проверять их при выходе каждой новой версии комплекта разработчика. Не помню есть ли это в документации, но там должно быть обязательное указание на то, что эти оба инструментария должны устанавливаться в разные директории, не содержащие пробелов, например, c:\yagarto\ и c:\yagarto-tools\). Как раз установка в разные папки вылечило мою проблему в WinXP (странно, но заработало).

Проблема в Win8.1 x64 вылечилась пересборкой yagarto-tools. Опишу вкратце, что я сделал, может быть, кому пригодится. Я заменил все *.exe файлы, а так же msys-1.0.dll в папке c:\yagarto-tools\bin\ на их новые версии из http://www.mingw.org. Установил с сайта, скачал c помощью него нужные пакеты и вручную заменил файлы. Библиотеки libiconv2.dll и libintl3.dll можно удалить, они уже не нужны. Вместо них необходимо добавить все dll, на которые ссылаются *.exe и msys-1.0.dll. Для поиска недостающих dll файлов можно использовать http://www.dependencywalker.com. У меня получилось: msys-iconv-2.dll, msys-intl-8.dll, msys-regex-1.dll и msys-termcap-0.dll.

Дополнительно, будем выкладывать рабочие сборки YAGARTO на нашем сайте вместе с SDK и записывать на диск в комплекте разработчика.

Не смог найти рабочие сборки на вашем сайте и на своём CD диске (полученном от вас в декабре 2012 г.) тоже. А это необходимо, т.к. с сайта http://www.yagarto.org/ их уже не скачать. Проект перешёл на SourceForge, но yagarto-tools там нет.

Нашёл в интернете ‘yagarto-tools-20121018-setup.exe’ и ‘yagarto-bu-2.22_gcc-4.7.2-c-c++_nl-1.20.0_gdb-7.5_eabi_20121013.exe’, установил их в ‘c:\YAGARTO\’. SDK установлено в директорию по умолчанию ‘c:\Program Files (x86)\Guardant\SDK 6.3\’. И ваши примеры загружаемого кода из SDK не компилируются.

На Windows 8.1 Pro x64 я получаю:

c:\Program Files (x86)\Guardant\SDK 6.3\XXX\Samples\ARM\00 - Template\Loadable Code>make all
-------- begin --------
--Check WinARM--
      0 [main] sh 5992 sync_with_child: child 8340(0x16C) died before initialization with status code 0xC0000142
    660 [main] sh 5992 sync_with_child: *** child state waiting for longjmp
/usr/bin/sh: fork: Resource temporarily unavailable
make: *** [prebuild] Error 128

На Windows XP SP3 x32 (всё установлено по тем же путям: ‘c:\YAGARTO\’ и ‘c:\Program Files\Guardant\SDK 6.3\’) получаю, как в теме https://forum.guardant.ru/post/1020/:

c:\Program Files\Guardant\SDK 6.3\XXX\Samples\ARM\00 - Template\Loadable Code>make all
-------- begin --------
--Check WinARM--
/usr/bin/sh: arm-elf-gcc: command not found
--Check Yagarto--
arm-none-eabi-gcc.exe: fatal error: no input files
compilation terminated.
Compiling: main.o main.c
arm-none-eabi-gcc.exe: fatal error: no input files
compilation terminated.
make: *** [main.o] Error 1

Make.exe точно вызывается из ‘c:\YAGARTO\bin\make.exe’, проверял, подставлял полный путь, в обоих случаях результат тот же.

В чём может быть беда? Проверьте сами, работает ли это сейчас. Обращаюсь к разработчикам, только не тяните, ответьте, как можно быстрее. Уже почти 3 недели ковыряю защиту и большую часть времени по вине ошибок в ваших утилитах и описании к ним.

1. Ссылка в документации на конкретную сборку YAGARTO дана некорректная, тем не менее последняя сборка с YAGARTO.DE отлично работает. Ссылки мы уберем, оставим только общую информацию.

Дополнительно, будем выкладывать рабочие сборки YAGARTO на нашем сайте вместе с SDK и записывать на диск в комплекте разработчика.

2. При установке нашего SDK по умолчанию и YAGARTO по рекомендованным в документации путям ВСЕ ПРИМЕРЫ КОМПИЛИРУЮТСЯ ИЗ КОРОБКИ, без правки makefile. Утверждать обратное некорректно.

3. Да, при переходе на новые ключи мы "подогнали" адреса RAM чтоб не путать клиентов и не вносить ненужные правки в GrdUtil (пришлось бы поддерживать две версии не только кода, но и дескриптора алгоритма в маске, что было неудобно нашим старым клиентам). Мы считаем что так банально удобнее. Жаль, если это производит впечатление работы школьника - это тем не менее работает.

4. Если в makefile использовать не относительные пути, а абсолютные, с пробелами, то их надо брать в кавычки! Например так:
CFG_SYS_DIR             = "C:\Program Files (x86)\Guardant\Guardant 6.1\DEMONVK\Bin"

5. Средства разработки пока только под Windows. Про Linux мы задумаемся при наличии соответствующего спроса :-).

Я благодарю участников Neekeetos и Jeevoy за обратную связь по продукту. Мы примем все это к сведению и попробуем упросить осовение продукта для новых клиентов и поправить непонятные моменты. Code является нашим самым сложным продуктом и самым продвинутым аппаратно - так что всегда приятно пообщаться с продвинутыми разработчиками.

Сейчас попробую проверить  - установить ваше ПО не по дефолтному пути.
Если ничего не указывать, то стоять оно будет в папке C:\Program Files\Guardant\Guardant 6.1\ИМЯ_КОНТРАКТА\
А значит пробелов по-минимуму два.

Yagarto про дефолту не ставится в ПФ, поэтому стоит на С в корне. Пробелов там нет.

Касательно пути установки Guardant - ограничений нет для примеров, если вы makefile не трогаете. Там пути указаны в относительном виде. YAGARTO должен быть по пути без пробелов.

Я установил наш SDK в папку по умолчанию...

Yagarto про дефолту не ставится в ПФ, поэтому стоит на С в корне. Пробелов там нет.

По представленной Вами информации я не могу понять в чем ошибка.

Только что проделал следующее:
1) На чистый компьютер с Win7 Pro установил Guardant SDK 6.1 - с сайта скачал для чистоты эксперимента
2) Установил последние версии YAGARTO Tools и YAGARTO GNU Toolchain с сайта http://www.yagarto.de/#download
3) Открыл наш самый наглядный пример C:\Program Files (x86)\Guardant\Guardant 6.1\DEMONVK\Samples\ARM\05 - LED Control\Loadable Code
Здесь загружаемый код заставляет ключ моргать с определенной периодичностью. Очень просто отследить работоспособность
4) Запустил команду make template, затем make all. Скомпилировалась пара файлов bin/bmap
5) Загрузил bin в ключ, маска по умолчанию.
6) Все работает, при вызове GrdCodeRun ключ моргает, никаких ошибок на всем пути.

Но ключ Code и вся инфраструктура GCC весьма сложные вещи, там все может слетать из за какого нибудь пробела в пути к файлу или подобной мелочи. Поэтому для локализации конкретно вашей ошибки нужно больше информации:
- версия SDK
- в какие папки на диске установлен SDK, Yagarto toolchain, Yagarto tools
- откуда и как запускаете make
- файл makefile
- полный вывод с команд make template и make all

Я сожалею что мы не ответили ранее, т.к. просто не заметили вопроса. Кривая освоения для Code в любом случае существует, ошибки неизбежны.

В итоге: map_parse отлично совместим с тулчейном, но небольшие правки makefile в зависимости от вашей инфраструктуры разработки это вполне нормальная вещь. Пишите подробности на hotline, разберемся.

внести в расписание и проверять хотябы с выпуском каждой новой версии сдк. Было бы меньше недопонимания.

+1

ещё раз +1

Во-первых хочу заверить Вас, что все сообщения о возможных ошибках makefile и сопутствующих утилит переданы соответствующим разработчикам. Мы обязательно разберемся со всеми проблемами, тем не менее хочу заверить Вас что в стандартной ситуации все наши примеры и makefile отрабатывают "на ура". Возможно обновились сборки тулчейнов, или возникла путаница в поколениях ключей или какой то неосознанный конфликт.

Или возможно никто не проверял даже изредка как работает то, что лежит в сдк, что, опять же, возможно, является вещью которую можно внести в расписание и проверять хотябы с выпуском каждой новой версии сдк. Было бы меньше недопонимания.

Я вас уверяю , все проблемы которые я нашел были связаны с использованием чисто yagarto без каких либо других установленых сред.

Но у вас спросили а вы поддержка, по большому счету то вы вообще ничего не обещали, даже работоспособность ключей, что теперь можно ничего не делать?

Я измерял времена работы SSL на ключе, и получилось парадоксальное соотношение,
допустим ключ без кода вообще тратит на передачу килобайта (на ключ и обратно)  60милисекунд, если работает ssl c AES-CBC/HMAC-SHA256  то это время увеличивается на 2 милисекунды, странно да?

Вот это отличная новость, думаю ключам Code именно этого и не хватает. В свою очередь могу описать несколько криптографических примитивов и безопасных протоколов, с тем чтобы разработчики не начинали на ровном месте.

Мне кажется он будет разумным,  поскольку сам микроконтроллер быстрый, и позволяет пропускать через ключ кучу данных, для защиты это плюс.

Я согласен, можно обходить препятствия, но ведь многие из них могли бы не существовать и тогда не пришлось бы "умело обходить", кроме того там не 20мс, 20 это для пустого запроса без передачи данных, более близкая к реальности цифра - порядка 100мс или 10 запросов в секунду для вызова кода, или порядка 40мс для вызова встроеных алгоритмов.