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.

Hi,

First of all, there are several (150+) TPMS protocols available that are not compatible with each other and those are proprietary protocols - so the specifications are not publicly available - thus, we don't have any sample codes for that.

Theoretically, EZR32HG320 is suitable for this purpose, it is capable to transmit/receive both 315MHz and 433MHz, both in FSK and ASK (actually not ASK, but OOK - but that's probably suitable), and the LF transmitter can be implemented in firmware (the built-in radio does not support that low frequency).

Additionally, you may want to check the EFR32 family, as it supports both sub GHz and 2.4GHz (BLE) so a standalone device could be used by communicating with the sensor at sub GHz and by any recent Android / iPhone mobile through Bluetooth Low Energy - thus, no USB connection to the phone is necessary.

So, to correctly answer your questions, we need more specific information.

BR,

/sza2

Hi,

In Connect, there is a callback (emberAfIncomingMessageCallback(EmberIncomingMessage *message)) which is fired when a message arrives. EmberIncomingMessage structure has a member named payload - which contains the message payload.

For more details about Connect stack see https://docs.silabs.com/connect-stack/latest/.

BR,

/sza2

Hi,

From Flex v2.0 Connect is only supported on EFR32 devices.

BR,

/sza2

Hi,

Did you check the documentation at https://docs.silabs.com/rail/latest/group-auto-ack?

BR,

/sza2