I am working with the CYBLE-416045-02 chip (with CY8CPROTO-063-BLE KIT) but i am declaring a function in my .h file as the following:
uint8_t WriteCommandPacket(uint16_t cmd);
and the user can send differents commands:
#define CMD_WATER (0x3608)
#define CMD_ALCOHOL (0x3615)
#define CMD_STOP_MEASUREMENT (0x3FF9)
#define CMD_SOFT_RESET (0x0006)
#define CMD_READ_I (0x367C)
#define CMD_READ_II (0xE102)
it is why i am using the uint16_t type to send this command. But the PSoC Creattor 4.4 is telling me the following error:
masterI2C.h:68:9: error: conflicting types for 'WriteCommandPacket'
uint8_t WriteCommandPacket(uint16_t cmd);
The strage thing that i can use this type inside of the functions
Can someone help me out?
I have a use case where 2 central devices need to connect to one peripheral. I am using psoc6 as a peripheral and phone as central devices.
The problem I see is that when one central device is connected to psoc6, the other central device does not discover the peripheral. I have increased the Max number of ble connection to 2 in BT configurator, but not able to connect two devices.
I am using 'BLE_Battery_Level_FreeRTOS' example and just increased the Max number of ble connection to 2. If I connect one phone via 'CYSmart' app, cysmart app on another phone does not show the peripheral in the list.
Is there anything additional thing needed to establish connection other than increasing the Max number of BLE connections in BT configurator?
Kit used: CYCKIT-062-BLE
MCU CY8C6347BZI-BLD54 is used as a CPU on our product and it has been produced for 50K-100K units. However, there are a few units (less than 1%) having boot-up issue after executing the process of secure boot. The failure symptoms are listed below:
1. Power up for several cycles and then finally it could boot up successfully. The cycle time of powering up can't be calculated. It's a random.
2. Always fail to boot up so it becomes a brick.
3. 1 unit succeeds to boot up intermittently.
The eFuse of these units is burned successfully if we check the eFuse bit after the unit succeed to boot up. Thus, we can't read any debug information from the SWD port. Then some signal waveforms are captured and compared on both the situation of successful and fail boot-up. The main differences are
1. The power rail behavior of MCU_VIND2, MCU_VRF, and MCU_VBUCK1
2. The activated timing of SWDIO
Please refer to the attachment for more detail waveforms. We suspect this issue results from the process of eFuse burning but we don't have solid evidence to prove it. Thus, we need your thoughts and insights on this issue. It's getting more critical now due to the increasing production volume. Thanks.Show Less
Due to lack of stock CY8C6247BZI-D34, new boards came out with CY8C6247BZI-D54 and am figuring out firmware compatibility, as by default JTAG ID is different, and cyacd2 also fails.
From the data-sheet it looks like the -D54 brings the crypto block in addition to what -D34 has, however hex file is different all over when recompiled for D54.
So I wonder do you think the same firmware can run on both CPU (and not using crypto at all) or there are more "fine details" making this impossible?
we are working on the Smart Lock project using the Matter protocol or CHIP
I am trying to connect the PSOC 6 with matter protocol/ CHIP software loaded and the Raspberry pi wifi/zigbee interface
Matter protocol buildwithmatter.com
i followed the docs provided in the /connectedhomeip/examples/lock-app/P6/Readme.md
I executed the : zcl OnOff On 1234 1 0 ---- command
not connecting , below is the error message
Please reply me the possible solution.
chip-device-ctrl > zcl OnOff On 1234 1 0
[1637573653.279080][9954:9960] CHIP:DL: Avahi resolve failed
[1637573653.279196][9954:9960] CHIP:DIS: Node ID resolved failed with ../../src/platform/Linux/DnssdImpl.cpp:692: CHIP Error 0x000000AC: Internal error
[1637573653.279257][9954:9960] CHIP:CTL: Error resolving node id: ../../src/platform/Linux/DnssdImpl.cpp:692: CHIP Error 0x000000AC: Internal error
Failed to update node address: 172
^Z[1637574457.431856][9954:9954] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-zQ6w1Q)
[1637574457.433052][9954:9954] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1637574457.433175][9954:9954] CHIP:DL: NVS set: chip-counters/boot-reason = 5 (0x5)
[1637574457.433553][9954:9954] CHIP:DL: writing settings to file (/tmp/chip_counters.ini-mnlqAQ)
[1637574457.434501][9954:9954] CHIP:DL: renamed tmp file to file (/tmp/chip_counters.ini)
[1637574457.434610][9954:9954] CHIP:DL: NVS set: chip-counters/total-operational-hours = 0 (0x0)
[1637574457.434666][9954:9954] CHIP:DL: Inet Layer shutdown
[1637574457.434892][9954:9954] CHIP:DL: BLE shutdown
[1637574457.434957][9954:9954] CHIP:DL: System Layer shutdown
pure virtual method called
terminate called without an active exception
Aborted (core dumped)
I am developing a product using the CYBLE-416045-02 module.
When nothing needs to work, both CM4 / CM0 + CPUs are DeepSleep using Cy_SysPm_DeepSleep.
In rare cases, the MCU will restart in Cy_SysPm_DeepSleep.
I found that it restarts at the following points of EnterDeepSleepRam.
/ * The CPU enters Deep Sleep mode upon execution of WFI / WFE * /
SCB_SCR | = SCB_SCR_SLEEPDEEP_Msk;
I have modified what is in KBA229335.
The frequency of occurrence varies depending on the individual.
It does not reproduce at all in one individual, but it reproduces 100% in another individual.
Are there any other similar reports?
Also, please give me some advice on how to solve this problem.
The PSoC 6 lists 3 XTAL's Core, RTC and BLE, as these take up more or less same board space as the psoc itself, I wonder if there are any ways to omit the bluetooth xtal, i.e. clocking it using the same MHz XTAL used for the core!?
In the hardware guide (AN218241) it simply says
> An external 32 MHz crystal is mandatory for proper BLE operation.
Basically any ways to reduce the number of crystal oscillators is what I'm after. i.e. skipping the ECO and instead rely on a sub 20ppm xtal for BLE and have it on all the time feeding other parts of the system.
...option 2 would be to go for some 3-in-1 mems oscillator at the cost of mems + added power
any ideas?Show Less
Hello Team Cypress,
I am here to ask for your recommendation on
the best Cypress MCU or/and Evaluation Board that can control 3.98 inch LCD touchscreen and more features,
in order to develop touch screen device.
The client was considering the following ST-micro MCU before,
because of its simple guidance to the sample project guide.
MCU Specifications in need :
-supports LCD : 3.98 inch, 320X480, RGB, 40pin
(ILI9488, a-Si TFT LCD single chip driver : https://focuslcds.com/content/ILI9488.pdf )
-supports 2D graphics acceleration
-supports single touch feature (capacitive)
-supports PWM controllers for buzzer feature for audio
-better than Arm Cortex-M0+
-6x USART, timers
-RAM size : 144kB or better
-Flash size : 256kB or 512kB
-compatible to use NAND flash of size 4~8MB
(in order for the device to support user interface in
three different languages(Korean, Chinese, English))
-preferably has easy development environment to develop the LCD touchscreen device.
If you can recommend MCU or/and evaluation board that can support above feature with design guidance for LCD touch device project, that would be greatly appreciated to share it with the client.
As always, thank you for your considerations to help and bring our business forward.
Hi everyone. I have the following issue. I just installed the new version of IDE Modus Toolbox in 2.4.
After going through the entire installation procedure on my Linux Manjaro machine.
My sample applications compile fine, but when I do Debug or Program it throws the following error and does not allow me to program my PSoC6.
Could not determine GDB version after sending: /home/user/ModusToolbox/tools_2.4/gcc/bin/arm-none-eabi-gdb --version, response:
I want to emphasize that I had previously installed the Modus Toolbox 2.3 version and it was working fine
Can you guide me to solve this problem, please?Show Less