Time out problem(The debugging issues between NUC972DF63YC and WiFi Hallow)

When streaming, a time out issue occurs after a period of time, as indicated by the red box in the screenshot.

It’s hard to say exactly what might cause this issue without more information.
The error is saying that something has happened which has caused the chip to not respond, or otherwise miss the health check command.

This could be caused by signal integrity issues on the SDIO lines. Verifying the data lines with an eye diagram is always a good first thing to check.

Additionally, attaching a high sample rate logic analyzer (~250MS/s is typical) on the SDIO and RESET lines and capturing the bus can help us identify if the chip isn’t responding, a response (or request) is corrupted, or a message is missed. Is this something you are able to capture?

Can you also share device tree files?

device_tree.rar (6.3 KB)
Hi,ajudge,i’m so glad for your reply.
the device tree files , ‌Please refer to the attachment.

HI @panhaojie
What mode is the device running in?
Are you able to get a logic analyser trace of the SDIO and RESET lines?

HI@ajudge
1、the device run in station mode.
2、The attachments are the SDIO and RESET diagrams.

These timing diagrams were captured while executing the flow.
thank you!

Thanks for sharing the captures! Are you able to share the dslogic files directly so I can scroll through the logic analyser capture?


Station devices typically enable powersave by default. Try to disable powersave to identify if there is something wrong with that configuration which is causing the device to enter sleep mode at the wrong time.
Early after boot (after the Morse module is inserted, and after the wlanX interface is created, run iw dev wlan0 set powersave off.

If this resolves the problem, then we can investigate the configuration of your powersave pins.

DSLogic PLus-la-250120-113824.part02.rar (25 MB)

We have made changes according to your suggestion and disabled the power-saving mode, yet the time-out problem still occurs

Hey @panhaojie , unfortunately these captures were made at 25 MHz not 250 MHz which makes it hard to distinguish the detail. Are you able to capture at the higher sample rate?

If you’re running 2.6.6 you can try adding this patch file to kernel/mm61xx/patches in morse_feed.

It will cause the chip not to restart on a single bad health check, but try again. This will let you see if you’re having intermittent issues or if it’s consistently failing the health check.

009-SW-12601-add-retries-for-the-health-check.patch (1.9 KB)

We try,but it doesn’work.

As in you’ve applied the patch, but the health check still fails?

yes,and the time that fail become short

----------Reply to Message----------

yes ,it still fail.and more is When we ping packets, the duration has become shorter.

DSLogic U3Pro16-la-250125-102321.part1.rar (25 MB)
DSLogic U3Pro16-la-250125-102321.part2.rar (25 MB)

DSLogic U3Pro16-la-250125-102321.part3.rar (25 MB)

DSLogic U3Pro16-la-250125-102321.part4.rar (3.4 MB)

《DSLogic U3Pro16-la-250125-102321》 is the board boot process capture data。

time out problem capture by logic analysis
DSLogic U3Pro16-la-250125-101852.part01.rar (20 MB)
DSLogic U3Pro16-la-250125-101852.part02.rar (20 MB)
DSLogic U3Pro16-la-250125-101852.part03.rar (20 MB)
DSLogic U3Pro16-la-250125-101852.part04.rar (20 MB)
DSLogic U3Pro16-la-250125-101852.part05.rar (18.0 MB)

@adjuge hi ,
i have upload the capture data by 250MHz sample rate