WICED currently has support for sflash from the following manufacturers.
You can get a list of all the supported sflash in CYW43907 with External SFLASH in WICED . If you want to add support for any other part number from the existing supported flash manufacturers in WICED SDK, you can follow the steps mentioned below. In this example, I have added support for N25Q128A flash from MICRON.
For ST based platforms:
#define SFLASH_ID_MX25L8006E ( (uint32_t) 0xC22014 )
#define SFLASH_ID_MX25L1606E ( (uint32_t) 0xC22015 )
#define SFLASH_ID_MX25L6433F ( (uint32_t) 0xC22017 )
#define SFLASH_ID_MX25L12835F ( (uint32_t) 0xC22018 )
#define SFLASH_ID_MX25L25635F ( (uint32_t) 0xC22019 )
#define SFLASH_ID_MX25U1635F ( (uint32_t) 0xC22535 )
#define SFLASH_ID_MX66U51235F ( (uint32_t) 0xC2253A )
#define SFLASH_ID_SST25VF080B ( (uint32_t) 0xBF258E )
#define SFLASH_ID_EN25QH16 ( (uint32_t) 0x1C3015 )
#define SFLASH_ID_ISSI25CQ032 ( (uint32_t) 0x7F9D46 )
#define SFLASH_ID_N25Q512A ( (uint32_t) 0x20BB20 )
#define SFLASH_ID_ISSI25LP064 ( (uint32_t) 0x9D6017 )
#define SFLASH_ID_N25Q064A ( (uint32_t) 0x20BA17 )
#define SFLASH_ID_W25Q64FV ( (uint32_t) 0xEF4017 )
#define SFLASH_ID_CY15B104Q ( (uint32_t) 0x7F7F7F )
+#define SFLASH_ID_N25Q128A ( (uint32_t) 0x20BA18 )
#define SFLASH_ID_DEFAULT ( (uint32_t) 0x000000 )
#define SFLASH_SIZE_1MByte 0x100000
#define SFLASH_SIZE_2MByte 0x200000
#define SLFASH_SIZE_32MByte 0x2000000
#define SFLASH_SIZE_64MByte 0x4000000
#define SFLASH_SIZE_512KByte 0x80000
#define SFLASH_SIZE_16MByte 0x1000000
device_id_to_flash_size_t sflash_device_id_size [SFLASH_ID_MAX_PARTS] =
{
{ SFLASH_ID_MX25L8006E, SFLASH_SIZE_1MByte },
{ SFLASH_ID_MX25L1606E, SFLASH_SIZE_2MByte },
{ SFLASH_ID_MX25L25635F, SLFASH_SIZE_32MByte },
{ SFLASH_ID_MX25U1635F, SFLASH_SIZE_2MByte },
{ SFLASH_ID_SST25VF080B, SFLASH_SIZE_1MByte },
{ SFLASH_ID_EN25QH16, SFLASH_SIZE_2MByte },
{ SFLASH_ID_N25Q512A, SFLASH_SIZE_64MByte },
{ SFLASH_ID_CY15B104Q, SFLASH_SIZE_512KByte },
{ SFLASH_ID_N25Q128A, SFLASH_SIZE_16MByte }
};
For 4390x based platform
To add a new part with the already supported sflash chips for 4390x platform, you have to make the necessary modifications in 43xxx_Wi-Fi/WICED/platform/MCU/BCM4390x/peripherals/spi_flash.
#define SFLASH_ID_MX25L8006E SFLASHID( 0xC2, 0x20, 0x14 )
#define SFLASH_ID_MX25L1606E SFLASHID( 0xC2, 0x20, 0x15 )
#define SFLASH_ID_MX25L6433F SFLASHID( 0xC2, 0x20, 0x17 )
#define SFLASH_ID_MX25L12835F SFLASHID( 0xC2, 0x20, 0x18 )
#define SFLASH_ID_MX25L25635F SFLASHID( 0xC2, 0x20, 0x19 )
#define SFLASH_ID_MX25U1635F SFLASHID( 0xC2, 0x25, 0x35 )
#define SFLASH_ID_MX66U51235F SFLASHID( 0xC2, 0x25, 0x3A )
#define SFLASH_ID_SST25VF080B SFLASHID( 0xBF, 0x25, 0x8E )
#define SFLASH_ID_EN25QH16 SFLASHID( 0x1C, 0x30, 0x15 )
#define SFLASH_ID_ISSI25CQ032 SFLASHID( 0x7F, 0x9D, 0x46 )
#define SFLASH_ID_N25Q512A SFLASHID( 0x20, 0xBB, 0x20 )
#define SFLASH_ID_ISSI25LP064 SFLASHID( 0x9D, 0x60, 0x17 )
#define SFLASH_ID_N25Q064A SFLASHID( 0x20, 0xBA, 0x17 )
#define SFLASH_ID_W25Q64FV SFLASHID( 0xEF, 0x40, 0x17 )
#define SFLASH_ID_S25FL064L SFLASHID( 0x01, 0x60, 0x17 )
#define SFLASH_ID_S25FL128L SFLASHID( 0x01, 0x60, 0x18 )
#define SFLASH_ID_S25FL256L SFLASHID( 0x01, 0x60, 0x19 )
#define SFLASH_ID_N25Q128A SFLASHID( 0x20, 0xBA, 0x18 )
#define SFLASH_ID_DEFAULT SFLASHID( 0x00, 0x00, 0x00 )
#ifdef SFLASH_SUPPORT_MICRON_PARTS
{ SFLASH_ID_N25Q064A, { 8*MBYTE, 256, .action = µn_action, .speed_advance = µn_speed_config } },
{ SFLASH_ID_N25Q128A, { 16*MBYTE, 256, .action = µn_action, .speed_advance = µn_speed_config } },
#endif
GLOBAL_DEFINES += SFLASH_SUPPORT_MICRON_PARTS
Debugging Notes:
SFLASH Device ID ( 0x20ba18)
SFLASH Size ( 0x1000000)
The BCM2073x chip (SoC) has 40 logical GPIOs (P0-P39).
The GPIOs themselves are broken out into three separate ports (meaningful when you start programming):
• P0 through P15 on port0
• P16 through P31 on port1
• P32 through P39 on port2
The 32 pin package (i.e. the SoC - BCM20736 and BCM20737 *without* the S) only brings out 14 of the 40 logical GPIOs. The System in Package/SIP (the BCM20736S and BCM20737S modules) follows the SoC closely with regards to which pins are brought out (but there is a slight difference) and these are what you see in the SIP module datasheets.
Since the 32 pin package (SoC) and the modules are pin-limited, some of the logical GPIOs within the SoC are multi-bonded before bringing them out on the balls on the chip.
For the 32 pin package, the following pins are bonded in this manner:
Very Important Note: The SOC packaged part described above is not used for the SIP module. The SIP uses the raw die and wirebonds it differently than the DFN part, so the IOs described above for the SoC are not bonded together from the die - they are bonded together on the DFN wirebond package.
Always refer to the BCM20737S Bluetooth Low Energy SiP Module Technical Reference for the bonding/alternate function information relevant to the SIP modules, not the BCM20737 SOC Data Sheet.
When leveraging the WICED™ Smart Hardware Interfaces for your development, you will run across several GPIO mapping tables in the document that look like this one:
Note here that you can use only one of the GPIOs (noted in black) from each of the vertical rows above. This is what is referenced in the WICED™ Smart Hardware Interfaces as a "group" (all signals must be selected from the same group, which is essentially the table).
All options may not be available in the package used within the SIP module (shown in red). Combinations shown in red text are also not generally available on the BCM20732 TAG. Additional options may be unavailable if they are being used for the peripheral UART interface.
All GPIOs support programmable pull-up and pull-down resistors, along with a 2 mA drive strength except P26, P27, and P28, which provide a 16 mA drive strength at 3.3V supply (this will change as the supply drops and the GPIO pins will sink less current).
The GPIOs are all capable of waking the device from sleep or deep sleep and the application can configure interrupts (both/either edges, level), pull-up/pull-down High-Z, etc.
The following GPIOs are available on the BCM2073XS based SIP Modules (remember, only 14 are brought out on the SIP module):
For unused dual bonded pins, the unused GPIO should be input/output disabled (especially when it is an input).
From the perspective of writing software against the GPIO mappings defined above, it's important to keep in mind that the GPIO is physically mapped to a BCM2073XS device within the platform.h file which is custom to the TAG development board by default.
However, this mapping in platform.h can be reconfigured for a custom design.
The values in platform.h then map to definitions and function prototypes in bleprofile.h
Note that the specific values in the bleprofile.h bitmasks themselves are not intended to be exposed as the code beneath these bitmasks is proprietary and cannot be released for reasons outside the scope of this discussion.
In addition to reconfiguring the mappings of your custom board within the bleprofile.h, GPIO can also be assigned within BLE_PROFILE_GPIO_CFG within the .c file for each application. This is also where you allocate/initialize the GPIO within your application. The bleprofile_xxx() routines are then how you use/access what you have configured above.
With this said, I realize there is some ambiguity in this message as we have documents like WICED™ Smart Hardware Interfaces which clearly states that the BCM2073X (note that this guide was written for the SoC, then modified slightly for the SIP module) includes two sets of APIs that are available for the application: the low-level driver API and the high-level profile API.
So yes, the Low Level API is there and in some cases ok to use, but we are not consistent in exposing everything a developer needs to actually use it effectively on a consistent basis.
Hopefully you guys find this helpful. I know many of you have tidbits to add, so feel free to comment (please stay on topic). I would love to see some examples and code snippets showing usage of the bleprofile_xxx() routines.
Show LessThe attached app shows sample usage of the ADC hardware built into the 36/37/s chips.
To use the app, load it onto a Tag board that has a push button on P0. Run traces on the board. You'll initially see ~0V, and when you press the button you'll see the applied voltage on the voltage rail (~3300mV).
There are three necessary steps to get the ADC running, as seen in the app:
Import:
#include "adc.h"
Instantiate in create function:
adc_config();
And poll the ADC using the function:
adc_readVoltage(adc_convertGPIOtoADCInput(gpio_number));
*Calibration occurs within the initialization function. However, it may be useful to your application to calibrate the ADC to an external voltage for added assurance, or to do so periodically throughout the run-time of your application. To do so, call the function below: parameter one is the known voltage of the reference source in mV, and parameter two is the location of the reference voltage. The location can be configured to many different buses and all GPIOs (for external sources). Control click the second parameter within the source code to see a complete list of the locations that can be utilized as a reference voltage.
adc_adcCalibrate(2000, ADC_INPUT_VDDIO);
The output of the polling function is in mV.
More info on the ADC:
BCM20737S - ADC Noise-free resolution
Questions related to the ADC implementation on the BCM2073XS...
BCM20737 ADC DMA or Interrupt Service Routine
Show LessProduct Selection | Product Evaluation | WICED Sense | Product Development | Manufacturing / Production |
The WICED host CPU's ADC port can be setup to read ADC data and send it to a remote host or client.
The App_temp_control application (temp_control) located in .../apps/demo/temp_control demonstrates ADC setup and reading. This application sends temperature data (ADC data) to remote host (www.xively.com). The same data is served by the http server running on the WICED module and sent to http clients. This is a comprehensive sample application with many rich features.
The attached sample application sets up the ADC using only WICED APIs and reads the ADC data then prints the read ADC value on the serial terminal.
The new adc_setup_read snip application is located in …/apps/snip/adc_setup_read. Patch file updates the …/apps/snip/ directory with adc_setup_read application files.
In order to run this snip application on the BCM43341WCD1 platform platform.c and platform.h files needs to be updated. Attached patch file contains the needed changes.
Use the following Make Target commands to build the ADCSetupReadApp application.
For BCM943362WCD4 platform:
snip.adc_setup_read-BCM943362WCD4 download run
For BCM943341WCD1 platform:
snip.adc_setup_read-BCM943341WCD1 download run
The ADC values are printed on the serial terminal.