Member | Action | Date |
---|---|---|
![]() |
Replied
to
Error: unknown type name 'sys_prot_t'; did you mean 'sys_mbox_t'?"
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 |
10 days ago |
![]() |
Selected an answer for
Do silicon labs provide http examples for WGM160P WiFi Module?
Hi Kiran, You can start with our example implementing an Http server. And refer the the LWIP community to port HTTP client. Thanks, Ayoub, |
14 days ago |
![]() |
Updated
to
Do silicon labs provide http examples for WGM160P WiFi Module?
Hi Kiran, You can start with our example implementing an Http server. And refer to the LWIP community to port HTTP client. Thanks, Ayoub, |
17 days ago |
![]() |
Replied
to
WFM200s fails to reinitialize after shutdown - check bootloader fails
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 |
20 days ago |
![]() |
Replied
to
WFM200S Software Questions
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
|
21 days ago |
![]() |
Replied
to
WFM200S Software Questions
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 |
22 days ago |
![]() |
Updated
to
WFM200S Software Questions
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 |
22 days ago |
![]() |
Replied
to
WFM200S Software Questions
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
|
26 days ago |
![]() |
Replied
to
WFM200S Software Questions
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 |
36 days ago |
![]() |
reopen
4GFSK Sync word on blog
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:
Note: The address is valid for EFR32xG12/13/14. For EFR32xG1 the address is 603C. Exampe:
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. |
53 days ago |