GregKell
commented
1 year ago Thank you for reaching out! In 2019 we sold the Bluetooth Low Energy Module portion of our business to u-bloxhttps://www.u-blox.com/en as we transition focus to our Enterprise IoT solutionhttps://www.rigado.com/cascade-edge-as-a-service/ - read the press release herehttps://www.rigado.com/press_releases/u-blox-acquired-rigados-bluetooth-modules-business/.
If you are having technical issues or have a question, please visit the u-blox Support Communityhttps://portal.u-blox.com/s/ and submit a ticket.
I have copied the u-blox team on this email and someone should be in touch shortly to answer your questions.
Ken Magee . Enterprise IoT Solutions . Rigado E: @.**@.> M: 503.341.3300 @.***
From: chatdeschroedinger @.> Sent: Monday, November 7, 2022 1:49 AM To: rigado/firmware @.> Cc: Subscribed @.***> Subject: [EXTERNAL] [rigado/firmware] Update of BL and Softdevice OTA (Issue #2)
Hi,
I have several devices with the RIGADO BMDWare on them but whose hardware is inaccessible. I want to initialize these nRF52832 chips with out nRF Bootloader, Softdevice and Application.
I have loaded the nRF Bootloader and Application as a RIGADO update package (generated with RIGADO genimage tools):
python genimage.py --hexfile bootloader.hex softdevice701.hex --output output.bin --bootloader --softdevice -f config/nrf52832-sd132v3.x.0.cfg
Then I upload the application (generated with command below) with nRF DFU which is working fine.
nrfutil pkg generate --hw-version 52 --app-boot-validation VALIDATE_GENERATED_CRC --sd-req 0xCB --application-version $(APP_FW_VER_HEX) --application app.hex --key-file priv.pem app.zipThe problem arises when I try to update the Bootloader (generated with below command) over the NRF DFU or over UART. In this case the Bootloader does not start at all bricking the device.
nrfutil pkg generate --hw-version 52 --sd-req 0xCB --bootloader-version $(BL_FW_VER_HEX) --bootloader bootloader.hex --sd-id 0xCB --key-file priv.pem Bootloader.zip
- when I read out the hex with the nRF programmer I can see differences in the MBR settings page and the Bootloader settings page (start at 0x7E0000 and 0x7F0000). However, the MBR should always stay intact, even over several softdevice versions.
My questions are:
- What could be the problem with this sequence of updates?
- Is this update procedure not supported or does the RIGADO BL even block updates of 'itself'?
- I am using a much newer Softdevice version (7.0.1) does this have an impact on the MBR settings?
— Reply to this email directly, view it on GitHubhttps://github.com/rigado/firmware/issues/2, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELLV2K2ECFPHS6IINBBQX3WHDGAJANCNFSM6AAAAAARY75CNE. You are receiving this because you are subscribed to this thread.Message ID: @.***>
ghost
chatdeschroedinger
torfinnberset
Hi,
I have several devices with the RIGADO BMDWare on them but whose hardware is inaccessible. I want to initialize these nRF52832 chips with out nRF Bootloader, Softdevice and Application.
I have loaded the nRF Bootloader and Application as a RIGADO update package (generated with RIGADO genimage tools):
python genimage.py --hexfile bootloader.hex softdevice701.hex --output output.bin --bootloader --softdevice -f config/nrf52832-sd132v3.x.0.cfgThen I upload the application (generated with command below) with nRF DFU which is working fine.
The problem arises when I try to update the Bootloader (generated with below command) over the NRF DFU or over UART. In this case the Bootloader does not start at all bricking the device.
My questions are: