- During scanning, the web browser reported error message "Command failed, connection to development board was lost".
This is not a bug because when you click the "OK" button in the message box, it will continue to work correctly. Above timeout error message happens when you choose to scan ALL channels. If you elect to scan only 2-3 channels, the scan duration will be much faster and the web browser is unlikely to timeout.
A possible solution is to increase the timeout setting in mchp.js
Eg \EasyConfigWebPages\javascript\mchp.js
var timeOutMS = 5000; //ms
- Scan results seem to display 1 SSID less. For example, there are 10 scan results but only 9 scan results are displayed.
If the scan result yields 10 scan results, our MRF24W + PIC development board will send 10 scan results to the webpage. However, the webpage will display only 9 scan results and drop its own SSID (scan result). As an example, the development board and laptop are using an AP named "test", then the webpage will not display SSID "test" among the displayed scan results.
- Why is my device not displaying MRF24WG0M softAP SSID in the scan results?
There are 2 possible reasons.
(a) Hidden SSID
(b) The device is only supporting active scan. MRF24WG0M RF module FW version 0x3107 only supports softAP with passive scan. From MRF24WG0M RF module FW version 0x3108 and future releases, softAP supports both active and passive scan. Check that your MRF24WG0M RF module FW version is 0x3108 and later.
- How can the received signal strength indicator (RSSI) be obtained from the MRF24W?
RSSI can only be obtained from the scan results p_scanResult->rssi. Refer to function prototype WF_ScanGetResult(). MRF24W checks out the signal strength from the preamble of the incoming packets. The higher the values, the stronger is the received signal strength.
MRF24WB : RSSI_MAX (200) , RSSI_MIN (106).
MRF24WG : RSSI_MAX (128) , RSSI_MIN (43).
The RSSI value is not directly translated to dbm because this is not calibrated number. However, as a guideline, MAX(200) corresponds to 0 dbm, MIN (106) corresponds to -94 dbm.
- Why is MRF24W failing after chip reset?
It is discovered that glitches on the MRF24W reset line. that is occurring after ChipReset(), could potentially cause MRF24W to fail.
The root cause is traced to the macros WF_SetCE_N and WF_SetRST_N, where the pin is configured as output first and then the level is set. The correct sequences should be to set the level first and then configure the pin as output.
#define WF_SetCE_N(level)
/* set pin to desired level */
WF_HIBERNATE_IO = level;
/* configure I/O as ouput */
WF_HIBERNATE_TRIS = 0
#define WF_SetRST_N(level)
/* set pin to desired level */
WF_RESET_IO = level;
/* configure the I/O as an output */
WF_RESET_TRIS = 0
The above changes apply to both MRF24WB0M and MRF24WG0M.
Refer to MLA v5.42.04 for the changes in the file WFDriverPrv_24G.h (MRF24WG0M)
Refer to MLA v5.42.08 for the changes in the file WFDriverPrv.h (MRF24WB0M)
- Why is the software hanging in infinite loop within WaitForMgmtResponse() function ?
For MLA v5.41 2012-02-15 and earlier versions, it is possible to be caught in an infinite loop. This could be caused by a race condition where a data message comes in before a mgmt response. Thus the workaround solution is to throw away a data message that comes in while waiting for a mgmt response.
This workaround is implemented in MLA v5.41.02 2012-04-03 and future versions.
The work-around is to change the while loop code to:
while (gMgmtConfirmMsgReceived == FALSE) {
WFProcess();
/* if received a data packet while waiting for mgmt packet */
if (g_HostRAWDataPacketReceived) {
// throw away the data rx
RawMountRxBuffer();
DeallocateDataRxBuffer();
g_HostRAWDataPacketReceived = FALSE;
/* ensure interrupts enabled */
WF_EintEnable(); }}