- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- BCM94343WWCD2 (26MHZ)
- CY8CKIT_062 (37_4MHZ)
- 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.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello:
Let me explain the boards type you mentioned in the threads:
- BCM94343WWCD2 (26MHZ)
A: From circuit provided this is a COB evb with 26M cystal oscillator , Part number is 4343WKUBG.
- CY8CKIT_062 (37_4MHZ)
A: evb with murata module included , 37.4M cystal oscillator included , this is CY evb board.
- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, same question. How do I start this review process?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 🙂