- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
On CYW943907AEVAL1F, interrupt latency sometimes getting longer.
Usually, it's approx 2-3us, but every 2-10 seconds get 30-100us.
In my project, CPU must respond within several microseconds.
Therefore this long latency is a issue to be solved.
How can I make the latency at around 3us constantly?
Sample program is attached.
Tools
- Windows 10 PC
- CYW943907AEVAL1F
- WICED-Studio 6.4.0.61 on Windows
- SocketTest v3.0 http://sockettest.sourceforge.net/
- Wi-Fi Access Point
- Jump wire 1pc
The connection diagram is shown below.
Usage
1) Power on Wi-Fi AP.
2) Using jump wire, connect J10.7 to J12.4 on CYW943907AEVAL1F.(J10.7=PWM4 output, J12.4=interrupt input)
3) Run SocketTest3 on Windows PC, it acts as a TCP Server.
4) Connect CYW943907AEVAL1F to Windows PC with USB cable.
5) Run TeraTerm, and connect CYW943907AEVAL1F via Serial port.
6) Type "join <AP SSID> wpa2_aes <Password>" on TeraTerm.
> join IoT-2G-01-1943 wpa2_aes PASSWORD
Joining : IoT-2G-01-1943
Successfully joined : IoT-2G-01-1943
Obtaining IPv4 address via DHCP
L1420 : dhcp_client_init() : DHCP CLIENT hostname = [WICED IP]
IPv4 network ready IP: 192.168.3.100
Setting IPv6 link-local address
IPv6 network ready IP: FE80:0000:0000:0000:A608:EAFF:FED9:CE58
7) Windows PC connects to the Wi-Fi AP.
😎 Set up SocketTest3 as a TCP Server. The IP address=X.X.X.X and Port=5001, and click "Start Listening".
9) Type "start -c X.X.X.X" on TereTerm, then start data transmission.
10) The interrupt latency information are displayed on TeraTerm.
exceed_cnt increments when exceeds threshold.
exceed_val shows interrupt interval when exceeds threshold.
> start -c 192.168.3.101 -n 100
wiced_tcp_connect start
> wlan_send_countdown=99, exceed_cnt=37, exceed_val=76100ns
wlan_send_countdown=98, exceed_cnt=37, exceed_val=76100ns
wlan_send_countdown=97, exceed_cnt=38, exceed_val=91250ns
wlan_send_countdown=96, exceed_cnt=38, exceed_val=91250ns
wlan_send_countdown=95, exceed_cnt=38, exceed_val=91250ns
wlan_send_countdown=94, exceed_cnt=38, exceed_val=91250ns
wlan_send_countdown=93, exceed_cnt=38, exceed_val=91250ns
wlan_send_countdown=92, exceed_cnt=39, exceed_val=91250ns
wlan_send_countdown=91, exceed_cnt=39, exceed_val=91250ns
wlan_send_countdown=90, exceed_cnt=41, exceed_val=75550ns
wlan_send_countdown=89, exceed_cnt=41, exceed_val=75550ns
wlan_send_countdown=88, exceed_cnt=41, exceed_val=75550ns
wlan_send_countdown=87, exceed_cnt=41, exceed_val=75550ns
wlan_send_countdown=86, exceed_cnt=42, exceed_val=91025ns
wlan_send_countdown=85, exceed_cnt=42, exceed_val=91025ns
...
wlan_send_countdown=3, exceed_cnt=55, exceed_val=75725ns
wlan_send_countdown=2, exceed_cnt=55, exceed_val=75725ns
wlan_send_countdown=1, exceed_cnt=56, exceed_val=75650ns
wlan_send_countdown=0, exceed_cnt=56, exceed_val=75650ns
Regards,
Nobuhiro
- Labels:
-
Interrupts
-
TCPIP
-
WICED Studio
-
Windows
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I believe the main problem is for interrupt latency. The PWM_4 and GPIO_6 are used for testing the same in your setup. I would recommend testing the interrupt generation and intrCallback only and comment out rest of the code to make sure interrupt processing is not affected by other thread.
Also it will be helpful if you would explain the code a bit(exceed_cnt ,exceed_val, how the other data thread can affect applcation thread ). The wiced_rtos_get_semaphore() call in txDataTask fucntion is waiting to acquire the semaphore. This might result in the delay between the threads scheduling(application thread where interrupt is processed and txDataTask thread) and so the interrupt latency might be affected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for your reply.
According to your advice, I simplified my sample code.
- Removed semaphore
- Improved messages
- Message is displayed only when unexpected interval is detected.
Interrupt intervals are measured in ISR.
ISR has the highest priority.
Of course, some APIs might prevent the interrupt response...
Normaly, in this program, the interrupt intervals are about 15-16us.
But sometimes getting longer.
This issue happens during Wi-Fi transmission.
Sample code is attached.
--
Starting WICED Wiced_006.004.000.0061
Platform CYW943907AEVAL1F initialised
Started ThreadX v5.8
WICED_core Initialized
Initialising NetX_Duo v5.10_sp3
Creating Packet pools
WLAN MAC Address : A4:08:EA:D9:CE:58
WLAN Firmware : wl0: May 2 2019 02:34:15 version 7.15.168.130 (r714231) FWID 01-7fc7cd46
WLAN CLM : API: 12.2 Data: XXX Compiler: 1.31.3 ClmImport: 1.36.3 Customization: v1 16/12/02 Creation: 2019-05-23 06:58:32
> join IoT-2G-01-1943 wpa2_aes PASSWORD
Joining : IoT-2G-01-1943
Successfully joined : IoT-2G-01-1943
Obtaining IPv4 address via DHCP
L1420 : dhcp_client_init() : DHCP CLIENT hostname = [WICED IP]
IPv4 network ready IP: 192.168.3.101
Setting IPv6 link-local address
IPv6 network ready IP: FE80:0000:0000:0000:A608:EAFF:FED9:CE58
> start -c 192.168.3.100
wiced_tcp_connect start
> Unexpected longer interrupt interval detected at wlan_send_countdown=99, exceed_cnt=2, interval=91150ns
Unexpected longer interrupt interval detected at wlan_send_countdown=98, exceed_cnt=4, interval=91400ns
Unexpected longer interrupt interval detected at wlan_send_countdown=94, exceed_cnt=5, interval=91200ns
Unexpected longer interrupt interval detected at wlan_send_countdown=90, exceed_cnt=6, interval=91275ns
Unexpected longer interrupt interval detected at wlan_send_countdown=85, exceed_cnt=7, interval=75800ns
Unexpected longer interrupt interval detected at wlan_send_countdown=82, exceed_cnt=8, interval=91050ns
Unexpected longer interrupt interval detected at wlan_send_countdown=81, exceed_cnt=9, interval=75925ns
Unexpected longer interrupt interval detected at wlan_send_countdown=79, exceed_cnt=10, interval=76050ns
Unexpected longer interrupt interval detected at wlan_send_countdown=66, exceed_cnt=11, interval=76025ns
Unexpected longer interrupt interval detected at wlan_send_countdown=62, exceed_cnt=12, interval=91125ns
Unexpected longer interrupt interval detected at wlan_send_countdown=61, exceed_cnt=13, interval=91075ns
Unexpected longer interrupt interval detected at wlan_send_countdown=54, exceed_cnt=14, interval=75775ns
Unexpected longer interrupt interval detected at wlan_send_countdown=52, exceed_cnt=15, interval=30350ns
Unexpected longer interrupt interval detected at wlan_send_countdown=51, exceed_cnt=16, interval=91375ns
Unexpected longer interrupt interval detected at wlan_send_countdown=50, exceed_cnt=17, interval=76175ns
Unexpected longer interrupt interval detected at wlan_send_countdown=49, exceed_cnt=18, interval=91025ns
Unexpected longer interrupt interval detected at wlan_send_countdown=45, exceed_cnt=19, interval=30425ns
Unexpected longer interrupt interval detected at wlan_send_countdown=43, exceed_cnt=20, interval=91225ns
Unexpected longer interrupt interval detected at wlan_send_countdown=42, exceed_cnt=21, interval=91125ns
Unexpected longer interrupt interval detected at wlan_send_countdown=39, exceed_cnt=22, interval=91350ns
Unexpected longer interrupt interval detected at wlan_send_countdown=32, exceed_cnt=23, interval=91075ns
Unexpected longer interrupt interval detected at wlan_send_countdown=30, exceed_cnt=24, interval=74950ns
Unexpected longer interrupt interval detected at wlan_send_countdown=23, exceed_cnt=25, interval=76550ns
Unexpected longer interrupt interval detected at wlan_send_countdown=15, exceed_cnt=26, interval=91075ns
Transmission finished
Regards,
Nobuhiro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
The thread in which TCP transmission is happening is the reason for the ISR latency. The data traffic is usually bursty in nature and might take up more time to process. This processing time results in the delay in the ISR thread.
If you could explain the end goal in your application, we can try to brainstorm a different way of writing the current application.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for your reply.
In my app, App CPU reads the sensor value every 15us in ISR.
The timing signal is output by PWM4 as same as the sample code.
So, the ISR must respond in several micro-seconds to the signal.
App CPU sends the data chunk using WLAN TCP sesseion every 160ms.
Regards,
Nobuhiro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Is there any update on this?
Is this issue fixed in the near future?
Regards,
Nobuhiro
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello
Is it necessary to use an ISR to read the sensor value?
Is it possible to use multi-threading? If so, could you try defining 2 threads, where 1 thread will handle reading value from the sensor and another thread will handle TCP transmission. The thread used to read the ISR can be defined with a higher priority.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Thanks for your reply.
In my project, sensor has no buffer.
Thus, in order to capture the sensor data, need ISR.
This issue is in ISR repsponse latency, not in multi threading, I think.
In somewhere in the Wi-Fi transmission process, interrupt is inhibited for a long time (a few 10us), isn't it?
Regards,
Nobuhiro