I plan to use the WF121 module in a new device to transfer information via UART from the device FIFO memory to the Windows application.
WF121 does not support wifi-direct.
Can I create a connection between my device and a laptop with WiFi direct in the area without WiFi coverage, i.e, without using a router?
Is there any way to force a MIME type for files served by the WGM110's internal HTTP server? It seems to recognize only a small number of file types. It's unable to serve WOFF or WOFF2 font files to Firefox (and also IE, I believe) because it defaults to a type of text/plain. If I switch to serving it via BGAPI, where my host code can set the MIME type appropriately, it works fine. It's not really an acceptable fix in this case, though - I need all of the static resources to be served by the module.
I think the LwIP webserver used by the WGM110 has an option to provide headers included in the files. If there was an option to turn that on, that would be sufficient. Or if there was an XML tag for project.xml to include a MIME type for a file, that would work too.
At the very least, if someone can tell me the checksum method used for the firmware image, it looks like I might be able to patch it to replace the .class entry that I'm not using with .woff.
I'm developing a new product that are using WF121 controlled by an external MCU through API protocol and I'm using Wifi and Ethernet functions without any problem.
I'm also including now an USB connector connected to USB interface from WF121 to be used as a USB cdc (virtual COM).
I was looking for examples and I don't found examples related to USB using API. Is there any limitation to use USB by API? In this case is possible to control USB through BgScript and Wifi and ethernet through API?
I have a custom board with a WF111 on it. The driver seems to work. My problem is that when I try to use wpa_supplicant I get the following output...
root@am437x-evm:~# wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf Successfully initialized wpa_supplicant wlan0: Unsupported driver 'wext'
It would seem my platform doesn't have wext. It only has nl80211. When I try to use nl80211 I get the following output...
root@am437x-evm:~# wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant.conf Successfully initialized wpa_supplicant nl80211: Driver does not support authentication/association or connect commands nl80211: deinit ifname=wlan0 disabled_11b_rates=0 wlan0: Failed to initialize driver interface
Any help in resolving this would be greatly appreciated. I noticed the driver comes with some patches for wpa_supplicant. Do I need to patch it and rebuild it?
I get some random crash with WGM110; having excluded other causes, I think it may be a problem of stack/memory.
Therefore, I would like some clarifications.
What is the max call stack size of bgscript on WGM110?
The compiler does check the used stack memory at compile time?
What is exactly pushed in the stack? does memcpy command go into the stack?
Does events and commands counts, or the stack is only for user defined procedures?
Parameters of procedures count even if the parameter is defined as const?
The section "script" in the memory report of bgbuild script represents the programm memory used?
The section "stack" represents the maximum stack size? Is there anyway to estimante the maximum used stack memory?
The section "2.3 Buffers" of BGscript user guide reports that the maximum size of a buffer is 256 bytes, why does the compiler allow to create a buffer with larger size?
What happens if I declare a buffer of size 1000?
How the code has to done to recevice, with bgscript, an HTTP response greater than 256 byte?
Finally, can you clarify the following section of the BGscript user guide?
"Constant strings must be defined before use. The maximum size of a constant string depends on application and stack usage. For
standard Wi-Fi applications, a safe size is around 64 bytes."
I have the WGM110 starter kit, i configure it in TCP or UDP client and i would like to know if it possible to transfert receiving data by wifi on the rj45 in the same protocol ?
If it possible can i have a code exemple please
I've asked before and never got a response explaining what exactly might trigger an error 0x187, 'hardware failure', and I'm running into it again - and this time it's definitely not a power problem.
In the particular capture I'm looking at, the device is reset and while it's offline a browser continues to pile up JSON requests for it. When the module reconnects, it gets a flood of HTTP requests - close to 1000 in 30 seconds. The WGM110 holds up for that long, and then starts giving 0x188 'buffers full' responses to the host's HTTP responses. It seems to bog down, with the last 0x188 RSP taking 40 ms to be sent, and then 375 ms passes with no RSP at all. At this point the host times out and tries again, and again 375 ms later. It eventually gets a 0x184 'invalid command', which is reasonable since it didn't wait for a RSP and violated the packet sequence, but that's immediately followed by evt_sme_wifi_is_off with a 0x187 error.
My questions are:
1. What exactly does 0x187 'hardware failure' indicate?
2. Why does rapid HTTP traffic cause a hardware failure and how can it be avoided?
3. What is a reasonable timeout value when waiting for a RSP?
4. What is the expected recovery procedure in the event of a hardware failure or RSP timeout?
The reference manual makes no mention of RSP timeouts, and simply says that the host must wait for a RSP to every command. It gives no information about expected times. Most commands usually respond in a few hundred microseconds. The signal quality check command takes half a second or more. While it's easy to say that the module will always send a response, in my experience that can't be relied on. There must be some procedure to recover, even if that recovery procedure is to initiate a hardware reset, but I need to know when the host should start that procedure.
You might also say that 30 HTTP requests/second is too much and that they should be throttled at the originating end. That's fair, but then what IS a request rate that the module can safely handle? Is the hardware failure purely a function of the buffer overload and guaranteed not to happen at lower rates, or is it probablistic? If it's failing with consistency in under 60 seconds on my test bench with 30 requests/second, when a thousand units are deployed and handling 3 requests per second, how often can I expect them to fail with the same error?