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.
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 188.8.131.52, 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.
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.
/* PSoC4 UART settings */
Mode : Standard
19200bps (Actual 19231bps)
8bit data length
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.
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?
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.
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 
Code Type: X86-64 (Translated)
Parent Process: ??? 
Responsible: ModusToolbox 
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 
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
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:
Calls made by this process:
Calls made by all processes on this machine:
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%)
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 184.108.40.206.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.
I have a startup problem with the PSCO4 BLE module, here is the functionality:
So my question is this:
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?