Reset Module

The radio can be reset through either hardware (reset pin) or software (SYS_RESET_REQ). When the radio is reset it transmits a SYS_RESET_IND message containing version information. This example will perform a hardware reset of the radio, parse the received data, and display the parsed fields.



First we initialize the hardware with halInit. Next we initialize the interface to the Module with moduleInit. This method does a few things:
 * Initialize the physical (PHY) interface to the Module, in our case SPI with halSpiInitModule.
 * Calls moduleReset which performs a hardware reset of the radio by asserting RESET_N (pulled low) for 1mSec and then deasserting it.
 * The Module will now perform its internal initialization and when done will output a SYS_RESET_IND message.
 * The moduleInit method will return a pointer to the beginning of the SYS_RESET_IND payload if you want to display it. In this example we display its contents.

Under the Hood
If using the UART interface, the Module sends the message out on its Tx pin. If using the SPI interface it is a little more complicated. In the code you'll see that moduleReset calls spiPoll to read the data. This method sends a poll (a poll is just an empty Synchronous Request Message) to the Module by doing the following in zm_phy_spi.c:
 * 1) After asserting RESET wait for SRDY to go low. Typically takes approximately 250mSec
 * 2) Asserting Chip Select & MRDY. Both are active low, meaning that we pull them LOW to assert.
 * 3) Send out via SPI a POLL message with spiWrite - a poll message is just three zeroes.
 * 4) Wait while SRDY is low. When it goes high it means the Module has data ready. Typical ~35mSec.
 * 5) Poll again using spiWrite, this time reading bytes in. This function is dual purpose, since it writes as well as reads. In this case we're using it to read bytes in. The first byte of any Module Synchronous Response Message (SRSP) is the length. We read the first byte (*zmBuf in the code) and read in that number of bytes into buffer zmBuf.

Typical values received are: Of course your values may be different. The SPI interface has been abstracted so if you are changing hardware you don't need to change the module_interface.c or zm_phy_spi.c methods, only spiWrite in the hal file.
 * TransportRev = 2
 * ProductID = 126
 * FW Revision = 2.4.1

For a more detailed look into how this works, see Reset Module Logic Analyzer Trace.

Asynchronous Request Messages
This example is a good demonstration of an Asynchronous Request (AREQ) message. Unlike a Synchronous Request Message, an AREQ message does NOT return a Synchronous Response (SRSP) message. Basically a SREQ is two-way communication with the module but an AREQ is one-way. There are only a few AREQ messages, almost everything uses a SREQ message.

Next Example: Get Version

Top: Module_Examples