in NUC980,usiing fg, find espsta0,but application running,error.
Opened this issue · 20 comments
Hi,
we use hosted_fg, insmod esp32_sdio.ko,we can find espsta0.But.we run ./test.out get_ap_scan_list is error.we has test hoste_ng ,wifi is ok,but we need wifi ap,so we must use hosted)fg,help me.
980_fg_05071530.log
esp_fg_05071530.log
Hello @KenKang2015 ,
Have you checked port guide?
It is surprising to know that sdio is working in NG and not in FG. Both use same transport, so should not have seen any diff wrt transport as such.
From log,
esp32_sdio: esp_get_len_from_slave: Len from slave[1048519] exceeds max [1536]
esp32_sdio: read_packet: Rx large packet: 1048519
esp32_sdio: read_packet: Failed to read data - -22 [2047 - 1048064]
I can clearly conclude that timing of sdio are wrong. This might happen due to one or more reasons listed below.
Bootup event has received fine but next messages are experiencing problems, in either rx or tx direction.
-
You might be using a very high clock (max clock ESP32 can support is 50M). Check your device tree, what clock is used. Change Device Tree config and reload, if more than 50MHz. You can also override/hack the clock from device tree at
-
The external pull-ups are not connected or not sufficient (use 51KOhm - check port guide for expected pins)
-
Do not use jumper cables for connection.
Use PCB for sdio as the signal integrity is big issue for sdio protocol when used with jumper cables. Can you please share picture of your setup? -
If you must evaluate the solution with jumper cables only, test with lower clock and 1-bit mode. Although, external pull-ups are mandatory (check details in port guide)
-
Does your esp need efuse burning (most cases it needs) due to strapping pins collision with sdio pin?
Check : pull-up and efuse expectations -
You need to use same code base at ESP and host.
-
Device tree config could also be helpful (we can only check any obvious error, as it differs greatly Linux to Linux SoC)
- As you already stated, the NG worked whereas FG did not, it is also worth to check your connections (if jumper cables used), to be firm.
Reason I state, the slave received start-data-path but is not able to see any message sent from host on D0-D3 lines.
regarding (1) above, you can also check the current clock speed using command:
sudo cat /sys/kernel/debug/mmc0/ios
Assuming from the log, mmc0 represents ESP SDIO.
Hi mantriyogesh,
1
Hello @KenKang2015 ,
Have you checked port guide? It is surprising to know that sdio is working in NG and not in FG. Both use same transport, so should not have seen any diff wrt transport as such.
From log,
esp32_sdio: esp_get_len_from_slave: Len from slave[1048519] exceeds max [1536] esp32_sdio: read_packet: Rx large packet: 1048519 esp32_sdio: read_packet: Failed to read data - -22 [2047 - 1048064]I can clearly conclude that timing of sdio are wrong. This might happen due to one or more reasons listed below. Bootup event has received fine but next messages are experiencing problems, in either rx or tx direction.
- You might be using a very high clock (max clock ESP32 can support is 50M). Check your device tree, what clock is used. Change Device Tree config and reload, if more than 50MHz. You can also override/hack the clock from device tree at
- The external pull-ups are not connected or not sufficient (use 51KOhm - check port guide for expected pins)
- Do not use jumper cables for connection.
Use PCB for sdio as the signal integrity is big issue for sdio protocol when used with jumper cables. Can you please share picture of your setup?- If you must evaluate the solution with jumper cables only, test with lower clock and 1-bit mode. Although, external pull-ups are mandatory (check details in port guide)
- Does your esp need efuse burning (most cases it needs) due to strapping pins collision with sdio pin?
Check : pull-up and efuse expectations- You need to use same code base at ESP and host.
- Device tree config could also be helpful (we can only check any obvious error, as it differs greatly Linux to Linux SoC)
- I am certain that I have reduced the SDIO speed to 5M, as shown in the figure below;
- I am using a 10K pull-up resistor, which works fine in hosted_ng;
- I am not using jumper wires; it's the PCB board of the final product;
- I am confident that we have performed efuse burning;
- It's the same project, on the master branch;
Where can I add logs to clearly determine whether the module did not receive it, or the nUC980 did not transmit it;
This issue has been bothering us for six months now, seriously affecting the progress of the product. Please help resolve it as soon as possible.
"#if 1 /* in case to lower sdio clock speed by ken*/
host = func->card->host;
host->ios.clock = 5*1000000; //5MHz
host->ops->set_ios(host, &host->ios);
#endif"
(2) 10k is also fine
(6) Can you please test on master both sides?
- Is this issue always happening or intermittent?
Host:
Slave:
Similar log at
esp-hosted/esp_hosted_fg/esp/esp_driver/network_adapter/main/app_main.c
Lines 381 to 382 in 040cfdb
Host:
Slave:
Similar log at
esp-hosted/esp_hosted_fg/esp/esp_driver/network_adapter/main/app_main.c
Lines 381 to 382 in 040cfdb
hi ，mantriyogesh
The code for these log segments is already present in the original SDK.。
These are ignored as default log level is set to info level.
These logs can be modified from debug/verbose to info level to get transport level logs.
These are ignored as default log level is set to info level.
These logs can be modified from debug/verbose to info level to get transport level logs.
Do you mean "i need modify the log level is debug or verbose for host and slave"?
Either is okay.
If you just need transport level stats, modifying the above logs as current log level (info) should be sufficient.
If you change log level, it may include more messages including transport logs, is also okay for debugging.
hi，mantriyogesh
I modified the log level of the code on both the master and slave, turning on the debug level. After testing, I found that the network interfaces such as ethsta0 and ethap0 did not appear on the master side after loading esp32_sdio.ko. Attached is the log.
2 When reverting to the previous firmware on the slave side for testing, while keeping the modifications on the master side, I can see ethsta0 and ethap0. However, when trying to bring up ethsta0 with 'ifconfig ethsta0 up', it prompts 'ifconfig: SIOCSIFFLAGS: Cannot assign requested address'.
esp32_24051.log
nuc980_240521.log
From the logs in #379 (comment), The sdio is trying to connect, but host has not understood the msg. This was init msg sent from slave to host. I still suspect something wrong at your hardware.
on the master side, I can see ethsta0 and ethap0.
From log I can't see any ethsta0 or ethap0 in your 'ifconfig -a' output. Could you please include those logs?
But you claimed the ng works and FG doesn't, can you post the output of NG , both sides, to understand the scenario?
--Edited--
hi
I powered the device via the debugging interface with DC5V, and I was able to retrieve the surrounding access points using ./test.out get_ap_scan_list. This confirms that the host E-FG is functioning properly at a preliminary level.
Now, I need to know how to use these commands: 1 Connect to a specified WiFi AP; 2 Test the network via socket or ping; 3 Set the WiFi module to AP mode and connect to it; 4 Bluetooth broadcasting from the module, mobile connections can communicate. How should I operate these tests?
this is the test log
Okay great.
The image link is broken in your last post.
Anyway, I assume that you have ported the driver.
Before moving to application, it is worth to see the raw transport throughout you get.
Raw_TP_Testing
Test this in both rx and tx directions.
Moving on to the demo app, if your Linux supports python, it would be extremely easy to follow python_demo_app. This contains fancy feature set, by the python power.
Most likely you would be desiring a c based application, which is c_demo_app
In these apps, you can issue control commands, get responses and notifications. Connect to ap or start an softap etc would be handled through control path, which is protobuf serialised. Detailed control path
Also API description: ctrl_apis
Okay great.
The image link is broken in your last post. Anyway, I assume that you have ported the driver.
Before moving to application, it is worth to see the raw transport throughout you get. Raw_TP_Testing Test this in both rx and tx directions.
Moving on to the demo app, if your Linux supports python, it would be extremely easy to follow python_demo_app. This contains fancy feature set, by the python power.
Most likely you would be desiring a c based application, which is c_demo_app
In these apps, you can issue control commands, get responses and notifications. Connect to ap or start an softap etc would be handled through control path, which is protobuf serialised. Detailed control path
Also API description: ctrl_apis
The description of c_demo_app seems to lack details on how to use BLE.
Bluetootth is not controlled through c_demo.
For Bluetooth, refer: https://github.com/espressif/esp-hosted/blob/master/esp_hosted_fg/docs/Linux_based_host/Getting_started.md
If you follow https://github.com/espressif/esp-hosted from start, you would be automatically landing in corresponding documentation.
For bluetooth, please note, the hciconfig and hcitool etc bluetooth looks are marked obsolete. So try to use the tools supported by BlueZ in upstream.
when i use nRF connect app connect esp32 moudle ,i do this work, "[56-CB-99-D7-6D-79]# list
Invalid command in menu gatt: list
Use "help" for a list of available commands in a menu.
Use "menu " if you want to enter any submenu.
Use "back" if you want to return to menu main.
[56-CB-99-D7-6D-79]# list-attributes
Primary Service (Handle 0x0000)
/org/bluez/hci1/dev_56_CB_99_D7_6D_79/service0001
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
Characteristic (Handle 0x3290)
/org/bluez/hci1/dev_56_CB_99_D7_6D_79/service0001/char0002
00002a05-0000-1000-8000-00805f9b34fb
Service Changed
Primary Service (Handle 0x962c)
/org/bluez/hci1/dev_56_CB_99_D7_6D_79/service0028
2c042b0a-7f57-4c0a-afcf-1762af70257c
Vendor specific
Characteristic (Handle 0xacb8)
/org/bluez/hci1/dev_56_CB_99_D7_6D_79/service0028/char0029
bda65297-d43b-4e22-b424-012345678900
Vendor specific
Characteristic (Handle 0xacb8)
/org/bluez/hci1/dev_56_CB_99_D7_6D_79/service0028/char002b
bda65297-d43b-4e22-b424-012345678901
Vendor specific
Characteristic (Handle 0xacb8)
/org/bluez/hci1/dev_56_CB_99_D7_6D_79/service0028/char002d
982a921c-c083-47ea-b6be-f2d637969d91
Vendor specific
Characteristic (Handle 0xacb8)
/org/bluez/hci1/dev_56_CB_99_D7_6D_79/service0028/char002f
5aa977ef-aa32-4e4d-8f45-e381dc479eea
Vendor specific
[56-CB-99-D7-6D-79]#
[56-CB-99-D7-6D-79]# select-attribute 0xacb8
[56-CB-99-D7-6D-79]# write 0xacb8 11223344
No attribute selected
[56-CB-99-D7-6D-79]#
"
i want send some date to nRF connect app in iphone.,but is not. please help me.
Hello @KenKang2015 ,
We had listed the example in getting started guide. But the user space apps have no direct relation and the use case varies a lot per user.
For app related issues, you can find help from BlueZ.
Sorry, but our scope and knowledge is limited.
If the issues are at Bluetooth controller level (with the detailed showcase of logs) we can involve controller team. But the turnaround time increase a lot in this case.
Any hosted related issues or even the issues in our knowledge, we will be certain to help with.
FG supports softap directly using commands in control path, have you checked? Hostapd is not supported with FG. Softap is stable and configured from demo app in FG.
hostapd would be supported in NG in future. Right now it is in evaluation phase. Details could be found in issue 387