- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ,
Do you have a guide provide to user about how to add a new platform in WICED?
I would like to porting a new platform to WICED, but I don't know how start.
Thanks!
Solved! Go to Solution.
- Labels:
-
WICED Studio
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please tell what platform are you planning to add in WICED? As mifo pointed out, the first part will be adding the platform files (platform.c, platform.h, <platfiorm_name>.mk, platform_config.h) and then port the host MCU src files in the following location 43xxx_Wi-Fi/WICED/platform/MCU. You also have to write your own linker script (.ld) and add it to the following location 43xxx_Wi-Fi/WICED/platform/MCU/<target_MCU>/GCC. We are working on a document to provide some more granular details of platform porting but unfortunately I can't provide you with an ETA for the same as of now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This section of chapter 2 from the WICED 101 training introduces platform files and how platform.c/platform.h are leveraged within WICED to properly reflect pins on your hardware.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you please tell what platform are you planning to add in WICED? As mifo pointed out, the first part will be adding the platform files (platform.c, platform.h, <platfiorm_name>.mk, platform_config.h) and then port the host MCU src files in the following location 43xxx_Wi-Fi/WICED/platform/MCU. You also have to write your own linker script (.ld) and add it to the following location 43xxx_Wi-Fi/WICED/platform/MCU/<target_MCU>/GCC. We are working on a document to provide some more granular details of platform porting but unfortunately I can't provide you with an ETA for the same as of now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am working enable NXP's i.mxRT1050 on WICED with CYW4343W wifi module and i have finished most of porting, but i have some questions,
i have created a target named,
snip.led_Example-EVKBMIMXRT1050_4343W-FreeRTOS-LwIP-debug download
i want to enable a simple led example firstly, but when i build the target, i saw two more target generated,
waf.bootloader-NoOS-EVKBMIMXRT1050_4343W
waf.sflash_write-NoOS-EVKBMIMXRT1050_4343W-SDIO
and i got error
I have no idea why bootloader and sflash write is needed.
when i remove debug and download string, and add no boot loader in makefile, i can generate a elf file, so my questions is,
1. how can i avoid use of bootloader and sflash_write? they are removable?
2. why NoOS is needed while i have enabled freertos?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The bootloader essentially loads the program entry point along with setting up the timing etc. Similarly, sflash_write is used to facilitate the application download to sflash, which is leveraged in all the Cypress EVK. Please go through the waf.sflash_write and waf.bootloader code to get a detailed understanding of Wiced Application Framework. If you check the makefiles of these files, you can find these apps do not require an OS, hence you are seeing NoOS tag in the error log.
If you do not want to use the bootloader (which is not recommended ) or sflash_write, WICED allows you the flexibility to do that. To understand the WICED eco-system better, you can have a look at the makefiles as located in 43xxx_Wi-Fi/tools/makefiles to understand how the bootloader or sflash_write calls are being invoked. If you specify RESOURCES_LOCATION := RESOURCES_IN_DIRECT_RESOURCES, and comment-out the USES_RESOURCE_FILESYSTEM part in plaform_config.h, then all the resources will be stored in the internal flash and waf.sflash_write will not be used. To avoid downloading the bootloader, you can use NO_BOOTLOADER_REQUIRED=1 NO_BUILD_BOOTLOADER=1 macros.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you very much for your reply, i just want to enable the wifi moudle for RT with WICED, i got a big ram memory on board, so i want to avoid use of bootloader or flash write and the linker file which i configured were all allocated from RAM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Sorry for trouble you again,
I got another questions , application run failed when get the DCT magic number, in the wiced_network_init/wiced_network_get_hostname function, seems the DCT section has no available information,
I am using Jlink gdb server + arm-gdb download the elf file directly,
1.download snip.led_Example-EVKBMIMXRT1050_4343W-FreeRTOS-LwIP-debug.elf
2.load DCT.elf(in build/snip.led_Example-EVKBMIMXRT1050_4343W-FreeRTOS-LwIP-debug/DCT.elf )
3.Correct the PC pointer.
Seems the DCT.elf generated is not correct, how can i correct it?Or can I use no dct to disable DCT, i have no idea if it is necessary or not!
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you create the correct dct.ld required to be present 43xxx_Wi-Fi/WICED/platform/MCU/<MCU_SERIES>( e.g STM32F4xx)/GCC/<MCU_NAME> (e.g STM32F429)/dct.ld? If you are not using the bootloader then also this problem might appear because bootloader code checks the DCT INTERNAL section for boot-up information. To understand the DCT requirement in WICED, please go through the DCT app note as provided in 43xxx_Wi-Fi/doc/WICED-DCT.pdf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes, i believe i have created a correct dct.ld,
MEMORY
{
/*
BTLDR_OR_VECTOR_FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 16K
*/
DCT1_FLASH (rx) : ORIGIN = 0x80004000, LENGTH = 16K
DCT2_FLASH (rx) : ORIGIN = 0x80008000, LENGTH = 16K
APP_FLASH (rx) : ORIGIN = 0x8000c000, LENGTH = 976K
SRAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}
PHDRS
{
rodata PT_LOAD ;
}
SECTIONS
{
.rodata :
{
dct_location = .;
KEEP(*(.rodata.initial_dct))
KEEP(*(.rodata._app_dct))
KEEP(*(.rodata.wiced_apps_lut))
KEEP(*(.rodata.wiced_apps_lut_fill))
dct_end = .;
} >DCT1_FLASH AT> DCT1_FLASH :rodata
}
PROVIDE( dct_full_size_loc = LENGTH( DCT1_FLASH ));
PROVIDE( dct_used_size_loc = (dct_end - ORIGIN( DCT1_FLASH )));
what do you mean by
If you are not using the bootloader then also this problem might appear because bootloader code checks the DCT INTERNAL section for boot-up information
?
Do you mean no matter use bootloader or not, DCT section check is always perform?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I checked the generated DCT.bin,
0040 0000 401f 0000 0001 0100 4252 434d
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0100 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0200 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0200 0000 2200 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0200 0000 4400 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0200 0000
6600 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0200 0000 8800 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0200 0000 aa00 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0200 0000 cc00 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0200 0000
ee00 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 -------------->offset is 0x200
Above high light line is the line read to compare, it is all zero.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I hope you have correctly checked the address mapping in the dct.bin file and the one you wrote in .ld file. Please check the Dump of the dct.bin and see if you get some meaningful comments like the AP name, passphrase etc. Some sections of the DCT might be unused hence those might be zero but the other sections should have some meaningful comments in the dump. Regarding "because bootloader code checks the DCT INTERNAL section for boot-up information" comment means bootloader checks the INTERNAL section of DCT for boot details which the device won't be able to fetch as bootloader is not being used.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes, thanks for your reply.
The issue is caused by the address allocated for DCT1_FLASH mismatch between DCT.ld and memory_with_bootloader.ld.
By the way, i got timeout in wwd_bus_sdio_download_firmware,
if ( loop_count >= (uint32_t) HT_AVAIL_TIMEOUT_MS )
{
/* If your system times out here, it means that the WLAN firmware is not booting.
* Check that your WLAN chip matches the 'wifi_image.c' being built - in GNU toolchain, $(CHIP)
* makefile variable must be correct.
*/
WPRINT_WWD_ERROR(("Timeout while waiting for high throughput clock\n"));
/*@-unreachable@*/ /* Reachable after hitting assert */
return WWD_TIMEOUT;
/*@+unreachable@*/
}
Then i checked i my makefile configurations, in platform/EVKBMIMXRT1050_4343W/.mk
NAME := Platform_EVKBMIMXRT1050_4343W
WLAN_CHIP := 4343W
WLAN_CHIP_REVISION := A1
WLAN_CHIP_FAMILY := 4343x
HOST_MCU_FAMILY := MIMXRT1052
HOST_MCU_VARIANT := MIMXRT1052
HOST_MCU_PART_NUMBER := MIMXRT1052DVL6B
BT_CHIP := 43438
BT_CHIP_REVISION := A1
BT_CHIP_XTAL_FREQUENCY := 26MHz
PLATFORM_SUPPORTS_BUTTONS := 1
ifndef BUS
BUS := SDIO
endif
And the wifi module which i am using is,
muRata Type1DX FS EVB P2ML3661A
Part number on chip is:
SS7224015
1DX
Do i have some configurations error? I have checked the .map file, 4343WA_bin firmware is included correctly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please check the LPO_IN pin of your module which according to the datasheet should be connected to the sleep_clock of your host MCU. If you don't have any idea about that, you can alternatively ground the LPO_IN pin but the LPO_IN should not be left hanging. In case, the pin is grounded, it will use the internal LPO which is not really as accurate as the external sleep clock, hence we don't recommend or support to use it at all. If you want to have good low power numbers and the wwd_bus_sdio_download_firmware to pass, please connect the LPO_IN pin with external sleep clock generated from i.mx side.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
i tried with connect the LPO_IN to ground or external 32.768KHZ oscillator, both of two not work, but the external OSC output waveform amplitude is very small, about 1.0v, does it make sense?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Please attach your nvram file (wifi_nvram_image.h) which should be a part of your platform directory for further debugging
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
/** @file
* NVRAM variables taken from BCM943438WLPTH nvram file (2.4 GHz, 20 MHz BW mode)
*/
#ifndef INCLUDED_NVRAM_IMAGE_H_
#define INCLUDED_NVRAM_IMAGE_H_
#include <string.h>
#include <stdint.h>
#include "../generated_mac_address.txt"
#ifdef __cplusplus
extern "C" {
#endif
/**
* Character array of NVRAM image
*/
static const char wifi_nvram_image[] =
// # The following parameter values are just placeholders, need to be updated.
"manfid=0x2d0" "\x00"
"prodid=0x0726" "\x00"
"vendid=0x14e4" "\x00"
"devid=0x43e2" "\x00"
"boardtype=0x0726" "\x00"
"boardrev=0x1101" "\x00"
"boardnum=22" "\x00"
"xtalfreq=26000" "\x00"
"sromrev=11" "\x00"
"boardflags=0x00404201" "\x00"
"boardflags3=0x08000000" "\x00"
NVRAM_GENERATED_MAC_ADDRESS "\x00"
"nocrc=1" "\x00"
"ag0=255" "\x00"
"aa2g=1" "\x00"
"ccode=ALL"
"\x00"
//#Antenna diversity
"swdiv_en=1" "\x00"
"swdiv_gpio=2" "\x00"
"pa0itssit=0x20" "\x00"
"extpagain2g=0" "\x00"
//#PA parameters for 2.4GHz, measured at CHIP OUTPUT
"pa2ga0=-140,6566,-728" "\x00"
"AvVmid_c0=0x0,0xc8" "\x00"
"cckpwroffset0=5" "\x00"
//# PPR params
"maxp2ga0=84" "\x00"
"txpwrbckof=6" "\x00"
"cckbw202gpo=0" "\x00"
"legofdmbw202gpo=0x66111111" "\x00"
"mcsbw202gpo=0x77711111" "\x00"
"propbw202gpo=0xdd" "\x00"
//# OFDM IIR :
"ofdmdigfilttype=18" "\x00"
"ofdmdigfilttypebe=18" "\x00"
//# PAPD mode:
"papdmode=1" "\x00"
"papdvalidtest=1" "\x00"
"pacalidx2g=32" "\x00"
"papdepsoffset=-36" "\x00"
"papdendidx=61" "\x00"
//# LTECX flags
// "ltecxmux=1" "\x00"
//"ltecxpadnum=0x02030401" "\x00"
// "ltecxfnsel=0x3003" "\x00"
// "ltecxgcigpio=0x3012" "\x00"
//#il0macaddr=00:90:4c:c5:12:38
"wl0id=0x431b" "\x00"
"deadman_to=0xffffffff" "\x00"
//# muxenab: 0x1 for UART enable, 0x2 for GPIOs, 0x8 for JTAG, 0x10 for HW OOB
"muxenab=0x11" "\x00"
//# CLDO PWM voltage settings - 0x4 - 1.1 volt
//#cldo_pwm=0x4 "\x00"
//#VCO freq 326.4MHz
"spurconfig=0x3" "\x00"
"\x00\x00";
#ifdef __cplusplus
} /* extern "C" */
#endif
#else /* ifndef INCLUDED_NVRAM_IMAGE_H_ */
#error Wi-Fi NVRAM image included twice
#endif /* ifndef INCLUDED_NVRAM_IMAGE_H_ */
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you receive this NVRAM file from Murata? Ideally, the issue you are facing should have been resolved by providing the correct LPO_IN clock. I am guessing this is some issue with the hardware connections in your setup.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
no, i copied from platform/BCM94343WWCD2/.
So you don't think the LPO_IN waveform amplitude too small is a issue?
My hardware connection is :
The wifi module is inserted to board's SD socket and WL_REG_ON is connected to a GPIO, and LPO_IN is connected to external OSC.
And after card is enumerated, bus width is 4bit, bus clock is 23.999MHZ.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ideally, you should use the nvram file supplied by your module partner only. I definitely think LPO_IN waveform amplitude is an issue in your setup. In the Cypress EVBs, standard amplitude for the sleep_clk is 3.3 V (Check the attached).
I have one more question. In your platform_config.h file, what is the status of WICED_USE_WIFI_32K_CLOCK_MCO macro? If it is commented out and LPO_IN grounded, you are trying to use the internal oscillator of the WLAN module for which you will need your module vendor to provide with the necessary nvram changes. If the macro is defined in your platform_config.h (i.e you are using the external sleep_clk), connect the proper clock pin from the host MCU and correctly declare WWD_PIN_32K_CLK in platform.c because this is being checked by WICED initialization sequence. (wiced_init -> wiced_wlan_connectivity_init -> wwd_management_wifi_on -> wwd_management_wifi_platform_init -> host_platform_init_wlan_powersave_clock -> (your host specific implementation)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have asked support from murata. And about the waveform amplitude issue, i tried with another external clock source which has a 3.3v amplitude, but when i connect it to LPO_IN, the waveform was pulled down to 1v around, i don't know why.
WICED_USE_WIFI_32K_CLOCK_MCO is commented out in my platform_config.h, i connected it to a external clock source directly and ignore the software sequence,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By the way, is there is some api in WICED which i can used to check the firmware downloaded is correct or not?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can enable WWD debug macros (WPRINT_WWD_ERROR or any other debug macros you need to do in wwd layer) mentioned in wiced_defaults.h to check the progress in wwd_bus_common.c. If the download is complete, you should see the fw version, clm version on your serial monitor (if you have set-up one in your system) or some other pointers like hosting softAP interface. But I feel the bottleneck in your setup is fixing the SLEEP_CLK issue, for which you have two options.
1) As you are commenting WICED_USE_WIFI_32K_CLOCK_MCO this out, you are implying WICED to use internal oscillator of the module for which you need nvram support from your module vendor
2) When you try to use the extetrnal oscillator, check on your host side based on the platform settings selected and the initialization steps done as mentioned in the earlier comment
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have recently published a help article on this topic. You can check the same STM32F469 porting in WICED
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Which module partner are you using? Have you approached them for help with the port and creation of a new BSP not currently supported within WICED?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you mean the wifi module?
Seems it is Murate Type1DX FS EVB P2ML3661A.