STM32F769NI + Murata SN8000 - Problem with high throughput clock.

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

cross mob
Anonymous
Not applicable

Hi,

Its my first post on wiced community.

I'm trying to port WWD driver on STM32F7 series (without full WICED SDK).

My platform is STM32F769NI + Murata SN8000 connected throug 1 BIT SDIO.  I use WWD + LWIP from WICED SDK ver. 3.7 + Murata patch for SN8xxx for ver. 3.7.

I try to run example FreeRTOS_LwIP_Scan.c example. At this moment I'm able to compile it.SDIO works with DMA and Interrupts. I pass all init functions with WWD_SUCCED including NVRAM and Firmware download.

But unfortunetly I stuck after core reset on SBSDIO_HT_AVAIL flag (I receive 0x40 status exept 0x80):

WWD_ERROR : "Timeout while waiting for high throughput clock\n"

I took nvram and firmware (43362A2_bin.c) from Murata patch.

Is this tis a problem with firmware files or chip revision?

0 Likes
1 Solution
Anonymous
Not applicable

I found solution for last problem on another topic. I had to increase high speed of sdio clock to 4 MHz and now core is working. Now I have to fix some os issues and everything should works Thanks for help.

View solution in original post

5 Replies
DaBa_2244756
Level 5
Level 5
25 likes received 10 likes received 10 likes given

Hi.

First try after write chunk, read chunk into other buffer and compare.

Anonymous
Not applicable

sqlsql_2244756 thanks for help, your advise was correct.

I made tests at low speed (CK = 100 kHz).

After each write:

result = wwd_bus_transfer_bytes( BUS_WRITE, BACKPLANE_FUNCTION, ( address & BACKPLANE_ADDRESS_MASK ), transfer_size, (wwd_transfer_bytes_packet_t*) sent );

I perform a read with:

result = wwd_bus_transfer_bytes( BUS_READ, BACKPLANE_FUNCTION, ( address & BACKPLANE_ADDRESS_MASK ),   transfer_size, (wwd_transfer_bytes_packet_t*) recv );

I sent/read buffer with size of 1024B in a 64B blocks.

And if I compare read and write buffer (sent / recv) at every try I get a few buffers, which are not equal. To simplify I send constant byte 0xAA.

If I get wrong unequal buffer for 1024 B I get usually about 20-30 B wrong in one pleace, like kind of short time disturbation.

I check SDMMC_STA_CCRCFAIL and SDMMC_STA_DCRCFAIL flags as in STM32F4 example but CRC flags are not set. And transfer function allways returns WICED_SUCCESFUL status.

My connection on PCB between Murata and host MCU is about 160mm-180mm length, but I checked timings  with oscilloscope and they are almost correct.

Is Cypress CYW43362 checking block crc after each cmd53 write? It looks like it get data with disturbation but it store it and resend stored data on read transfer.

0 Likes

Try flat connection cable  gnd sck vdd gnd data0 vdd ..... vbat and if possible shorted.

Better todo custom board.

Darius

Anonymous
Not applicable

I can't change wire length, it dependens on layout on pcb (this is first prototype), wchich was created by our team. I will try to force shorter lines on next revision.

But I found a reason why communication doesn't works properly on firmware/nvram download. This may be helpful for people who also works on STM32F7. STM32F7 uses additional cache for memory access and instructions to speed-up core performence. Its easy to find in reference manual that DTCM and ITCM Ram regions are not accessible through AHB/APB buses. This regions starts after 0x20000000.

So, at begining I moved all my buffers to SRAM1. But I didn't know that MPU unit allows to configure this region also as cacheable. I found solution in lin below:

Community:

https://community.st.com/thread/30147

Application note:

http://www.st.com/content/ccc/resource/technical/document/application_note/group0/08/dd/25/9c/4d/83/...

After disable cache on my buffers region, all data from firmware/nvram is 100% correct.

Due to my line length I had to slow down high speed communiction. It works correct with CK up to 1 MHz.

But I still have an issue with Murata core startup.

In function:

wwd_result_t wwd_bus_sdio_download_firmware( void )

We have core reset at beginig, next we write firmware image and nvram image and after we made second reset on core.

I have problem on second reset function. After setting SICF_CLOCK_EN flag in AI_IOCTRL, I get 0x00 on read junk from AI_IOCTRL. So core isn't working. Maybe someone has an idea to solve that issue?. On PCB I have grounded sleep clk.

0 Likes
Anonymous
Not applicable

I found solution for last problem on another topic. I had to increase high speed of sdio clock to 4 MHz and now core is working. Now I have to fix some os issues and everything should works Thanks for help.