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 ?
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.
I have one question Is there any method to check if the device is returned from Backup Domain. I am working on device in which Backup domain is required for time tracking and other implementations.
I have looked into Technical Reference Manual Section for Backup Systems and Power Supply where I found VDDBAK_CTL for switching the Power rail between VDDD and VDDBAK.
I also looked into Registers Technical Reference Manual for Backup System Registers BACKUP_STATUS But it only tells the status of WCO and RTC_Busy not if system is returned from BACKUP domain
I also tried to look into Pdl reference manual no API found that could help me.
Kindly help me with the situationShow Less
We are using the CYBLE-416045-02 module in a doppler radar speed collection
module that sends traffic speed data to a server. We have a half dozen
units in the field for testing and the system is running very well.
An external FRAM is being used for parameter and system state saving during
processor hibernation. For system reliability we want to also save the
parameters in PSoC 6 flash using the EEPROM V2.20 component. Creator 4.4
is being used for development.
The "Em_EEPROM" component was first configured with 1024 bytes, redundant copy,
blocking write and no wear leveling. Auxiliary audits were added to see the
results of the writes and reads on the EEPROM. At first nothing went through;
even the initialization returned a CY_EM_EEPROM_WRITE_FAIL. After
various trials with the configuration, a number of writes and reads
went through with no redundant copy and non-blocking writes. After more
experimenting, I could not even get that case to work any more.
Also, when the EEPROM component is active none of the ipc functions which are
used to communicate between CM0p and CM4 were working any more.
So, the EEPROM component must be interfering with the ipc operation.
To check this further, a compiler conditional variable was added to
be able to comment out the new EEPROM interface code. When
the EEPROM was allowed to be compiled in, the system did not
work. When it was not, the system worked as well as before starting
to add the EEPROM.
So, the problem is what should I be doing to prevent this interference.
The documentation for EEPROM does not say anything about such
interaction and I do not know what internal chip resources the
EEPROM is using that might be colliding with those used by ipc.
This should not have to be known to the user.
Also, the documentation for the EEPROM component is much too sparse.
For example, writes can be in non-blocking mode. Normally when
this is provided, there is a way of starting the operation and a
way of checking when the operation is done. There is no information
about this in the EEPROM documentation.
A second example is the return codes. Sure, they are defined. But,
what the user needs to know is why did a write error appear and
what should be done to fix it.
The only EEPROM calls used in the interface are the following:
fnvm__status= Em_EEPROM_Init(0); // address not used in PSoC 6
fnvm__status= Em_EEPROM_Write((U4)ind,(V *)vUP,(U4)nb_used);
fnvm__status= Em_EEPROM_Read((U4)ind,(V *)dUP,(U4)nb_used);
The following are the ipc calls used in the CM0p and CM4 processors:
, (void *) &ipc0__ipc_msg
, (void *) &ipc4__ipc_msgT