How to tune wifi_nvram_image.h? OR Why F2 is not ready?

Hello:

  Let me explain the boards type you mentioned in the threads:

1. BCM94343WWCD2 (26MHZ)

     A： From circuit provided  this is a COB evb with 26M cystal oscillator , Part number is 4343WKUBG.

1. CY8CKIT_062   (37_4MHZ)

     A:  evb with murata module included ,  37.4M  cystal  oscillator included , this is CY evb board.

1. NEB1DX_01     (37_4MHZ)

     A:  This is Nebula kit for wiced  from Future Electronics with murata module provided.

Why the nv is different , because NV needs to change  calibration parameters,  if using different RF control logic , we need to change the corresponding parameters also.   So these are the reasons of the difference.

    For such a COB project I think  normal process is to send the circuit to us by case system to have a review,  then ask Hardware engineer to update one nvram according your circuit.  

   Then we can exclude the NV reason of F2 failure.

Since you are using the same chip with BCM94343WWCD2 ,  suggest  having a compare to the reference circuit in the release in first step.

We have mentioned some ways to debug the issue in STM32F469 porting in WICED

Excerpt: If you are getting stuck in F2, FIFO underflow could be a probable cause. Check the SDIO_STA (interrupt status) register to debug the issue. You can check wwd_sdio.c and wwd_bus_protocol.c. You can consider disabling the interrupt received flag SDIO_MASK_SDIOITIE from the SDIO mask register in STM32F4xx/WWD/wwd_sdio.c. In that case, the function wwd_bus_packet_available_to_read() would have to be commented out because this function would check for interrupt by reading the IntStatus register of the WLAN chip.

Check the patch attached in the blog post, if you have any difficulty in understanding the above statements.

Hello：

I would understand it if incorrect parameters would make the radio not perform at its best but not functioning at all?

A:  Yes,  RF control logic will not influence function part like interface communication.

   Actually, COB project really needs a review by our marketing team,  We always insist that customers adopt module solutions on open market , it will save  debug efforts .

hello:

    Ok,  I know your meaning.   For COB project it really need a review ,  and better to be supported from our case system, thanks.

and if we have sales or FAE to track the opportunity ,  we will provide better support resource.

Some things are not being communicated properly here.

WiFi chip down designs are notoriously complex and support intensive both from a hardware and software perspective.  As such, we have deployed a large ecosystem of module partners that provide fully certified modules with extensive internal support and expertise on their fully tested hardware and custom firmware/software solutions.

With that said, there may be instances where chip down designs make sense from a volume perspective, but those engagements are not typical of a broad market engagement and should be managed through our local FAE/Sales teams as opposed to the community, which is designated Broad Market support.

Our module partners and their associated solutions are listed here in the IoT Solutions Guide