Getting Started with the 88W8801 on i.MX RT

[mjbcswitzerland]

Hi All

I have just received an embedded artist EAR00386 board with NXP WiFi module 88W8801.
Embedded Artists has patched the SDK so that there is a demo showing it in operation on their i.MX RT 1062 board - this builds, loads and runs.

However I don't find any information about how it is operating - for example, the wifi module's data sheets only give details about the SDIO interface's electrical specification.

Looking how the code starts I see that it first downloads a binary file to the interface (about 256k in size) - wlan_fw_bin[] in sd8801_wlan.h, which is the one for this particular module.
Later I see that it can send commands, like

#define HostCmd_CMD_MAC_CONTROL 0x0028

 (defined in mlan_fw.h)

Are there any details about the operation of the FW loaded and its interface apart from the SDK code base itself?

Regards

Mark

[mjbcswitzerland]

Hi All

I have seen that Murata also has tx power level configurations (wlan_txpwrlimit_cfg_murata_2DS_WW.h) on GITHUB: https://github.com/murata-wireless/nxp-freertos-calibration/blob/main/wlan_txpwrlimit_cfg_murata_2DS...
However these are not exactly the same as the one that is included in the NXP SDK. The headers are different and the NXP one is missing the channel 14 configuration. Is there are reason for removing it?

Regards

Mark

[mjbcswitzerland]

Hi All

I have had contact with Murata and they have told me to use the one on GITHUB and not the one in the SDK.
It is strange because the one on GITHUB is the one that has the NXP header and the one in the SDK has the Murata header - that means that NXP must be maintaining the one at GITHUB but using the Murata one (which Murata says NOT TO USE) in the SDK.....

I have therefore used the GITHUB one and removed the _WW at the end (it means World Wide) and just used some defines to allow it to adapt itself for Japanese, EU and USA versions (which are not included in the SDK but are on GITHUB).

Regards

Mark

[mjbcswitzerland]

I believe that there is a bug in the following code in wlan_enhanced_tests.c

#ifdef SD8801
        (void)PRINTF("  TX: \r\n");
        if (datarate->tx_data_rate < 12)
        {
            (void)PRINTF("    Type: %s\r\n", rate_format[0]);
            /* LG */
            (void)PRINTF("    Rate: %s\r\n", lg_rate[datarate->tx_data_rate]);
        }
        else
        {
            /* HT*/
            (void)PRINTF("    Type: %s\r\n", rate_format[1]);
            if (datarate->tx_bw <= 2)
                (void)PRINTF("    BW:   %s\r\n", bw[datarate->tx_bw]);
            if (datarate->tx_gi == 0)
                (void)PRINTF("    GI:   Long\r\n");
            else
                (void)PRINTF("    GI:   Short\r\n");
            (void)PRINTF("    MCS:  MCS %d\r\n", (int)(datarate->tx_data_rate - 12));
        }

It display the data rate returned by the module but when it is in HT mode it returns the values 0..7, but they display as slow LG values instead.

wlan-get-data-rate uap
Data Rate:
TX:
Type: LG
Rate: 18 Mbps


What is found is that the wifi module defaults to auto mode with a tx data rate of 2Mb/s in LG mode before being connected. When connected the speed is increases (negotiated I presume) to 65Mb/s in HT mode.

If the code is modified to not use the rate value (which will never be true for HT mode) but instead the mode it the displays MSC 7 with 20MHz bandwidth and long guard interval (65Mb/s) which is then as expected.

Regards

Mark

[mjbcswitzerland]

Finally I am working intensively on this and may have some remarks.

I'll start with what looks like a strange initialisation in the reference project:

        /* 3.3V voltage should be supported as default */
        ocr |= SDMMC_MASK(kSD_OcrVdd29_30Flag) | SDMMC_MASK(kSD_OcrVdd32_33Flag) | SDMMC_MASK(kSD_OcrVdd33_34Flag);

This is in SDIO_ProbeBusVoltage() in fsl_sdio.c.

I don't expect it really affects anything whether this is performed or not but if the range 2.9V..3.4V is to be set correctly it looks like it should also have additional flags set:

kSD_OcrVdd30_31Flag

kSD_OcrVdd31_32Flag

Regards

Mark

[mjbcswitzerland]

The following routine (in fsl_sdmmc_host.h) doesn't operate correctly.

/*!
 * @brief Send initilization active 80 clocks to card.
 * @Param host host handler
 */
static inline void SDMMCHOST_SendCardActive(sdmmchost_t *host)
{
    (void)USDHC_SetCardActive(host->hostController.base, 100U);
}

It commands 80 clocks to be sent and works if stepped though with the debugger.
However the 100 passed is a loop counter which causes it to not wait until the sequence has completed as it times out much too quickly. There are, in real operation, only about 10 clocks sent.

/*!
 * brief Sends 80 clocks to the card to set it to the active state.
 *
 * This function must be called each time the card is inserted to ensure that the card can receive the command
 * correctly.
 *
 * param base USDHC peripheral base address.
 * param timeout Timeout to initialize card.
 * retval true Set card active successfully.
 * retval false Set card active failed.
 */
bool USDHC_SetCardActive(USDHC_Type *base, uint32_t timeout)
{
    base->SYS_CTRL |= USDHC_SYS_CTRL_INITA_MASK;
    /* Delay some time to wait card become active state. */
    while (IS_USDHC_FLAG_SET(base->SYS_CTRL, USDHC_SYS_CTRL_INITA_MASK))
    {
        if (0UL == timeout)
        {
            break;
        }
        timeout--;
    }

    return ((0UL == timeout) ? false : true);
}

Since the timeout value is dependent on the processor speed it may have been Ok on slower processors but for the i.MX RT the timeout value needs to be increased to about 2000 to be on the safe side.

Regards

Mark

[mjbcswitzerland]

I am working on the Embedded Artists board and the reference project "eaimxrt1062_wifi_cli" always sets the SDHC bus to 1V8 operation.

However when CMD5 requests the device's capabilities it states that it doesn't support 1V8 mode of operation and the code doesn't activate it with the CMD11.

Therefore we are confused as to whether we should be using 3V3 or 1V8 bus levels, noting however that the reference HW and FW always uses 1V8 levels and seems to operate reliably.

What does NXP recommend? 1V8 or 3V3 signal levels???

[mjbcswitzerland]

In the function wlan_reconfigure_tx_buffers(), which is used to configure the tx buffers to 2kByte the tx_blocks value is set to 4 blocks:

static void wlan_reconfigure_tx_buffers(void)

{

t_u32 tx_blocks = 4, buflen = MLAN_SDIO_BLOCK_SIZE;

The actual object used to command [HostCmd_CMD_RECONFIGURE_TX_BUFF] this is in fact only 16 bytes in length but it sends 1k of data to transport it.
It looks like this is a copy paste issue from other functions used as base and the block count can be set to 1 instead [verified] (sending 4 doesn't hurt but is very probably not intended).

What I have also noticed is that all transmitted data is rounded up to the block length (256 bytes) so whenever data of less that 256 bytes is sent it is always sent as 256 (with some overhead).
I have modified this to use a byte length methods instead of always rounding up and it makes things more efficient. The startup time could be reduced by about 17% and I expect that data operations may be improved a bit too (when I get that far).

[DanielRuvalcaba]

Hi,

All the documentation regarding the wireless applications is available in your SDK bundle.
Please take a look to it in the following directory docs\wireless.

Regards,

Daniel.

[mjbcswitzerland]

Hello Daniel

Many thanks - the project import didn't add any wifi documents but I have found the folder in the SDK installation ZIP file.

However, apart from a high level guide to what the demonstrations do and an API document [WiFi driver reference manual] (which is generated by doxygen from the project code - and therefore doesn't add any more information than found in the code itself) I didn't find anything that describes how things actually work.

For example, the downloaded binary function is not mentioned anywhere (apart from the fact that it is loaded during the initialisation) and, using a reference command to set the MAC address the API describes the call as

whereas looking at the code involved gives further insight:

    (void)wlan_ops_sta_prepare_cmd((mlan_private *)mlan_adap->priv[0], HostCmd_CMD_802_11_MAC_ADDRESS, HostCmd_ACT_GEN_SET, 0, NULL, (uint8_t *)mac, cmd);

showing the use of a host command

#define HostCmd_CMD_802_11_MAC_ADDRESS 0x004D

to transfer it over the SDHC bus.

The details about this layer of interaction is what I am trying to locate (it must be defined by the downloaded binary, which must have been generated from its code, based on such a specification).

Regards

Mark

[DanielRuvalcaba]

Hi,

All the available documentation of the SDK can be found in the docs directory of you zip SDK bundle.

I'm afraid we don't have any guide or user manual that technically describes the process you mention.

In case you have a specific question regarding the firmware or download process, I can ask internally for help.

Regards,
Daniel.