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?
PSoC Creater 4.4 will program my CY8KIT-059.
However, Programmer 4.00 will not recognize the device.
However, Programmer will detect my CY8KIT-147.
What must I do to get Programmer to detect the CY8KIT-059 ?
I'm trying to understand, via the Architecture TRM, Registers TRM, and the PDL documentation how the Trigger Mux's connect to the PWM Trigger inputs.
I can see that there are 2 Trigger Mux groups, 2 and 3, that connect into the TCPWM's. It looks like the TCPWMx_GRPy_CNTz_TR_IN_SEL1 register is used to select the trigger source for the START signal to the TCPWM. It looks like I can chose between 139 possible trigger choices per figure 25-3 in the TRM. It seems like I can pick the same trigger for each of the counters I might want to control. I want to understand in more detail what is happening
1) Trigger group 2 vs Trigger group 3, which one is used and where is this documented?
2) There are 28 outputs from those 2 trigger groups. How are they routed to the PWM's, where is this documented in the architecture or where is a register controlling this?
3) I cannot understand Table 29-2 in the TRM, there is no indication of what registers control this "selection"?
The PDL documentation shows that I can use Cy_TrigMux_SwTrigger to software trigger all my TCPWM's to START at the same time, but I am unclear how this occurs without understanding the mux connections from the Trigger mux to the individual TCPWM's. Please help my understanding.
And note, this is for the 6xx4 family which is the Ver 2 style of TCPWM and muxing.Show Less
The attached workspace bundle contains two projects: a bootloader minimally modified from CE216767, Bootloader_DevKit, and a very simple bootloadable, App_Stub_DevKit. I'm operating with PSoC Creator 4.2, PDL 3.1.4 (though 3.1.0 has the same issue), and the CYBLE-416045-EVAL dev kit.
The release build of the App Stub builds the App Stub against the bootloader's linker command files making it a standalone application in slot 0. Flash that into the part and it runs. The green LED on the dev kit is being operated by the M4 core and the red LED is being operated by the M0+ core at a different rate.
Fine so far.
Build the debug build of the bootloader and flash it into the part. The LED blinks white as it should.
Build the debug built of the App Stub. This is built against the App Stub's own linker command files which put it in slot 1. That build also creates the .cyacd2 file.
Use CySmart to load the App Stub .cyacd2 file via the bootloader. CySmart says it loads fine. The LEDs don't blink.
Problem: the application doesn't run.
Go into the App Stub's clock configuration and source Clk_HF0 from path 0 instead of path 1. Change nothing else. Rebuild the App Stub.
Reflash the bootloader into the board to destroy the broken App Stub. Note that I have disabled the button functionality of the bootloader since my real hardware doesn't have a usable button.
Use CySmart to load the rebuilt App Stub into the board. CySmart says it loads fine. The LEDs blink correctly.
For some reason, when the App Stub is in slot 0, the PLL clock works. When it's in slot 1, the PLL clock fails. Switching the App Stub to the FLL clock enables the App Stub to run in slot 1.
Help, please!Show Less
while porting WHD, I have similar question as https://community.infineon.com/t5/Wi-Fi-Combo/Support-for-porting-WHD-to-stm32F7/m-p/212755 .
1. However this question seems not answered fully. So, please let us know it.
2. & I assume the port specific type can be something like below -
I setup the PSoC 62S4 Kit ADC , with 2 channels as singled end, Vref=VDDA, Vminus=VSSA. When feed the Vplus with known signal (or voltage) , the voltage readings of the two channel is ok and as expected. When I disconnected the signal, i.e. the Vplus open ended, I got reading (as calculated) is fixed as 2.8V . Is this normal? As I thought an open-ended Vplus will get varying readings from time to time, or at least the level is not so high.Show Less
i am trying to carry out clock glitching with the new target board PSoC 62 with Chip Whisperer pro kit. but am not able to. after making changes in the code there is not effective changes seen, the results are the same.
attached is the file with changes made please help me out what am i missing are doing wrong?Show Less
I'm trying to put my device to deep sleep using a 16 bit WDT (Counter0) . I'm able to put the device to deep sleep for 4ms.
1. However, when I try to increase the time to 30s by using a for loop, the device isn't going to deep sleep (current ~ 2mA).
2. Even when I use a 32 bit WDT ( Counter2), I get a current of about 2mA.
Can someone help me out with the code of putting the device to deep sleep for long intervals like 1-2 minutes and then wake up the device.
Hello Infineon Support,
Apologies, I originally posted about this issue here, but I was taken off the project before I was able to test it out. I'm back on now and I'm still getting this error after the BLE stack is initialized:
hci_open(): init error (0x4021c00)
The old post wouldn't let me reply so I'm adding some information here.
First off, I can confirm that I have the most up-to-date version of the BSP and libraries available, so that is not the issue.
Second, I'm using the Bluetooth_LE_CapSense_Buttons_and_Slider project as a baseline, and when I run that project, it works as expected and I do not get the HCI error.
For my project, I copied in the ble_task files and the design.cybt file, so my setup should be the same for all the bluetooth libraries and functions. I confirmed that my Makefile has the FREERTOS and WICED_BLE components added to it.
There's two other notable differences between my project and the original capsense project:
Could either of those differences cause contention issues with the HCI hardware? I've tried all sorts of things to get this running but cannot shake this error message.
The most recent discussion on this topic dates back to 2018. At that point, Cypress did not support running FreeRTOS on the PSoC 6's CM0+ core.
First - has that position changed? Is there any official support for FreeRTOS on the CM0+?
Second - has anyone done this, especially using ModusToolbox? If so, would you please share your experience here?
A side issue is that the procedure for developing dual-CPU applications using ModusToolbox omits the FreeRTOS include directories from the compiler command line. The obvious brute-force workaround would be to add them in the CM0+ Makefile. Is there a better way?
There is a CM0 port of FreeRTOS available directly from FreeRTOS - download the FreeRTOS distro, then look in
The port is not specific to the PSoC 6, of course, and I'm unclear exactly what, if anything, needs to be changed.
For background, we plan to run FreeRTOS on both PSoC 6 cores. The CM0+ will handle data acquisition code (external multi-channel SPI ADC via DMA), and lightweight feature detection. The CM4 will be called into action for heavyweight processing when a feature is detected.