cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

NoMa_3617641
New Contributor II

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.

connection.png

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".

sockettest3.png

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

0 Likes
7 Replies
PriyaM_16
Moderator
Moderator

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. 

NoMa_3617641
New Contributor II

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

0 Likes
PriyaM_16
Moderator
Moderator

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.

NoMa_3617641
New Contributor II

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

0 Likes
NoMa_3617641
New Contributor II

Hello,

Is there any update on this?

Is this issue fixed in the near future?

Regards,

Nobuhiro

0 Likes
MuraliR_36
Moderator
Moderator

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.

0 Likes
NoMa_3617641
New Contributor II

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

0 Likes