Add a new platform in WICED

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ccc_1322726
Level 2
Level 2
First like received First like given

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!

1 Solution
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

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.

View solution in original post

24 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

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.

Video Link : 1543

0 Likes
RaktimR_11
Moderator
Moderator
Moderator
500 replies posted 250 replies posted 100 replies posted

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.

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

pastedImage_0.png

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?

0 Likes

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.

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.

0 Likes

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!

0 Likes

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

0 Likes

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?

0 Likes

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.

0 Likes

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.

0 Likes

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.

0 Likes

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.

0 Likes

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?

0 Likes

Please attach your nvram file (wifi_nvram_image.h) which should be a part of your platform directory for further debugging

0 Likes

/** @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_ */

0 Likes

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.

0 Likes

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.

0 Likes
lock attach
Attachments are accessible only for community members.

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)

0 Likes

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,

0 Likes

By the way, is there is some api in WICED which i can used to check the firmware downloaded is correct or not?

0 Likes

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

0 Likes

We have recently published a help article on this topic. You can check the same STM32F469 porting in WICED

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?

0 Likes

Do you mean the wifi module?

Seems it is Murate Type1DX FS EVB P2ML3661A.

0 Likes