WICED™ Studio Forum Discussions
Browse the Community
Featured Discussions
Get WICED Smart with Nebula
FREE Hands-On Training: Nebula IoT Reference Design board with Cypress & Murata
This hands-on training workshop is designed to address the challenges in developing IoT products and equip engineers with key technical skills to develop cloud-connected products, using:
- Future Electronics: Nebula reference design board
- Cypress: CYW4343W Wi-Fi and Bluetooth Classic (BR/EDR) / BLE chipset radio
- Cypress: WICED SDK
- Murata: 1DX module
Challenges that typically need to be solved when developing IoT Products:
- Connectivity challenges (wireless protocols & standards)
- Security & privacy (authentication & encryption)
- Cloud storage, analysis, computing/actions
- Device management, field updates, system scalability
- Mobile platform integration (smartphones & tablets)
Workshop Objectives:
- By the end of this workshop, you will be able to Navigate the WICED development environment
As a follow on to this thread: Re: brcm_patchram_buf to flash?
Damn, it looks like the BT library wherein the brcm_patchram_buf is actually loaded is inside a closed-source library.
There's the wiced_hci library, but that appear to be only for a 92xxx products?
If it wasn't, it really shouldn't be hard to add it into the FS image and load from there. The hardest part would be patching the Makefile system to work cleanly.
rroy feature request
Show LessGet WICED Smart with Nebula
FREE Hands-On Training: Nebula IoT Reference Design board with Cypress & Murata
This hands-on training workshop is designed to address the challenges in developing IoT products and equip engineers with key technical skills to develop cloud-connected products, using:
- Future Electronics: Nebula reference design board
- Cypress: CYW4343W Wi-Fi and Bluetooth Classic (BR/EDR) / BLE chipset radio
- Cypress: WICED SDK
- Murata: 1DX module
Challenges that typically need to be solved when developing IoT Products:
- Connectivity challenges (wireless protocols & standards)
- Security & privacy (authentication & encryption)
- Cloud storage, analysis, computing/actions
- Device management, field updates, system scalability
- Mobile platform integration (smartphones & tablets)
Workshop Objectives:
- By the end of this workshop, you will be able to Navigate the WICED development environment
Hello,
Per this prior thread: wiced studio 5.2 backward compatibility for 4343wcd1
I also face the same issue. After updating filesystem, device lost wifi functionality. So is there any solution to update filesystem?
Show LessItems in Red have been added and/or slightly modified for OSX platforms:
OSX Install:
- Download the attached .zip file
- Double click the zip file and extract all contents from the installer to a local folder
- Note: When using the Safari Browser, it will automatically unzip the contents and create a folder
- Note: the next two steps above are needed as a workaround for a known OSX 10.12 install issue called "App Translocation"
- Move the contents of the folder to another folder using ‘Finder’; Do not move the files using ‘Terminal’
- Run the command below using Terminal window:
> xattr -r -d com.apple.quarantine <path>/WICED-Studio-X.X.X.X-IDE-Installer.app
- See "Additional Installation Notes" below before installing
- Double click the "WICED-Studio-X.X.X.X-IDE-Installer" app to execute the installer
- After the installation in complete, launch the WICED Studio IDE from shortcut in the $HOME/Cypress $HOME/WICED/WICED-Studio-X folder
OSX Uninstall:
- From Finder, navigate to User > <name> -> Applications -> Cypress and launch 'Uninstall'
- To clean up all WICED components manually, delete files and folders for the IDE and SDK, typically in User -> <name> -> WICED/WICED-Studio-X and User -> <name> -> Documents -> WICED/WICED-Studio-X or from terminal $HOME/Cypress/WICED*, $HOME/WICED/WICED-Studio-X and $HOME/Documents/WICED/WICED-Studio-X
Additional Installation Notes:
1.
Open xterm, run the "java -version" command. If it fails to return any results or states that you are running version 1.6, then you need to install the Java SE Development Kit 8, which can be found here: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html. Once the Java SE Development Kit 8 is installed, run the "java -version" command again with xterm. If this command returns "1.6", then you will need to fix the symbolic link using the following commands:
> rm -f /usr/bin/java
> ln -s /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java /usr/bin/java
2.
Application downloads on WICED platforms may fail on certain OSX versions due to an incompatibility between the OSX version and the installed driver for the FTDI USB to serial chip. On OSX versions 10.10 and earlier, a specific version of the FTDI driver must be installed using the instructions available here: https://learn.sparkfun.com/tutorials/how-to-install-ftdi-drivers/mac
On OS X versions 10.11 and greater, the Apple version of the FTDI driver must be used, and any previous instance of the FTDI version of the driver must be removed from the system, by executing the following command in xterm:
> sudo rm -rf /Library/Extensions/FTDIUSBSerialDriver.kext /System/Library/Extensions/FTDIUSBSerialDriver.kext
Reboot the system after performing the rm command
Show LessHi,
I am working with ISM43903 modules that currently run SDK 4.1.
When I use OTA2 mechanism to upgrade the software to one based on SDK 6.1 I get into trouble.
After some digging I think I have found why.
During OTA2 upgrade bootloader and failsafe app are not upgraded, so they stay as they were in SDK 4.1.
Extract app and main app are upgraded to SDK 6.1, so when they write DCT, it becomes marked with new version.
DCT 6.1 version is set to in wiced_dct_finish_new_dct() in wiced_dct_external_common.c as below:
new_dct_version->version | = DCT_BOOTLOADER_SDK_CURRENT; | |
new_dct_version->sequence++; | /* always increment the sequence */ |
Now when bootloader or failsafe (from SDK 4.1) tries to read OTA2 config structure from DCT written with software basaed on SDK 6.1 it gets to the function wiced_dct_get_current_address(), which in turn reads version of both DCTs using wiced_dct_validate_and_determine_version().
During determining version wiced_dct_minimal_check_dct_version() is called, which returns WICED_FALSE (we are reading DCT written by SDK 6.1 using code from SDK 4.1).
In this case the following code is used:
this_dct_version = DCT_BOOTLOADER_SDK_VERSION;
goto _version_test_done_and_deinit_sflash;
What is important, in such a case CRC is not checked and sequence number is not checked, only version from old SDK is returned (even for non-current DCT)
The code in wiced_dct_get_current_address() that decides which DCT is current looks as below:
use_dct1 = WICED_TRUE;
if ((dct1_sdk_version == DCT_BOOTLOADER_SDK_UNKNOWN) && (dct2_sdk_version == DCT_BOOTLOADER_SDK_UNKNOWN))
{
goto _both_dcts_invalid;
}
else if ((dct1_sdk_version != DCT_BOOTLOADER_SDK_UNKNOWN) && (dct2_sdk_version != DCT_BOOTLOADER_SDK_UNKNOWN))
{
/* Both DCTs are valid
* determine most recent using version # (and sequence # if versions are the same)
*/
if (dct1_sdk_version < dct2_sdk_version)
{
use_dct1 = WICED_FALSE;
}
else if (dct1_sdk_version == dct2_sdk_version)
{
/* if one of the version data has initial_write == 1, it is the correct one to use! */
if ((dct2_initial_write != 0) && (dct2_initial_write != 0xFF))
{
use_dct1 = WICED_FALSE;
}
else if ((dct1_initial_write != 0) && (dct1_initial_write != 0xFF))
{
use_dct1 = WICED_TRUE;
}
else if (dct1_sequence < dct2_sequence)
{
use_dct1 = WICED_FALSE;
}
}
}
else if (dct1_sdk_version == DCT_BOOTLOADER_SDK_UNKNOWN)
{
/* dct2 is valid, use that */
use_dct1 = WICED_FALSE;
}
In case when both DCTs were written with SDK 6.1 software and are read with SDK 4.1 software (bootloader or failsafe) we get dct1_sdk_version and dct2_sdk_version set to 0x401, dct1_sequence and dct2_sequence set to 0, so we end up with use_dct1 set to TRUE. But as CRC is not checked and sequence number not checked, DCT1 may be invalid in fact. So in this case bootloader or failsafe ends up with reading incorrect OTA2 boottype.
So the question is: how to make this upgrade working correctly ? (Without upgrading bootloader and failsafe on already produced devices)
Show LessI have to down load 6MB file from cloud using USI 22 ( BMC4343XX + STM32F41xx) module, which has 1MB Flash nd 256KB RAM. The module connected cloud via TCP/IP(HTTPS) and USART to Host MCU which have 64MB Flash and 16MB RAM but it is very busy with doing all the application. I need to transfer this data reliably and correctly to host processor. My understanding of file transfer from server is verify by HTTP client after download entire file,
Q1. What is the best way to down load this big data from server
1. Chop the big file into 1KB packet and every packet with clear packet number and CRC
2. Wi-F module verify every packet received the send to host via serial port
3. Host will verify the CRC and store into flash
4. After transfer entire packet cloud send file hash
5. Hash is verify by host
In is this good idea? or give some suggestion please
Show LessQuestion:
Is there any data on the philosophy we have for creating unique MAC addresses for WiFI modules where the customer is developing with WICED. He would like to of course have the first 3 octets be his IEEE address, and the next 3 be something that can easily introduced into the part or read from the part so he can put a label on the module with the assigned MAC address.
Can you provide a document on the care and feeding of MAC addresses under WICED?
Answer:
There's a file at the top level of WICED has some clues for you to get started (contents below); There appears to be multiple ways of going about this:
/*
* The MAC address of the Wi-Fi device may be configured in one of several places as
* described in the document WICED-AN800-R Factory Programming Application Note.
* Please read this document for further information.
*/
#define NVRAM_GENERATED_MAC_ADDRESS "macaddr=00:A0:50:27:92:0c"
#define DCT_GENERATED_MAC_ADDRESS "\x00\xA0\x50\x0c\x27\x92"
#define DCT_GENERATED_ETHERNET_MAC_ADDRESS "\x00\xA0\x50\x0c\x27\x93"
This Help Article is also helpful: https://community.cypress.com/community/wiced-wifi/wiced-wifi-forums/blog/2017/07/12/how-to-add-mac-address-to-your-wiced-app
Show Less