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

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

cross mob
rzec_3016261
Level 3
Level 3
First like received

Hallo all,

Still debugging our own platform.

Hardware:

  • my own (STM32F756 + CYW4343WKUBG)
  • bus used == SDIO

Software:

  • WICED-Studio-6.2-SDK
  • no IDE, just makefiles [ ./make snip.scan-MYPLF-FreeRTOS-LwIP download run ]

Try to initialize our board, but now I'm stuck in

./WICED/WWD/internal/bus_protocols/SDIO/wwd_bus_protocol.c at

     while ( ( ( result = wwd_bus_read_register_value( BUS_FUNCTION, SDIOD_CCCR_IORDY, (uint8_t) 1, &byte_data ) ) == WWD_SUCCESS ) &&

             ( ( byte_data & SDIO_FUNC_READY_2 ) == 0 ) &&

             ( loop_count < (uint32_t) F2_READY_TIMEOUT_MS ) )

     {

         (void) host_rtos_delay_milliseconds( (uint32_t) 1 ); /* Ignore return - nothing can be done if it fails */

         loop_count++;

     }

     if ( loop_count >= (uint32_t) F2_READY_TIMEOUT_MS )

     {

         /* If your system fails here, it could be due to incorrect NVRAM variables.

          * Check which 'wifi_nvram_image.h' file your platform is using, and

          * check that it matches the WLAN device on your platform, including the

          * crystal frequency.

          */

(BTW: byte_data == SDIO_FUNC_READY_1 at this point)

So the suggestion is that we should tune the wifi_nvram_image.h file to match our platform but answers in these links suggest don't touch the wifi_nvram_image.h file:

- https://community.cypress.com/thread/1187

- https://community.cypress.com/thread/1806

In this link https://community.cypress.com/community/wiced-wifi/wiced-wifi-forums/blog/2018/10/10/stm32f469-porti... it states:

c. wifi_nvram_image.h: This is the nvram file for the WLAN module. This is supplied by the module partner.

However if we compared the wifi_nvram_image.h file included in the WICED-Studio-6.2-SDK platforms with a similar chip set:

WLAN_CHIP              := 4343W

WLAN_CHIP_REVISION     := A1

WLAN_CHIP_FAMILY       := 4343x

BT_CHIP                := 43438

BT_CHIP_REVISION       := A1

BT_CHIP_XTAL_FREQUENCY := 37_4MHz

  1. BCM94343WWCD2 (26MHZ)
  2. CY8CKIT_062   (37_4MHZ)
  3. NEB1DX_01     (37_4MHZ)

Comparing 1,2 and 3 shows they are all different, parameters are included or excluded or have different values.

Same chip set but different wifi_nvram_image.h. We tried them all but no luck. Does not make sense...

We have designed our own platform with the same chip-set (4343W) and need (?? or not) to change/match the wifi_nvram_image.h file. Question is how?

We have no idea what each parameter means ( besides the xtalfreq= ).

Or are there any other suggestion why F2 is not ready?

Used: GLOBAL_DEFINES += SLOW_SDIO_CLOCK

This looks like a similar questions:

- https://community.cypress.com/message/22196

- https://community.cypress.com/message/24685

both unanswered.

0 Likes
1 Solution

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.

View solution in original post

0 Likes
11 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

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.

Hello, thanks for your answer.

If my schematic is for 99% identical to the radio page of the BCM94343WWCD2, do the NVRAM parameters still need updating?

The 1% is that I use a 37.4Mhz crystal (changed that in the parameters).

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

Any way how do I go about it, if we want to organise a review by Cypress to tune the nvram parameters.

0 Likes

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 .

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 .

Sorry?!?! My English must be insufficient to understand this.

Cypress will sell its chip on the "open market" but can't be bothered to support its customers? I'm working on a 100K+ annual application and the advice given here is "please choose an other manufacturer" ???

Really?

Know any good ones?

0 Likes

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.

0 Likes

OK, same question. How do I start this review process?

0 Likes

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.

0 Likes

Well, things are communicated properly, you state the same. Share all information about your application with us and Cypress might share some information, somewhere in the future, with you to get your application up and running, if Cypress decides it wants you as a customer.

Thanks for the guide but my design constraints rules-out any module.

I still don't understand why the CYW4343W chip is sold by a lot of distributors if Cypress doesn't want anyone to use the chip. But that is my problem.

I will try to get in touch with a local FAE/Sales team, to resolve the issue on this version of the application.

0 Likes

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

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

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 have read the post, you mention, many times and followed the advice given.

Running the SDIO clock at as low as 800Khz and disabling the SDIO_MASK_SDIOITIE, I would expect a FIFO underflow is not the cause.

But in all fairness I did not yet check the STA register. Will do that.

Cool learned a new English word: Excerpt 🙂