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,

Hi,

I recently the ModusToolbox 2.3. The ModusToolbox works properly the first time after installation. I was able to program the board and see the debug logs also. When I quit the application and reopen I see the following crash log.

Process: ModusToolbox [2125]
Path: /Applications/ModusToolbox/*/ModusToolbox.app/Contents/MacOS/ModusToolbox
Identifier: ModusToolbox
Version: ???
Code Type: X86-64 (Translated)
Parent Process: ??? [1]
Responsible: ModusToolbox [2125]
User ID: 501

Date/Time: 2021-05-14 22:22:20.917 +0530
OS Version: macOS 11.3 (20E232)
Report Version: 12
Anonymous UUID: 72D78742-3F7C-5B9A-1D5A-08FF3FB3DC39

Sleep/Wake UUID: 9A70761A-4BD8-45D9-B3ED-D9FE4AABA3C0

Time Awake Since Boot: 300000 seconds
Time Since Wake: 12 seconds

System Integrity Protection: enabled

Crashed Thread: 0

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: EXC_ARM_BREAKPOINT at 0x00007ffdffc42360 (brk 1)
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Trace/BPT trap: 5
Termination Reason: Namespace SIGNAL, Code 0x5
Terminating Process: exc handler [2125]

Application Specific Information:
rosetta error: /var/db/oah/63b8ff35a4bc93e2da17585c4ea5ae7f225c3b5f3c7ebcea016bd32f0f335c15/a462f34c94df3beb9c9321b81b4fec37bafd6d153828a19d3608e801f1adf921/ModusToolbox.aot: attachment of code signature supplement failed: 3

Thread 0 Crashed:
0 runtime 0x00007ffdffc42360 0x7ffdffbef000 + 340832
1 runtime 0x00007ffdffc423ac 0x7ffdffbef000 + 340908
2 runtime 0x00007ffdffbfd004 0x7ffdffbef000 + 57348
3 runtime 0x00007ffdffbfe54c 0x7ffdffbef000 + 62796
4 runtime 0x00007ffdffbfe044 0x7ffdffbef000 + 61508
5 runtime 0x00007ffdffbf02a0 0x7ffdffbef000 + 4768
6 dyld 0x0000000103267000 0x103267000 + 0

Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x0000000000000000 x1: 0x0000000000000003 x2: 0x000000000000003c x3: 0x000000000000002c
x4: 0x0000000000000303 x5: 0x0000000000000000 x6: 0x0000000000000000 x7: 0x0000000000008463
x8: 0x00007ffdffc6f000 x9: 0x0000000000000000 x10: 0x00007ffdffc65c5a x11: 0x0000000000000000
x12: 0x00007ffdffc596e0 x13: 0x00007ffdffc596d0 x14: 0x00007ffdffc54a76 x15: 0x0000000000000020
x16: 0xffffffffffffffe1 x17: 0x00007ffdffc467e4 x18: 0x000000020a286103 x19: 0x00007ffdffc65b78
x20: 0x000000020a2867b8 x21: 0x0000000002f1d000 x22: 0x0000000000000103 x23: 0x0000000002f1d000
x24: 0x0000000000000003 x25: 0x0000000000000001 x26: 0x000000020a285c10 x27: 0x00007ffdffbef000
x28: 0x0000000000000001 fp: 0x000000020a2849b0 lr: 0x73027ffdffc42358
sp: 0x000000020a284990 pc: 0x00007ffdffc42360 cpsr: 0x60000000
far: 0x00007ffdffc70000 esr: 0xf2000001

Binary Images:
0x103267000 - 0x103302fff dyld (851.27) <7EAA668B-F906-3BAA-A980-139BBE6E8766> /usr/lib/dyld
0x7ffdffbef000 - 0x7ffdffc62fff +runtime (203.42) <A7DF9462-ECE5-3ED4-8C57-BC56BA4793EA> /Library/Apple/*/runtime

External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 3
thread_create: 0
thread_set_state: 6

VM Region Summary:
ReadOnly portion of Libraries: Total=1328K resident=0K(0%) swapped_out_or_unallocated=1328K(100%)
Writable regions: Total=18.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=18.8M(100%)

VIRTUAL REGION
REGION TYPE SIZE COUNT (non-coalesced)
=========== ======= =======
STACK GUARD 56.0M 1
Stack 8176K 1
VM_ALLOCATE 10.5M 1
VM_ALLOCATE (reserved) 56K 1 reserved VM address space (unallocated)
__DATA 288K 4
__DATA_CONST 32K 1
__LINKEDIT 272K 4
__TEXT 1088K 2
mapped file 4.7G 12
=========== ======= =======
TOTAL 4.8G 27
TOTAL, minus reserved VM space 4.8G 27

Model: MacBookAir10,1, BootROM 6723.101.4, proc 8:4:4 processors, 8 GB, SMC
Graphics: kHW_AppleM1Item, Apple M1, spdisplays_builtin
Memory Module: LPDDR4
AirPort: spairport_wireless_card_type_airport_extreme, wl0: Apr 2 2021 00:48:12 version 18.52.1.2.7.8.116 FWID 01-9f7b4413
Bluetooth: Version 8.0.4d18, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.1 Bus
USB Device: USB 3.1 Bus
Thunderbolt Bus: MacBook Air, Apple Inc.
Thunderbolt Bus: MacBook Air, Apple Inc.

I'm using Creator 4.4 in a PSoC4 project.
For best size optimization, under "Build Settings" I enabled "Link Time Optimization".
For maximum gain I also added "-fwhole-program" as Custom Flag for both Compiler and Linker.
With the above options there are compilation errors caused by removal of some global symbol.

After debugging I found that the following changes are required into file ".\Generated_Source\PSoC4\Cm0plusStart.c".

//!void Reset(void)
void __attribute__((externally_visible))Reset(void)

//!cyisraddress CyRamVectors[CY_NUM_VECTORS];
cyisraddress __attribute__((externally_visible)) CyRamVectors[CY_NUM_VECTORS];

//!const cyisraddress RomVectors[CY_NUM_ROM_VECTORS] =
const cyisraddress __attribute__((externally_visible)) RomVectors[CY_NUM_ROM_VECTORS] =

The GCC attribute "externally_visible" correctly prevents the optimization on these symbols.
With the above fix I was able to test a working application and save quite Flash space thanks to LTO.

I hope this could be of interest to someone.
I suggest to file an enhancement request so that this fix could be included in a future revision of cy_boot component.

Regards,
Giuliano

I have a startup problem with the PSCO4 BLE module, here is the functionality:

1. It is a sealed unit, with an internal LiPo battery, and externally I can only provide 5V to charge
2. It appears that from a dead battery, if you start charging there is maybe 1 in 20 chance, PSOC4 hangs and doesn't start up properly
3. The battery now has some charge, and I can't access XRES pin easily (you have to remove a few things to get to the signal). It looks like you need to let the battery fully discharge and then try again to power up the next day
4. The external way you know it's charging is if the firmware checks a GPIO from the charging IC, and then turns on an LED, I can see the charge current going into the battery (charging IC is working), but firmware is not working
5. The project supports an OTA update (fixed stack bootloader)

So my question is this:

• If I enable the Watchdog timer Hard reset in the firmware image -- is that enabled at power-up,  or is it still a firmware step to enable the watchdog per the FLASH image?
• I had this slight hope that the watchdog could help if the firmware hung, and issue the reset to the device -- but if it requires firmware to enable the watchdog, it may never get to that step.
• Same question with the brown-out detection circuit, does that require a firmware step to program at power-up
• Is it possible that it is hanging in the bootloader section first 

I already have many units built, and I have no real ability to redo HW right now (very painful). I can easily update the main firmware image, but changing the bootloader is also very hard. 

Any thoughts on the firmware watchdog solution?