Comments 14
Если что-то может пойти не так -- оно пойдёт :)
Спасибо, что поделились рецептом!
Весьма любопытный случай, спасибо!
в итоге он потерял возможность работы с Bluetooth, так как затёр код SoftDevice
А что, скачать его с сайта и залить снова уже нереально? Есть какие-то религиозные причины?
Познавательно, спасибо автору!
А есть какой-то смысл использовать в готовом устройстве Zephyr с этим сторонним загрузчиком всесто mcuboot?
Это не сторонний загрузчик. Это загрузчик, сделанный на базе штатного примера от NRF52. Который учитывает все особенности этого контроллера. Включая наличие того самого SoftDevice.
SoftDevice - это код библиотеки, обслуживающей радиомодуль и обеспечивающей работу стека BlueTooth. Все производители уносят его в заранее собранный двоичный код. Подозреваю (но не уверен на все 100%), что это делается, потому что в объектном файле всегда останутся какие-то метки и какие-то имена переменных, а так - всё точно будет скрыто от сторонних глаз. Однажды я читал высказывание на форуме, что без этого не получить сертификат на радиосовместимость. Все подкручивания должны быть скрыты от конечного пользователя. Снаружи должны быть доступны только стандартные номера каналов, и работа с ними должна идти по сертифицированным алгоритмам.
Поэтому при работе с Bluetooth контроллером NRF52, важно не затереть эту самую "приколоченную гвоздями" библиотеку. Для новых контроллеров, эту библиотеку обязательно надо "прошить" на требуемое место.
Собственно, та путаница с адресами вытекает как раз из того, что SoftDevcice новой версии стал больше, чем был в предыдущей. Адрес 0x27000 вбит в стандартную конфигурацию платы, которая прописана в свойствах Zephyr, установленного вместе со средой разработки NRF Connect. А сам HEX файл берётся с сайта производителя платы. Какой же он сторонний?
Да тут как минимум две причины чтобы закрывать
1) Коммерческо-лицензионная - Bluetoth-стэк стоит денег как в разработке так и за лицензии. Никому не захочется чтобы его скопировали и сделали дешевый аналог
2) Хакерская. Чем больше доступа к каналу тем больше возможностей для всяких шалостей. Хотя делают сейчас с Flipper Zero да и стэк ESP32 пропатчили
Обе эти истории уже проходили с NRF24 и повторять видать никто не хочет. С Zigbee в общем то та же история, стэк не то чтобы не доступен, но мало кто в него лезет.
Я о другом. Zephyr использует свою имплементацию BLE, без softdevice. Поэтому zephyr на NRF52 можно грузить вообще без загрузчика или используя родственный для zephyr MCUboot, что я в свое время и делал. Насколько я понял, вы хотите использовать Zephyr с загрузчиком от Adafruit. Вот и возникает вопрос, зачем?
Вообще, я первый раз услышал про то, что где-то дают возможность работать с радиомодулем без контроля со стороны злых производителей. Ведь тут такое дело. В одном месте увидишь запрет, в другом, а потом - начинаешь без глубоких проверок доверять.
Я так обрадовался Вашим словам, что полез гуглить... И похоже, нашёл ответ на вопрос "Что мешает?". Мешает то, что работа ведётся через NRF Connect. А про неё (и связанный с нею NRF Connect SDK) я нашёл сейчас вот такие гадости
bluetooth - Comparison Zephyr vs SoftDevice - Stack Overflow
Но буду очень рад, если Вы через ссылки или в режиме беседы позволите скинуть эти шоры. Я только рад, если этот SoftDevice станет не нужен. Но чтобы при этом не потерять других вкусностей от производителя. Вкусности - они же полезны.
Как сказано в начале статьи, я пока только осваиваю это дело. И буду рад любым ПРАВИЛЬНЫМ ссылкам. А то в море информации пока плавать приходится и опытным путём постигать, что полезно, а что - нет.
Я работал с Zephyr начиная с версии 1.5 и последняя которую щупал была 2.4. В процессе работы даже один патч им отправил. Zephyr для NRF52 компилируется вместе с вашим приложеним и БТ стеком в один бинарник. Можно без всяких MCUBOOT его загрузить в чип через SWD. При правильно сконфигурированной системе и board файлах это делается одной cli командой "west flash". В качестве программатора можно использовать j-link или st-link. Можно бинарник прошить через сторонние инструменты, я так тоже делал. Вот с полным стиранием залоченного чипа через ST-link сложнее, но тоже делается.
Можно сконфигурировать проект так, что он будет поддерживать MCU boot. Это дает два слота загрузки и возможность OTA обновлений. Документация, говорят, хорошая. Но так сложилась, что проект под NRF52 делал я, a MCUBOOT прикручивал уже другой человек, а на пет проектах я MCUBOOT не пробовал.
Начтнайте с https://docs.zephyrproject.org/latest/develop/getting_started/index.html
начинаю думать что проблема более широкая
вообще есть загрузчики как миниум от adafrut, родной nordic и еще от makedyary. вроде бы у плат у всех один и тот же , отличается только пин светодиода... но вот эти разные "коннстанты" могут затереть часть прошивки и только jtag в помощь
и еще приколы
если сделать erase all то встроенный цифровой стабилизатор питания будет вырабатывать напряжение 1.8В а не 3.3 (настройка в соотв. регистре по умолчанию). не все swd/jtag отладчики умеют работать с 1.8В
можно настроить подтяжки портов так что они подтянут reset (инвертированный к "0"). Чип будет в вечном reset. можно вытянуть его в "1" дополнительным источником питания
@EasyLy я тут еще покопался в этих вопросах и пришол к выводу что с Xiao еще повезло. У нее схемотехника предусматривает правильную подтяжку reset и питание всегда 3.3В. А в моем случае после fullerase (как бы тоже самое что и в статье, но плата у меня другая) я в общем то получил вообще полный отвал программатора - он ругался что не может подключиться, хотя что то видел. Понадобился программатор умеющий 1.8В Vref (J-LINK EDU вроде так и не может даже) и вешняя подтяжка reset
Почему может не работать отладка на плате XIAO BLE