Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
wiced_get_http_packet_state_and_socket_context doesn't work as intended. It uses wiced_http_message_context_t* socket_http_context as an output argument, which obviously never works, because it just assigns this pointer (it should be a pointer to a pointer), so the context is never actually restored, and messages arriving when packet state is HTTP_DATA_ONLY_FRAME_STATE will always fail. I guess it was tested with very basic requests, so this code path was never exercised, it works by coincidence.
wiced_http_server_set_http_message_body_type_for_socket and wiced_reset_current_message_body_context_for_socket have conflicting logic: "Set" function will try to get a free context slot using socket_http_message_context_counter as index, and "reset" will loop through the list, nullify found element, but then simply decrement socket_http_message_context_counter, thus erasing a valid element instead of the one it just nullified. I suppose it also works by coincidence, because there are no more than 1 concurrent connection at a time, so it also works by coincidence.
server_event_queue is a global object, so it's not possible to start more than one HTTP(S) server (for example port 80 and port 443). It stems from the issue that it's not possible to pass custom context to WICED TCP callbacks the library is built on, so it relies on a global variable.
TCP server library
Not so much of a bug, but undocumented "feature": WICED_MAXIMUM_NUMBER_OF_SERVER_SOCKETS is set to WICED_MAXIMUM_NUMBER_OF_SOCKETS_WITH_CALLBACKS, which makes creating two TCP servers fail mysteriously.
Pretty glaring bug in wiced_dct_write_wifi_config_section that writes DCT_SECURITY_SECTION instead of DCT_WIFI_CONFIG_SECTION. The function is deprecated, but should not be a reason for it to be unusable.
Missing factory reset DCT support
factory_reset_dct target in the Makefile clearly refers to wiced_factory_reset.mk file that's missing from the SDK.
Can anyone from Broadcom comment on these, and whether an updated SDK will be available soon, so I don't have to maintain patches for these bugs?
Thanks for that observation. And I have had many more. I used to feed these in, and they survived to SDK 3.0.0, and then were lost as the internal developers were shifted around and the patches lost. Many of the defects are in the ST HAL libraries too.
The whole watchdog support is a problem, and needs a means for taking out the TIMER_7 debug overlays.
Supporting the internal ADC channels is possible but not implemented.
The RTC is reset on every power-up so if you support it with a battery it fails to track through power loss.
PWM can only take rates above 1000 Hz because the dividers are only 16-bit (but can be extended to 32-bit).
It does help that we have source code ... but it would be even better if the defects were corrected.