This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1835MOD: After downloading the FW, some chips report "fault_type = 3" in gLOGGER debug.

Part Number: WL1835MOD
Other Parts Discussed in Thread: WL1835

Hi,
We started producing a pcb board that uses WL1835MOD; the project seems to work well.
In the first four production batches (about 400pz) we found 32 pcb boards where WL1835MOD works badly.
At power up, WL18xx FW download is made and everything works correctly.
Subsequently, when i try to scan a wlan or connect to an AP, an error is reported in WL1835MOD and do not work.
On these boards we did both an electrical test and an X-ray inspection but we did not find any short-circuits or welding problems.
Analyzing with gLOGGER i see  "main_dump, fault_type = 3, pc = 0x00011b3a, SCR_PAD9 = 0x00000000,8008693a0000033a1b0100"; this is reported with other DEBUGs but I do not know how to understand the type of malfunction.
Do you have a list of gLOGGER error types?

By executing DMESG from commands promt, known "wlcore: ERROR SW watchdog interrupt received! Starting recovery" and more errors.

Attached is the gLOGGER LOG and the DMESG report.

I've analyzed SDIO, WL / BT_EN, 32kHz_osc, etc. etc. but do not detect malfunction.


The UART_DBG_BT and AUD_OUT_BT lines are configured for NORMAL MODE, ie UART_DBG_BT = 1 (Pull-UP 10k), AUD_OUT_BT = 0 (Pull-Down 10k).

Our system uses a i.MX6DL CPU with YOCTO 1.7 (KERNEL 3.14.28) and the BUSIO SDIO is set to 50Mhz.

Could you explain the meaning of the error "main_dump, fault_type = 3, pc = 0x00011b3a, SCR_PAD9 = 0x00000000,8008693a0000033a1b0100"?
Do you have any suggestions on where the problem may be with the cards that have this issue?

Many thanks,

Fabio

WL1835_LOG.zip

  • Hi ,
    - can you lower SDIO clk freq to 10MHz and check if you see the same issue
    - probe to see if WLAN_EN remains high after you bring up the wireless interface
    - probe to see if WLAN_IRQ is getting asserted

    Saurabh
  • https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/0537.wl18xx_2D00_fw_2D00_4.bin

    Hi,

    Can you try using the attached firmware file instead of the one you use now? Please rename it to wl18xx-fw-4.bin and update in /lib/firmware/ti-connectivity

    It is version 8.9.0.0.74 and contains a fix that we believe may address your issue. It is not officially release yet (still in test cycle) but we want you to try it out.

    BR,

    Eyal

  • Hi,
    At the beginning of May you sent me an internal release Rev 8.9.0.10.70; Has given us great improvements.
    The release Rev 8.9.0.0.74 that you are now proposing, is older or newer than Rev 8.9.0.10.70 that you sent me in early May?
    Do you have a change log?

    Many thanks,

    Fabio Boschi

  • Hi Fabio,

    The fix we gave you 8.9.0.10.70 that is now part of 8.9.0.0.74 which is planned to be the next official firmware.
    It is still in test cycle so you can give it a try now for confirmation or wait for it to be released officially.
    Once it is officially out it will also contain release notes with change log etc.

    Best Regards,
    Eyal
  • These are custom boards thath we have in production since March 2017.
    Apparently there are no differences between the first three devices and the fourth tried., but if the problem persists,I could do an X-Ray inspection to verify the welding joints of the WL1835MOD.
    Regarding FW 8.9.0.10.70, you sent it to me by email when I opened a support request in this post: e2e.ti.com/.../594207
    The FW was emailed to me by your European FAE.