Hello,

I have probed address line 25 and 26 to see it toggle between bank 0-3. I am able to write erase and see the device ID up to sector address 3FF0000H which shows the first flash in the block diagram, yet when I try to write anything above or even read device ID above, I cannot read any device id, is there a algorithm or something that chooses which flash block it uses besides bit 26 and 25 on the pin side?

Thanks,

George M. 

After power up, I need to wait 25mS in order to read data from the Flash correctly.   Anything less then 25mS and I get data errors.

Is the datasheet correct is specifying 35uS for rising edge of Vcc/Vccio to rising edge of RESET#?

Thanks,

Tim

Hi all,

I have a CY8CKIT-062-WIFI-BT dev kit and recently have come across a persistent annoying error even during compilation of a sample application such as snip.scan. While making sure other processes and applications weren't running that would use OpenOCD drivers, the console output during a build of snip.scan still complains. Here is a sample of the latest output. Any edits I've attempted to make would only be on the snip.c source file which is only adding print statements.

"**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****"
Resetting target
Target running
Build complete

Please advise - this hasn't happened before when I worked on this devkit but I feel I might be overlooking something with my build targets ("snip.scan-CY8CKIT_062 download_apps download run" and " snip.scan-CY8CKIT_062 download run ") or setup of the devkit. Very rarely, the build will complete without this error. WICED version is 6.6

We need to measure the level of a water-based cleaning solution in a consumable HDPE bottle, of wall thickness ~1mm. The consumable bottle will be docked into another plastic receptacle, either Polypropylene or HDPE or approximately 2mm thick.

We want to mount a segmented sensor to the outside of the receptacle, and measure the liquid level inside the consumable.

The wall of the consumable and the wall of the receptacle should be in contact with each other, but a small air gap is possible (<1mm)

We need to know if this is feasible, given the correct sensor design? We would be looking for a level resolution of 100%, 75%, 50%, 25% and empty.

Thanks.

Hi Cypress

We have some question about FRAM application ,
1. How time is it when write a 16Mbit in CY15B116QSN-108BKXIE , Can you take a example for it .
2 Is it can work in Linux system with file system .Thank !!

Using WICED 6.4.0.61, STM32L4+ connected to a 43012C0

I am running into an issue when sending data to a connected socket using the NETX API. After some time, anywhere from 2-20 minutes, my tcp sends return NX_NOT_CONNECTED. I've watched the connection in wireshark, and there is no FIN or RST being sent by either side of the connection. All traffic from the device stops, the server sends one keep alive, and finally the server RST the connection. When this happens, other wiced API calls, like getting the RSSI, hang indefinitely. I have tried closing the socket, and attempting to reconnect, but all attempts at connecting eventually return NX_NOT_CONNECTED. Even taking down the interface and attempting to rescan and connect to the AP fails on the scan call.

What I have noticed is that the WWD thread appears to be waiting on the SDIO semaphore, and never seems to unblock. Does anyone know what is happening, or if there is a work around for this which does not require restarting the chip from scratch?

Below is the stack trace for the WWD thread.

#0 __restore_interrupts (primask_value=2147483648)
threadx/5_8/tx_port.h:488
#1 _tx_thread_system_return_inline ()
threadx/5_8/tx_port.h:488
#2 _tx_thread_system_ni_suspend (thread_ptr=<optimized out>, thread_ptr@entry=0x200019d4
<wwd_thread>, wait_option=<optimized out>)
threadx/5_8/tx_thread_system_suspend.c:1278
#3 _tx_semaphore_get (semaphore_ptr=<optimized out>, wait_option=<optimized out>)
threadx/5_8/tx_semaphore_get.c:239
#4 _txe_semaphore_get (semaphore_ptr=semaphore_ptr@entry=0x200025b4 <sdmmc1_sem>,
wait_option=wait_option@entry=4294967295)
threadx/5_8/txe_semaphore_get.c:179
#5 host_platform_sdio_cmd (command=command@entry=SDIO_CMD_53, argument=argument@entry=2751496256,
response_expected=<optimized out>, response_expected@entry=(unknown: 164)
host_platform_wiced.c:314
#6 host_platform_sdio_transfer (command=SDIO_CMD_53, response=0x0, response_expected=(unknown: 164)
host_platform_wiced.c:531
#7 host_platform_sdio_transfer (direction=<optimized out>, command=<optimized out>,
mode=<optimized out>, block_size=<optimized out>, argument=<optimized out>, data=<optimized out>,
data_size=<optimized out>, response_expected=<optimized out>, response=<optimized out>)
host_platform_wiced.c:463
#8 wwd_bus_sdio_cmd53 (response_expected=RESPONSE_NEEDED, response=0x0, data=0x200208f0
<g_tx_mem+64> "a", data_size=<optimized out>, address=0, mode=<optimized out>, function=<optimized
out>, direction=<optimized out>)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols/SDIO/wwd_bus_protocol.c:708
#9 wwd_bus_sdio_transfer (direction=<optimized out>, function=<optimized out>,
address=address@entry=0, data_size=<optimized out>, data=0x200208f0 <g_tx_mem+64> "a",
response_expected=RESPONSE_NEEDED)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols/SDIO/
wwd_bus_protocol.c:663
#10 wwd_bus_transfer_bytes (direction=direction@entry=BUS_WRITE,
function=function@entry=WLAN_FUNCTION, address=address@entry=0, size=size@entry=97,
data=0x200208f0 <g_tx_mem+64>)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols/SDIO/
wwd_bus_protocol.c:644
#11 wwd_bus_send_buffer (buffer=0x200208b0 <g_tx_mem>)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols/SDIO/
wwd_bus_protocol.c:220
#12 wwd_thread_send_one_packet ()
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/wwd_thread.c:184
#13 wwd_thread_func (thread_input=<optimized out>)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/wwd_thread.c:357

Dear Sirs and Madams,

I asked a question before, but the problem has not been solved yet.

https://community.cypress.com/t5/PSoC-4-MCU/PSoC4S-CY8C4126AXI-S443-UART-communication-error-detection/td-p/274478

Regarding the UART component of PSoC4S,

When PSoC4S is set to no parity, if data with parity is transmitted continuously, the data cannot be received normally frequently, resulting in a mismatch between the transmitted data and the received data.

So, I would like to ask you another question.

(1)

/* PSoC4 UART settings */

Mode : Standard

RX+TX

19200bps (Actual 19231bps)

8bit data length

Parity non

Stopbit 1

Oversampling 12

/*************************************/

If parity (odd / even) data is received with the above settings, Do you know how PSoC4 behaves when it receives parity (odd / even) data with the above settings?

In our system, PSoC4S may have problems not only "no parity error" but also "data cannot be received correctly".

The fact that PSoC4S cannot receive correctly means that the values of the transmitted data and the received data may differ.

(2)

I've heard that if PSoC4S is set to no parity, a parity error cannot be detected even if data with parity is received.
We thought that even if we received data with parity when no parity was set, we could receive the data normally. Can you understand the reason why the data cannot be received normally with PSoC4S?

(3)

Previously, I got the following answer.

Is it possible to provide a concrete application example?

/***********************************************************************************************************/

> When parity bit is not enabled, then the RX parity error check cannot be accessed/used. However, you may manually calculate the parity (even or odd) by reading the data present in the RX buffer in your application.

/***********************************************************************************************************/

Regards,