Hi,

I'm not sure I understand your issue. Do you want and additional UART beside the UART used by Connect (APP_SERIAL) or just want to use UART2 instead of the default UART0?

It's not a good practice to init the serial port multiple times, but most of the time it should not cause a problem - but maybe, if there something already in the buffer and it hasn't been transmitted, lead to the issue as far as I remember.

There is a previous forum topic maybe you are interested in if your aim is to use multiple UARTs in Connect:
https://www.silabs.com/community/wireless/proprietary/forum.topic.html/uart_for_connectstack-uFg0

BR,

/sza2

Hi,

Could you please attach a reproducer code (project)?

Thanks,

/sza2

Hi,

Regarding key exchange, there is no even internal material/code for Connect. We plan to work on some example code that will be shared as KBA or in another form but unfortunately, I cannot promise any deadline for that.

Sorry for the inconvenience,

BR,

/sza2

Hi David,
 

About key exchange, we currently don't have any tutorial and no request happened to received for Connect so far - please give me some time to check how / if we could support this.

Regarding mbedTLS w/ Connect, did you tried to enable the mbedTLS plugin in the AppBuilder? Although mbedTLS is not the default setting currently but it should be supported already.

BR,

/sza2

Hi,

The API documentation available in HTML form only.

BR,

/sza2

Hi,

This seems to be I regression. I'll open an internal ticket for this. As a workaround, you can change the linker script in the C compiler settings opening the project properties - although, that will be reset on every "generate" unfortunately.

BR,

/sza2

Hi,

Several questions arose regarding the issue.

Do you use DMP in the project? schedInfo is only relevant for DMP, otherways you should pass NULL to RAIL_StartCcaCsmaTx() as the last parameter (although, this may not cause the issue).

Did you call RAIL_Init()? - It is necessary besides RAIL_IEEE802154_ConfigGB915MHzRadio().

What is the exact status value the function returns with? (the numerical value)

It would be preferable if you could attach the whole init/config/etc procedure to figure out what happens.

Edit: it would be even better, to send us a reproducer app - there are too many spots where RAIL_STATUS_INVALID_PARAMETER can be the return value in RAIL library.

BR,

/sza2

Hi,

Several questions arose regarding the issue.

Do you use DMP in the project? schedInfo is only relevant for DMP, otherways you should pass NULL to RAIL_StartCcaCsmaTx() as the last parameter (although, this may not cause the issue).

Did you call RAIL_Init()? - It is necessary besides RAIL_IEEE802154_ConfigGB915MHzRadio().

What is the exact status value the function returns with? (the numerical value)

It would be preferable if you could attach the whole init/config/etc procedure to figure out what happens.

BR,

/sza2

Introduction

The Connect stack supports OTA distribution of firmware images, both server, and client available as plugins. The usual method of uploading the image to the server device is to connect the J-Link adapter and upload the image the same way as in case of any other firmware images - which requires to stop the server device during the upload process and restart after the images are uploaded. However exploiting the capabilities of the Gecko bootloader, it is possible to upload images during normal operation. The following example implements an XMODEM protocol based uploader using built-in APIs.

Prerequisites

The described method and the provided method applicable for any Connect based application with any EFR32 device which supports Connect, this article uses Connect (SoC): Empty Example. This project also needs a properly configured Gecko bootloader which will provide the necessary API for the flash operations. In this example, we will use BRD4255A radio board. The user has to have a serial terminal emulator software that supports sending files using the XMODEM protocol.

Prepare the bootloader

There are multiple bootloaders available through the Simplicity Studio wizard - we need to use one which matches the flash memory size of the chosen device:

The default configuration of the bootloader is suitable for the current project, we only need to compile and upload to the device. Note: Gecko bootloader is a two stage bootloader always use the firmware image which contains -combined in its filename (bootloader-storage-internal-single-512k-combined.s37 in this case).

Prepare the application

Open the Connect (SoC): Empty Example through Simplicity Studio project wizard:

Select the Application bootloader in the AppBuilder on the HAL tab:

The complete example enables several plugins and options for working with CLI which are not detailed here as their description is out of the scope of this document, but the attached files configured properly. However, to be able to interact with the bootloader the following plugins should be enabled:

When the setting is done in AppBuilder and the files are generated, the next step is implementing the code in the flex-callbacks.c. Just as the settings in AppBuilder, the complete code is not described in this document, but further Connect documentation and resources can be found in Connect online documentation and Connect tutorial series.

The XMODEM protocol handling and the bootloader / flash memory related operations implemented in the xmodem-load-image.c and xmodem-load-image.h files (attached). These files should be added to the project (in the xmodem-load-image directory, but it can be placed anywhere but the header file must be in the include path).

The implementation contains only one public function: xmodemLoadImage(). This function handles both XMODEM upload and writing the incoming data chunks into the flash. The implementation follows the XMODEM protocol, but it does not support re-sending packets in case of failure. If any failure happens during upload, the whole process must be started from the beginning (including erasing the flash memory).

Completing the steps above, compile and run the firmware.

Note: do not use full erase on the device, just upload the application firmware, otherwise the bootloader may be erased as well.

Testing the application

If everything went well, a CLI interface should be available where the user can issue the necessary commands.

The first step is executing the flash initialization by issuing the command bootloader init. Initialization should be called once, when the application started / restarted, no subsequent initialization is necessary.

connect_xmodem_bootloader>bootloader init
bootloader init succeeded!

Then, if the image storage is not in the erased state, it must be erased by bootloader flash-erase:

connect_xmodem_bootloader>bootloader flash-erase
flash erasing slot 0 started
......................................................................................................................
flash erase successful!

Image storage always has to be erased before uploading an image. This means, if an upload was unsuccessful the erase command must be executed prior to any further uploads.

If the initialization was successful and the image storage is erased, the image upload can be started by the xmodem-load-image command. It has no parameters, as the image filename has to be specified at the host (PC) side and the end of the upload process (i.e. the length of the image) is determined by the host as well.

So, issue the xmodem-load-image command and select the file to upload.

If the upload was successful, the following messages should appear on the console:

connect_xmodem_bootloader>xmodem-load-image
CCCC
download successfully completed
connect_xmodem_bootloader>

The XMODEM uploader does not check if the uploaded image is valid. Issue the bootloader validate-image command validates the image:

connect_xmodem_bootloader>bootloader validate-image
Verifying image............................................................................................................................................................done!
Image is valid!

Conclusion

Although, the Connect does not support uploading OTA images from application directly, the way to implement is fairly easy and straightforward.

Introduction

The Connect stack supports OTA distribution of firmware images, both server, and client available as plugins. The usual method of uploading the image to the server device is to connect the J-Link adapter and upload the image the same way as in case of any other firmware images - which requires to stop the server device during the upload process and restart after the images are uploaded. However exploiting the capabilities of the Gecko bootloader, it is possible to upload images during normal operation. The following example implements an XMODEM protocol based uploader using built-in APIs.

Prerequisites

The described method and the provided method applicable for any Connect based application with any EFR32 device which supports Connect, this article uses Connect (SoC): Empty Example. This project also needs a properly configured Gecko bootloader which will provide the necessary API for the flash operations. In this example, we will use BRD4255A radio board. The user has to have a serial terminal emulator software that supports sending files using the XMODEM protocol.

Prepare the bootloader

There are multiple bootloaders available through the Simplicity Studio wizard - we need to use one which matches the flash memory size of the chosen device:

The default configuration of the bootloader is suitable for the current project, we only need to compile and upload to the device. Note: Gecko bootloader is a two stage bootloader always use the firmware image which contains -combined in its filename (bootloader-storage-internal-single-512k-combined.s37 in this case).

Prepare the application

Open the Connect (SoC): Empty Example through Simplicity Studio project wizard:

Select the Application bootloader in the AppBuilder on the HAL tab:

The complete example enables several plugins and options for working with CLI which are not detailed here as their description is out of the scope of this document, but the attached files configured properly. However, to be able to interact with the bootloader the following plugins should be enabled:

When the setting is done in AppBuilder and the files are generated, the next step is implementing the code in the flex-callbacks.c. Just as the settings in AppBuilder, the complete code is not described in this document, but further Connect documentation and resources can be found in Connect online documentation and Connect tutorial series.

The XMODEM protocol handling and the bootloader / flash memory related operations implemented in the xmodem-load-image.c and xmodem-load-image.h files (attached). These files should be added to the project (in the xmodem-load-image directory, but it can be placed anywhere but the header file must be in the include path).

The implementation contains only one public function: xmodemLoadImage(). This function handles both XMODEM upload and writing the incoming data chunks into the flash. The implementation follows the XMODEM protocol, but it does not support re-sending packets in case of failure. If any failure happens during upload, the whole process must be started from the beginning (including erasing the flash memory).

Completing the steps above, compile and run the firmware.

Note: do not use full erase on the device, just upload the application firmware, otherwise the bootloader may be erased as well.

Testing the application

If everything went well, a CLI interface should be available where the user can issue the necessary commands.

The first step is executing the flash initialization by issuing the command bootloader init. Initialization should be called once, when the application started / restarted, no subsequent initialization is necessary.

connect_xmodem_bootloader>bootloader init
bootloader init succeeded!

Then, if the image storage is not in the erased state, it must be erased by bootloader flash-erase:

connect_xmodem_bootloader>bootloader flash-erase
flash erasing slot 0 started
......................................................................................................................
flash erase successful!

Image storage always has to be erased before uploading an image. This means, if an upload was unsuccessful the erase command must be executed prior to any further uploads.

If the initialization was successful and the image storage is erased, the image upload can be started by the xmodem-load-image command. It has no parameters, as the image filename has to be specified at the host (PC) side and the end of the upload process (i.e. the length of the image) is determined by the host as well.

So, issue the xmodem-load-image command and select the file to upload.

If the upload was successful, the following messages should appear on the console:

connect_xmodem_bootloader>xmodem-load-image
CCCC
download successfully completed
connect_xmodem_bootloader>

The XMODEM uploader does not check if the uploaded image is valid. Issue the bootloader validate-image command validates the image:

connect_xmodem_bootloader>bootloader validate-image
Verifying image............................................................................................................................................................done!
Image is valid!

Conclusion

Although, the Connect does not support uploading OTA images from application directly, the way to implement is fairly easy and straightforward.