|
Bolivar, Marti
Hi Mayank,
toggle quoted messageShow quoted text
I am surprised to say this doesn't appear to be covered in the MCUboot documentation. David, did I miss it somewhere? Mayank: you need at least three pins connecting the i.MX and nRF chips: - UART TX - UART RX - a "serial detect" GPIO The i.MX chip also needs to be able to reset the nRF chip, e.g. with another i.MX GPIO connected to the nRF reset pin. (If you have already manufactured your PCB and don't have those required features, then you're out of luck, I'm afraid. You'll have to use something like the smp_svr app.) You need to customize your MCUboot build for your board so the bootloader reads your serial detect pin at reset and drops into serial recovery mode if it is asserted. The mcumgr serial protocol is used to do the update itself. Assuming the mcuboot kconfig help is still accurate, you need to set your MCUboot Kconfig knobs roughly like so: CONFIG_MCUBOOT_SERIAL=y CONFIG_BOOT_SERIAL_UART=y CONFIG_BOOT_SERIAL_DETECT_PORT="GPIO_0" # or GPIO_1 if your pin is on that port CONFIG_BOOT_SERIAL_DETECT_PIN=<your-custom-board's-serial-detect-pin-number> CONFIG_BOOT_SERIAL_DETECT_PIN_VAL=<your-serial-detect-pin's-assert-logic-level> Also make sure your zephyr,console chosen node in devicetree is the nRF52840 UART you want to use, and that its TX/RX pins are set correctly in DT as well. Once configured in this way, you need to build and reflash MCUboot on the nRF. On the i.MX side, to do an update, you need to do something like this: 1. assert the serial detect pin 2. reset the nRF SoC 3. use the mcumgr serial transport protocol to upload an update firmware image 4. deassert the serial detect pin (this just needs to happen sometime after mcuboot has read it out of reset) 5. use mcumgr to reset the nRF with serial detect deasserted, to boot into the new image You may find the west build + west sign + mcumgr command lines on this page helpful: https://docs.zephyrproject.org/latest/boards/arm/nrf52840_pca10059/doc/index.html#option-2-using-mcuboot-in-serial-recovery-mode If you are running Linux and can get golang programs running on the i.MX, you should be able to get mcumgr running and adapt the 'mcumgr ... image upload' and 'mcumgr ... reset' lines from there. Hope this helps! "Mayank via Lists.Zephyrproject.Org" <mayank7117=gmail.com@lists.zephyrproject.org> writes:
Hello,
|
|||||||||||||||
|
|
|||||||||||||||
|
Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)
Bolivar, Marti
Sorry for the double-post, but I realized that the latter half of my
inline responses might be easy to ignore, so I'm going to hang a lantern on them with this email: "Bolivar, Marti via Lists.Zephyrproject.Org" <marti.bolivar=nordicsemi.no@lists.zephyrproject.org> writes: Please make sure you see this part ^^.From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Marc Reilly via Lists.Zephyrproject.Org <marc.reilly=gmail.com@lists.zephyrproject.org>No matter what you choose to use (mainline or NCS), though, you can Martí
|
|||||||||||||||
|
|
|||||||||||||||
|
Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)
Bolivar, Marti
Hello Marc,
"Sebastian Boe via Lists.Zephyrproject.Org" <Sebastian.Boe=nordicsemi.no@lists.zephyrproject.org> writes: Hi, I see you are using nrf.I second Sebastian's suggestion to look at nRF Connect SDK (NCS). It has useful features for building OTA binaries for nRF devices. No matter what you choose to use (mainline or NCS), though, you can always tell 'west build' your default board like this: west config build.board theboard https://docs.zephyrproject.org/latest/guides/west/build-flash-debug.html#configuration-options The build.board value will be used if you don't provide --board (provided BOARD is also unset in the calling environment). I thought about your BOARD_ROOT question. I've gotten other similar requests recently, and I agree it would be useful, so I've proposed a new "build.cmake-args" config option: https://github.com/zephyrproject-rtos/zephyr/pull/21251 With the patch from #21251, you can save your BOARD_ROOT like this: west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app Your one-time setup work would then be: west init -m git@gitlab.com/SomeManifestRepo.git west update west config build.board theboard west config build.cmake-args -- -DBOARD_ROOT=/abs/path/to/app Note that plain 'west config var val' sets configuration options locally (just for your west installation). See the --global and --system options in the 'west config' documentation for alternatives. # build and flash west build -d build-mcuboot -s mcuboot/boot/zephyr west build -d build-app -s app west sign ... And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'.I hope the above is what you're looking for. Note 'west build' can only compile one Zephyr application at a time. The NCS can build application and mcuboot binaries at once out of the box, for reference. Please test and comment in the PR if you get a chance. Thanks, Martí
|
|||||||||||||||
|
|
|||||||||||||||
|
Re: Managing/structuring multi image/binary projects for (OTA updatable products etc)
Sebastian Boe
Hi, I see you are using nrf.
Signing, building, and hex merging of multiple images in a single west command is supported out-of-the box with the nRF Connect SDK, which uses a patched Zephyr. So if not using vanilla Zephyr is an option then see: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/http_application_update/README.html#http-application-update-sample https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_multi_image.html ________________________________________ From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Marc Reilly via Lists.Zephyrproject.Org <marc.reilly=gmail.com@lists.zephyrproject.org> Sent: Monday, December 9, 2019 4:38 PM To: devel@lists.zephyrproject.org Cc: devel@lists.zephyrproject.org Subject: [Zephyr-devel] Managing/structuring multi image/binary projects for (OTA updatable products etc) Hi all, I've been looking at making product(s) which can do OTA updates, and how to structure the overall project. A basic aim is to be able to checkout and build (assuming toolchain and environment is setup) with minimal commands, and also minimal manual 'configuration' changes required for a default build. I'm not really feeling like I'm seeing a nice solution, so was wondering if anyone else has overcome a similar situation, or anyone has any ideas to progress. Following, I've tried to summarize the problem & design as I see it to make sure I'm on the right track, and then I've got a few example commands to further illustrate where the problem is for me. Any and all suggestions welcome. Cheers, Marc ----- Overview: The product acheives OTA updates, at a general level, by: - use mcuboot as the bootloader - app implements SMP service (eg mcumgr/smp_svr example) - initially program the product with a combination of the mcuboot + app - further updates can be done OTA, the app handles transmission and copying of the new firmware image to a partition on flash, then resets. the bootloader checks the new firmware image does some partition 'accounting' and then boots the new image. Typical project elements/dependencies: - app for the product/device - board files are defined in the 'app' repo - common libs (eg for our GATT services which most our devices have) - zephyr framework - dependent modules (eg nordic_hal, segger) - mcuboot - (references the app board file) This resembles either the T2 or T3 of west's documented tolopogies. [https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#topologies-supported] Build: - We want 2 primary build artifacts: - the app (configured as launched from a bootloader) - bootloader mcuboot - And then from this with can run a variety of commands to merge and/or sign the build artifacts. - As a bonus, perhaps another app configuration to make dev/debug easier where the bootloader is not used. ----- West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example: west init -m git@gitlab.com:SomeManifestRepo.git west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app west sign ... However, it would be nice to be able to glue this all together with some script etc to simplify the extra elements of the west commands ('theboard' 'BOARD_ROOT') etc. And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'. Alternatives: - copy 'glue' script into west installation folder ? - west commands ? in the manifest repo, or maybe another common lib etc.
|
|||||||||||||||
|
|
|||||||||||||||
|
Managing/structuring multi image/binary projects for (OTA updatable products etc)
Marc Reilly
Hi all,
I've been looking at making product(s) which can do OTA updates, and how to structure the overall project. A basic aim is to be able to checkout and build (assuming toolchain and environment is setup) with minimal commands, and also minimal manual 'configuration' changes required for a default build. I'm not really feeling like I'm seeing a nice solution, so was wondering if anyone else has overcome a similar situation, or anyone has any ideas to progress. Following, I've tried to summarize the problem & design as I see it to make sure I'm on the right track, and then I've got a few example commands to further illustrate where the problem is for me. Any and all suggestions welcome. Cheers, Marc ----- Overview: The product acheives OTA updates, at a general level, by: - use mcuboot as the bootloader - app implements SMP service (eg mcumgr/smp_svr example) - initially program the product with a combination of the mcuboot + app - further updates can be done OTA, the app handles transmission and copying of the new firmware image to a partition on flash, then resets. the bootloader checks the new firmware image does some partition 'accounting' and then boots the new image. Typical project elements/dependencies: - app for the product/device - board files are defined in the 'app' repo - common libs (eg for our GATT services which most our devices have) - zephyr framework - dependent modules (eg nordic_hal, segger) - mcuboot - (references the app board file) This resembles either the T2 or T3 of west's documented tolopogies. [https://docs.zephyrproject.org/latest/guides/west/repo-tool.html#topologies-supported] Build: - We want 2 primary build artifacts: - the app (configured as launched from a bootloader) - bootloader mcuboot - And then from this with can run a variety of commands to merge and/or sign the build artifacts. - As a bonus, perhaps another app configuration to make dev/debug easier where the bootloader is not used. ----- West seems like the ideal tool to use for this, it boils down to a manifest repo (for project & dependencies checkout), and then a series of commands to build the various artifacts and merge & sign them. For example: west init -m git@...:SomeManifestRepo.git west build --board=theboard -d build-mcuboot -s mcuboot/boot/zephyr -- -DBOARD_ROOT=/abs/path/to/app west build --board=theboard -d build-app -s app -- -DBOARD_ROOT=/abs/path/to/app west sign ... However, it would be nice to be able to glue this all together with some script etc to simplify the extra elements of the west commands ('theboard' 'BOARD_ROOT') etc. And here is where I become unsure of how this glue script/(c)makefile/etc fits into the topology of the project.. The natural place for the script to run from is the west installation folder itself (ie, the parent folder of all the subprojects) however the natural place for it to 'live' is in the 'manifest-repo'. Alternatives: - copy 'glue' script into west installation folder ? - west commands ? in the manifest repo, or maybe another common lib etc.
|
|||||||||||||||
|
|
|||||||||||||||
|
Mayank
Hello,
I have nrf52840_pca10056 chip connected to imx6ul processor via uart (Both are embedded on my custom board) as shown in attached image. I'm using mcuboot bootloader on nrf52840 chip, now i want to flash hci_uart app over UART by keeping mcuboot in serial recovery mode. NOTE: I do not want to go with other way of upgrading the firmware (Using smp_svr application). Q: So what i need to do to upgrade the firmware using bootloader's serial recovery mode ? (I do not have any physical access to the pin for nrf52840 chip).
|
|||||||||||||||
|
|
|||||||||||||||
|
Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 2 January 2020
#cal-cancelled
devel@lists.zephyrproject.org Calendar <devel@...>
Cancelled: Zephyr Project: Dev Meeting This event has been cancelled. When: Where: Organizer: devel@... Description:
|
|||||||||||||||
|
|
|||||||||||||||
|
Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 26 December 2019
#cal-cancelled
devel@lists.zephyrproject.org Calendar <devel@...>
Cancelled: Zephyr Project: Dev Meeting This event has been cancelled. When: Where: Organizer: devel@... Description:
|
|||||||||||||||
|
|
|||||||||||||||
|
Cancelled Event: Zephyr Project: Dev Meeting - Thursday, 19 December 2019
#cal-cancelled
devel@lists.zephyrproject.org Calendar <devel@...>
Cancelled: Zephyr Project: Dev Meeting This event has been cancelled. When: Where: Organizer: devel@... Description:
|
|||||||||||||||
|
|
|||||||||||||||
|
Zephyr 2.1 Released
David Leach
Hi,
Major enhancements with this release include (but are not limited to):
The detailed release notes can be found here: https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v2.1.0 I would like to thank the community members who contributed to this release. In total 219 contributors provided PRs in the development of 2.1 with a total of 350+ community members providing issues, PRs, and comments. It has taken a lot of hard work from everyone in the Zephyr community! Starting now, the tree is open for new features targeting 2.2 release, which is tentatively scheduled for February 28th 2020.
Thank you again,
David Leach
David Leach
NXP Semiconductors phone: +1.210.241.6761 Email: david.leach@...
|
|||||||||||||||
|
|
|||||||||||||||
|
libstdc++ / thread safety
Markus
Dear all,
as I can't find any extensions to GCC for Zephyr, I am wondering if C++ / strings can already be used safely on Zephyr? Please have a look at the "Porting to New Hardware or Operating Systems" section of libstdc++ https://gcc.gnu.org/onlinedocs/libstdc++/manual/internals.html#internals.thread_safety Best Regards Markus
|
|||||||||||||||
|
|
|||||||||||||||
|
Re: bt_gatt_is_subscribed - any examples?
From: users@... <users@...>
On Behalf Of Lawrence King
Sent: Thursday, December 5, 2019 4:00 PM To: users@... Subject: [Zephyr-users] bt_gatt_is_subscribed - any examples?
Dear All:
I have a similar problem to what Frank Viren is seeing in his thread “bt_gatt_notify multiple characteristics”. How to determine the pointer to the right characteristic.
When my central connects to my device I want to send it several notifications. My device has several characteristics under the primary service. When the central connects (in this case the central is either an iPhone, or an Android phone), if I simply wait 200mS after the connection and sent the notifications with bt_gatt_notify() it ‘almost’ always works. Unfortunately sometimes Android or iOS take a little longer to subscribe for notifications, hence I would like to determine if the phone is ready to receive notifications rather than simply waiting 200mS.
I hunted through the bt_ apis and found bt_gatt_is_subscribed() which looks like I can loop testing to see if the central is ready and then send the notifications. Much better than blindly waiting 200mS.
bool Check if connection have subscribed to attribute. Check if connection has subscribed to attribute value change. The attribute object can be the so called Characteristic Declaration, which is usually declared with BT_GATT_CHARACTERISTIC followed by BT_GATT_CCC, or the Characteristic Value Declaration which is automatically created after the Characteristic Declaration when using BT_GATT_CHARACTERISTIC, or the Client Characteristic Configuration Descriptor (CCCD) which is created by BT_GATT_CCC. Return true if the attribute object has been subscribed. Parameters · conn: Connection object. · attr: Attribute object. · ccc_value: The subscription type, either notifications or indications.
OK, based on the documentation, this seems to be what I want, but the parameters are difficult for a newbie to understand: conn – yes I did declare this with BT_GATT_CHARACTERISTIC I know where it is in my source code, but how do I find a pointer to it? attr – this was automatically created with BT_GATT_CCC in the same place, but again how do I get a pointer to the attr? ccc_value – this is obviously an int, probably with definitions for the bits, but what symbolic enums or defines can I put in this parameter?
Unfortunately a google search of “bt_gatt_is_subscribed” only finds 8 results, the source code, the documentation (on the zephyr site, and on the nordic site), and 2 content aggregators. I did not find a single piece of code that calls this function, but there must be at least one call to the function in at least some test suite. bt_gatt_is_subscribed is never called in any of the zephyr/samples…
Can someone point me to an example please?
Lawrence King Principal Developer Connected Transport Market Unit +1(416)627-7302
CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.
|
|||||||||||||||
|
|
|||||||||||||||
|
LPC55S28JBD100 Zephyr OS
Wu, Hubert <Hubert.Wu@...>
|
|||||||||||||||
|
|
|||||||||||||||
|
frv
Hi Carles,
Thanks for the tip. I would be really surprised that I already have a stack issue, as the application is still very simple... Nevertheless it can't harm to have this option enabled. Br, Frank
|
|||||||||||||||
|
|
|||||||||||||||
|
Carles Cufi
Hi there,
One of the likely culprits is stack sizing. Please enable CONFIG_HW_STACK_PROTECTION and verify that one of your stacks is not overflowing.
Regards,
Carles
From: devel@... <devel@...>
On Behalf Of frv via Lists.Zephyrproject.Org
Sent: 06 December 2019 13:38 To: devel@... Cc: devel@... Subject: [Zephyr-devel] Persistent memory issue (NVS and FCB) - Zephyr V1.X versus V2 #ble #nrf52
Hi all, CONFIG_BT_SETTINGS=y CONFIG_FLASH=y CONFIG_FLASH_PAGE_LAYOUT=y CONFIG_FLASH_MAP=y CONFIG_FCB=y CONFIG_SETTINGS=y CONFIG_SETTINGS_FCB=y
CONFIG_BT_KEYS_OVERWRITE_OLDEST=y CONFIG_BT_SETTINGS=y CONFIG_FLASH=y CONFIG_FLASH_PAGE_LAYOUT=y CONFIG_FLASH_MAP=y CONFIG_NVS=y CONFIG_SETTINGS=y
CONFIG_FCB=y CONFIG_SETTINGS_FCB=y
|
|||||||||||||||
|
|
|||||||||||||||
|
frv
Hi all,
I have the following setup: - nrf52 demo kit running a simple BLE peripheral application - Raspberry Pi running a BLE central application A secured connection is made (authentication based on fixed passkey) and paired information is made persistent (bonded). I set in the peripheral's prj.conf file the following options: CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FCB=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_FCB=y
In V1.X this sometimes resulted in system crash when restarting the peripheral or when the connection was broken en reconnected for paired devices When I built my project in V2.X with these options, I get ALWAYS a OS usage FAULT, Illegal load of EXC_RETURN into PC and results further in a FATAL ERROR and halts the system. However when I use these options in V2.X: CONFIG_BT_KEYS_OVERWRITE_OLDEST=y
CONFIG_BT_SETTINGS=y
CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
no more system crash. I'm wondering if the issue is related to Flash Circular Buffer support (https://docs.zephyrproject.org/1.13.0/reference/kconfig/CONFIG_FCB.html) CONFIG_FCB=y
CONFIG_SETTINGS_FCB=y In the peripheral sample applic distributed with V2.X CONFIG_SETTINGS_FCB is replaced by CONFIG_NVS Best regards, Frank
|
|||||||||||||||
|
|
|||||||||||||||
|
Re: bt_gatt_notify multiple characteristics - always notification for the first characteristic
#ble
Hi all,
Solved... It looks like when BT_GATT_CCC is set in the service MACRO define, it takes not 1 but 2 indices to advance as also there is automatically a descriptor char added if you need to access the second attribute. Best regards, Frank
|
|||||||||||||||
|
|
|||||||||||||||
|
Cancelled Event: Zephyr Project: APIs - Tuesday, 31 December 2019
#cal-cancelled
devel@lists.zephyrproject.org Calendar <devel@...>
Cancelled: Zephyr Project: APIs This event has been cancelled. When: Where: Organizer: devel@... Description: Live meeting minutes: https://docs.google.com/
|
|||||||||||||||
|
|
|||||||||||||||
|
Cancelled Event: Zephyr Project: APIs - Tuesday, 24 December 2019
#cal-cancelled
devel@lists.zephyrproject.org Calendar <devel@...>
Cancelled: Zephyr Project: APIs This event has been cancelled. When: Where: Organizer: devel@... Description: Live meeting minutes: https://docs.google.com/
|
|||||||||||||||
|
|
|||||||||||||||
|
bt_gatt_notify multiple characteristics - always notification for the first characteristic
#ble
frv
Hi all,
I have a user defined BT GATT service with 2 user defined characteristics. The code is as simple as this for defining the GATT service. static struct bt_uuid_128 uuidButtonService = BT_UUID_INIT_128(
0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80,
0x00, 0x02, 0x00, 0x01, 0x01, 0x00, 0x00, 0x00);
static struct bt_uuid_128 uuidButtonStateCallStart = BT_UUID_INIT_128(
0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80,
0x00, 0x02, 0x00, 0x01, 0x02, 0x00, 0x00, 0x00);
static struct bt_uuid_128 uuidButtonStateCallStop = BT_UUID_INIT_128(
0xFB, 0x34, 0x9B, 0x5F, 0x80, 0x00, 0x00, 0x80,
0x00, 0x02, 0x00, 0x01, 0x03, 0x00, 0x00, 0x00);
BT_GATT_SERVICE_DEFINE(button_svc,
BT_GATT_PRIMARY_SERVICE(&uuidButtonService),
BT_GATT_CHARACTERISTIC(&uuidButtonStateCallStart, BT_GATT_CHRC_NOTIFY,
BT_GATT_PERM_NONE, NULL, NULL, NULL),
BT_GATT_CCC(buttonstate_ccc_cfg_changed, BT_GATT_PERM_READ | BT_GATT_PERM_WRITE),
BT_GATT_CHARACTERISTIC(&uuidButtonStateCallStop, BT_GATT_CHRC_NOTIFY,
BT_GATT_PERM_NONE, NULL, NULL, NULL),
BT_GATT_CCC(buttonstate_ccc_cfg_changed, BT_GATT_PERM_READ | BT_GATT_PERM_WRITE)
);
void button_notify(bool value, uint8_t buttonNbr)
{
printk("Button nbr %u - Notify value = %u\n", buttonNbr, value);
onOffFlag = value;
uint8_t index = 1;
if (buttonNbr == 0)
{
index = 1;
}
else
{
index = 2;
}
printk("--->index is %u\n", index);
bt_gatt_notify(NULL, &button_svc.attrs[index], &onOffFlag, sizeof(onOffFlag));
}
Nevertheless always the notification change of the first characteristic in the user defined service is trapped in the BT central application, despite the index value in button_svc.attrs changes between 1 and 2. I see in my central output that the service and its characteristics are well discovered. uuid service : 00000001-0100-0200-8000-00805f9b34fb uuid char1 : 00000002-0100-0200-8000-00805f9b34fb uuid char2 : 00000003-0100-0200-8000-00805f9b34fb Any idea's what I'm doing wrong? Thanks, Best regards, Frank
|
|||||||||||||||
|
|
