Hi Jason,

I'd say you need to look for whatever may have changed between the moment it compiled and now.

Do you have any easy way to perform a diff? If you're using GIT, it should be relatively easy.

Did you upgrade any SDK element? In this case, try reverting this and let us know if you detect an issue with the latest releases.

Otherwise, consider any possible change in include folders and compilation options.

Regards,

Marc

Hi Kiran,

You can start with our example implementing an Http server. 

https://docs.silabs.com/wifi/wf200/content-source/getting-started/silabs/wgm160/getting-started#getting-started

And refer the the LWIP community to port HTTP client.

Thanks,

Ayoub,

Hi Kiran,

You can start with our example implementing an Http server. 

https://docs.silabs.com/wifi/wf200/content-source/getting-started/silabs/wgm160/getting-started#getting-started

And refer to the LWIP community to port HTTP client.

Thanks,

Ayoub,

Hi Fabian,

If you want to call sl_wfx_init() a second time, you need to issue a reset on the part first.

The WF(M)200 is in 'register mode' after reset, and switches to an API-controlled 'command mode' as soon as the FW is started.

sl_wfx_init() assumes that the part is in 'register mode', so needs a reset to put the part back in this state.

Regards,

Marc

Hi John,

Fine. Give it a try with 26MHz.

Note that, due to a limited set of clock dividers, the actual clock options you can use are limited. So, when setting 26 MHz you should get the maximum achievable value below or equal to 26 MHz. You can always  check the final value, as you've already done.

Regards,

Marc

John,

Some details on the various traces first:

SDIO detection is done using only SD_CLK / SD_CMD with a low speed, and only goes to full speed at the very end. This part is what is described in https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/01/03/linux_sdio_detection-ajSx, and you get those traces filtering with ''cmd_opcode != 53' (a trick to limit the traces to the detection phase)

One SDIO detection is done, the rest of the communication is using CMD53, so can be filtered using 'cmd_opcode == 53'.

So, both show traces before/after going to high speed mode as well as using SD_CMD/SD_CLK only or all SDIO pins, respectively.

Based on that, we see the SDIO detection, and the first SDIO 'high speed' transactions fail.

You mention you've bought WFM200 modules, so it can be HW related.

Are you using a radio board (BRD8023) or only the WFM200?

How is the SDIO connection between your WFM200 and the host processor?

The BRD8022/BDR8023 radio boards have a limitation is term of max SDIO speed due to some on-board switches use to allow SDIO/SPI compatibility.

Even without using a radio board, if you're hooked via jumper wires, 50MHz may be too high.

You should reduce the SDIO clock to 20 MHz as a first step, and you will look for the max speed once all startup issues are solved.

If I summarize your SDIO detection traces, I get (starting from CMD0):

So, it ends up in error. It would be interesting to check if the first failing CMD52 is the one corresponding to the switch from low to high-speed.

To check this, you should trace mmc_request_start as well. to allow checking the command bytes.

Given the point where the first errors occur, reducing the clock speed will be faster to conclude that you're suffering from a clock speed issue, if if works.

Regards,

Marc

John,

Some details on the various traces first:

SDIO detection is done using only SD_CLK / SD_CMD with a low speed, and only goes to full speed at the very end. This part is what is described in https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/01/03/linux_sdio_detection-ajSx, and you get those traces filtering with ''cmd_opcode != 53' (a trick to limit the traces to the detection phase)

One SDIO detection is done, the rest of the communication is using CMD53, so can be filtered using 'cmd_opcode == 53'.

So, both show traces before/after going to high speed mode as well as using SD_CMD/SD_CLK only or all SDIO pins, respectively.

Based on that, we see the SDIO detection, and the first SDIO 'high speed' transactions fail.

You mention you've bought WFM200 modules, so it can be HW related.

Are you using a radio board (BRD8023) or only the WFM200?

How is the SDIO connection between your WFM200 and the host processor?

The BRD8022/BDR8023 radio boards have a limitation is term of max SDIO speed due to some on-board switches use to allow SDIO/SPI compatibility.

Even without using a radio board, if you're hooked via jumper wires, 50MHz may be too high.

You should reduce the SDIO clock to 20 MHz as a first step, and you will look for the max speed once all startup issues are solved.

If I summarize your SDIO detection traces, I get (starting from CMD0):

So, it ends up in error. It would be interesting to check if the first failing CMD52 is the one corresponding to the switch from low to high-speed.

To check this, you should trace mmc_request_start as well, to allow checking the command bytes.

Given the point where the first errors occur, reducing the clock speed will be faster to conclude that you're suffering from a clock speed issue, if if works.

Regards,

Marc

John,

So, you've got the "WF200_ASIC_WFM_(Jenkins)_FW3.11.1" message, which means you've solved many issues already, including SDIO detection, chip init and FW loading. This string comes directly from the firmware while running in command mode at full speed, so it's very good news.

At that point I think it would be useful to trace HIF messages, as indicated in https://github.com/SiliconLabs/wfx-linux-driver/blob/master/README.md#how-to-trace-events.

Note that to trace SDIO messages you need to unbind/bind the mmc bus, as discussed in https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/01/03/linux_sdio_detection-ajSx, but you should NOT filter for 'cmd_opcode != 53' but rather 'cmd_opcode == 53'. This is because all 'command mode' SDIO messages use CMD53.

You need to check at which point (i.e., following which call) you get the 'time out while polling control register'.

Getting it on the very first time we're polling is different from getting it later on, once it already worked several times.

The value you read is also important. Getting all 0x00 or 0xFF is different from getting any other value.

Regards,

Marc

Hi John,

I can only stress the importance of the following paragraph from https://www.silabs.com/community/wireless/wi-fi/knowledge-base.entry.html/2019/01/03/linux_sdio_detection-ajSx:

Do you get this message?

Regards,

Marc

Although, the Radio Configurator supports 4FSK modulation, the sync word is 2FSK by default and in the GUI interface it is not possible change this parameter currently.

However, 4FSK sync word option is available by editing the generated project files.

The following steps shows how to set the sync word to 4FSK:

• Open an example or create a new Flex project
• Set the required parameters in the Application Builder
• Click on “Generate” button and allow the Simplicity Studio to generate the necessary files
• If the generation was successful, open the project’s rail_config.h file in the project’s root directory.
• In const uint32_t generated[] = {} configuration array find address /* 605C */ and set bit 12 to “1”
• Save the modified file and continue with compilation as usual

Note: The address is valid for EFR32xG12/13/14. For EFR32xG1 the address is 603C.

Exampe:

const uint32_t generated[] = {
  0x01040FF0UL, (uint32_t) generated_phyInfo,
     /* 0FF4 */ 0x00000000UL,
     /* 0FF8 */ 0x0003C000UL,
     /* 0FFC */ 0x0003C00FUL,
  0x00020004UL, 0x00000000UL,
     /* 0008 */ 0x00000000UL,
  0x00020018UL, 0x0000000FUL,
     /* 001C */ 0x00000000UL,
  0x00070028UL, 0x00000000UL,
       .
       .
       .
     /* 6058 */ 0x000004CDUL,
     /* 605C */ 0x22140A04UL, /* Change this value from 0x22140A04UL to 0x22141A04UL */
     /* 6060 */ 0x504B4133UL,
  0x00037014UL, 0x000270F8UL,
     /* 7074 */ 0x00000433UL,
     /* 7078 */ 0x00552300UL,
       .
       .
       .
  0xFFFFFFFFUL,
};

Keep in mind, if tweaking rail_config.c (or other auto-generated files) manually, then changes will be overwritten on the next re-generation of files.