I am testing the AnyCloud TCP Server example project for CY8CPROTO-062-4343W. Inside the tcp_receive_msg_handler(cy_socket_t socket_handle, void *arg) function (I pasted it below), I found that there was about <1s delay when calling the API cy_socket_recv(). I toggled the user LED right before and after calling this API and I found that the delay of calling this function was quite significant. The tcp_receive_msg_handler is called whenever it receives some messages from the TCP client. I tried different message lengths from the client but the delay was quite consistent.
API cy_socket_recv() should just read the buffer and I am wondering why it took that long.
I am working on an application which requires the device (uses the same PSoC6 MCU and the same Wi-Fi/BT chip) to use Wi-Fi communication and act as a TCP server. So I used the AnyCloud TCP Server example project as the basic code structure. The device needs to read something from the client and then take some action as quickly as possible. The long delay of calling cy_socket_recv() is not acceptable for my application.
Any idea how to get rid of the delay? Maybe there is another API which is better in terms of response time?
From AnyCloud TCP Server example project:
static cy_rslt_t tcp_receive_msg_handler(cy_socket_t socket_handle, void *arg)
/* Variable to store number of bytes received from TCP client. */
uint32_t bytes_received = 0;
result = cy_socket_recv(socket_handle, message_buffer, MAX_TCP_RECV_BUFFER_SIZE,
CY_SOCKET_FLAGS_NONE, &bytes_received); // Long delay when calling this
if(result == CY_RSLT_SUCCESS)
/* Terminate the received string with '\0'. */
message_buffer[bytes_received] = '\0';
printf("\r\nAcknowledgement from TCP Client: %s\n", message_buffer);
/* Set the LED state based on the acknowledgement received from the TCP client. */
if(strcmp(message_buffer, "LED ON ACK") == 0)
led_state = CYBSP_LED_STATE_ON;
led_state = CYBSP_LED_STATE_OFF;
printf("Failed to receive acknowledgement from the TCP client. Error: 0x%08"PRIx32"\n",
if(result == CY_RSLT_MODULE_SECURE_SOCKETS_CLOSED)
/* Disconnect the socket. */
printf("Press the user button to send LED ON/OFF command to the TCP client\n");
I have a server tcp socket connected to a client.
I want to get ip address of the client.
Here the code.
status = wiced_tcp_create_socket ( &tcp_socket_msg, WICED_AP_INTERFACE );
if ( status != WICED_SUCCESS )
WPRINT_APP_INFO( ("wiced_tcp_create_socket failed, status = %d\n", status) );
status = wiced_tcp_listen ( &tcp_socket_msg, 50002 );
if ( status != WICED_SUCCESS )
WPRINT_APP_INFO( ("wiced_tcp_listen failed, status = %d\n", status) );
wiced_tcp_delete_socket ( &tcp_socket_msg );
status = wiced_tcp_accept ( &tcp_socket_msg );
if ( status == WICED_SUCCESS )
WPRINT_APP_INFO( ("wiced_tcp_accept ok!\n") );
WPRINT_APP_INFO( ("wiced_tcp_accept failed, status = %d\n", status) );
} while ( status == WICED_TCPIP_SOCKET_CLOSED );
HOW GET TCP CLIENT ADDRESS FROM tcp_socket_msg ???
I am new to development on the PSoC platform and I am attempting to configure UART on this device. It is a PSOC5LP - 050 board. I'm unable to configure the COM port I am supposed to read it on, because it does not show anything on device manager about which virtual COM port I should connect.
I am able to program other components and I have already worked on a few applications which are working fine. Sending a screenshot of my device manager. On PSOC programmer also, the Upgrade firmware option is 'greyed-out'. Any advice is appreciated.
EDIT: I have checked the example documentation and connected the RS-232 with the related Pinouts to the Rx and Tx pin and still nothing appears on my COM port.Show Less
Our FPGA may send variable length data(4B~16kB, integral multiple of 4Bytes) to FX3 in which firmware runs as slave FIFO mode, host app invoke XferData() to initiate a BULKIN transfer for reading data stored in FX3.
At each BULKIN event initiated by host, a certain len parameter must be passed into XferData() refer to Cypress CyAPI Programmer's Reference, for example 16384, if actual length of packet which sent by FX3 is shorter than 16384(ie partial packet), will XferData() receive the short length packet and return ture or return false for time-out? if this function can receive short packet, where can i get the actual length after the XferData() executed ?Show Less
Here`s a strange problem, XferData() may failed when slave endpoint sent a short packet with a particular length.
we`re trying to transfer data from FPGA to PC host by FX3, FX3 runs with a slave FIFO firmware, EP2 IN(0x82) is initiated in FX3 for BULK IN transferring, in each transfer test, firstly, PC host invoke XferData() to generate a BULKIN transfer(bufLen is always set 16384, pktMode is set TRUE) and waiting for a packet from FX3, then our FPGA send a short packet to FX3, at each test,packet length is different, short packet is ended by asserted the PKT_END pin .
XferData() return TRUE in most of tests, but failed at several test, after research of these failed tests, we found that if FPGA send packet with length of 2048,4096 or 8192, XferData() retrun FALSE and timed out happened, such a werid thing. any body can help me ?
BTW, these two results may help you:
1.XferData() can be successful when actual length is 8191 or 8193, but if FPGA send 8192 bytes to FX3, XferData() must be failed.
2.if we set 8192 to bufLen parameter, XferData() return TRUE when FPGA send 8192 bytes to FX3.
here`s main part of BULKIN transfer code at PC host side(VS2013):
Sorry to bother you again.
After the last /RD signal problem was solved, no more underrun error.
But recently, all system combined test, I received error "No error : 18" from CY3014 uart port ,then, Xfer to FPGA failed.
Please kindly advise what is "No error : 18" ?
I am using PSOC6 PROTOTYPEKIT BOARD 。
I am using a Verilog file for DS18B20 testing (I got it from a test in Altera Cyclone IV and it works well). But the file cannot be built in PSOC Creator 4.3
The Screenshot in PSOC Creator 4.3.
The errors occurred in building
It seems that the PSOC Creator 4.3 cannot interpret the line 171
Can't handle expression 'Z' in the final equation for 'org_data(0)'.
And I do not know how to solve it.
And I wonder whether the Verilog syntax in PSOC Creator 4.3 is just a subet of the Verilog syntax in general.
Thanks in advance.Show Less
"AN65974.zip"-> "FX3 Firmware"-> "Slave Fifo Sync"
→ There is the following description on line 892 of "cyfx slfifosync"
io_cfg.gpioSimpleEn  = 0;
io_cfg.gpioSimpleEn  = 0x08000000; / * GPIO 59 * /
io_cfg.gpioComplexEn  = 0;
io_cfg.gpioComplexEn  = 0;
What will happen to the terminal state when all gpioSimpleEn are set to 0 (disabled)?
Q2-1) I think that the GPIO_SIMPLE register setting described on P.590 of FX3 TRM corresponds to the terminal setting in this case. Is this correct? if so, would like to know the terminal status and necessary terminal processing in that case.
Q2-2) I think that DRIVE_HI_EN: 0 is a tri-state output if the initial value of the register. Is this correct?
Q2-3) Is it okay if external terminal processing is not required in the case of tri-state?
Please answer each question mentioned above?
I want to run a behavioral simulation of S29GL01GP.The secotor had been erased，and programed in word mode.But the data which be read from flash is 16'hXX2X.AS shown in the follow picture:
What‘s wrong in this timing sequence?
I'm trying to flash a ARS6501 device (PSoC CY8c4147azi-s445 inside) using CMSIS-DAP and PSoC Programmer 3.29.0
The SWD adapter is detected by the programmer, however, the device is never acquired. I tried multiple times, with different CMSIS-DAP versions (v1, v1.1 and v2.0) but none worked! I always get "FAILED! PSoC device is not acquired! Check connection of the chip to the programmer..." error.
I checked all connections many times, and also probing the signals with the scope and I can see RST, SWCLK and SWDIO toggling trying to get response from device, but no luck so far... Only thing I notice is RST pulse is only 50ns, which seems to be small compared to what the PSoC Programming Specification states; however, I don't see how to actually change this as it's supposed to be handle by the programmer software.
Also tried two devices with same behavior so I don't think it's the device.
So my question is; it's really possible to acquire the device using CMSIS-DAP?
Thanks in advance;