PSoC™ 6 Forum Discussions
Where can I get errata for PsoC CY8C6347FMI? I've searched the Infineon website without any luck. I did notice this post: https://community.infineon.com/t5/PSoC-6/Where-can-errata-be-found-for-PSoC-6-die-revs/td-p/324797 Where the errata was obtained from a local FAE. But I'd really just like to download the errata sheet and get on with my project.
Dean
Show LessDear Sirs,
Just like Bernadett, I'm looking for
-Maximum soldering temperature
-How long can the product be exposed to the maximum soldering temperature.
for the following products:
Manufacturer: Infineon
Manufacturer code: TC275TP64F200WDCKXUMA1
and TLF35584QVVS1XUMA2
(I would need this info for AUDIT by automotive project)
Thanks in advance!
kind regards
Show LessHi all,
I'm trying to add freeRTOS to cm0p for the project "Dual-CPU_Empty_PSoC6_App" but I keep getting this error:
../bsps/TARGET_APP_CY8CPROTO-062-4343W/COMPONENT_CM0P/TOOLCHAIN_GCC_ARM/linker.ld:312 cannot move location counter backwards (from 08001670 to 08001000)
I'm pretty new using both PSoC62 and freeRTOS. I'm able to add freeRTOS to cm4 but I need freeRTOS in each core. The error seems related to RAM but I can't figure what's wrong. Below are pictures showing the linker files settings for the RAM for both cores:
Is this a setting I need to change in FreeRTOSConfig.h or something else?
Thanks
Show LessCould you please provide the steps for integrating the WFM200SS22XNA3 module with the CYB0644ABZI-S2D44 microcontroller and wireless host driver. ?
Show LessHello,
please give me urgently Lötprofile for the following items :
INFINEON TC275TP64F200WDCKXUMA1
INFINEON TLF35584QVVS1XUMA2
We need urgently.
Thank you
Bernadett
Show LessWe have used UART in many projects involving the PSoC 6 and there have never been any problems. After migrating to PSoC Creator 4.4 we have seen some UART issues. However, we still have a number of applications that are running as they are supposed to with version 4.4. But, in a couple of new projects the UART output does not correspond to the UART FIFO input. There must be something wrong with the UART configuration or the way its is being set up.
In the current project a CYBLE-416045-02 built into the CY8CPROTO-063-BLE prototyping kit is being used to build a tester. As in other PSoC projects, a Control and Observation Port using a UART is used for monitoring and controlling the unit. The external connections for the UART (named COP_UART) are TX/P5_1 and RX/P5_0.
A debug trace shows that the intended output strings are getting to the UART FIFO (via COP_UART_Put() commands). For each byte sent, a single character appears on the monitoring teraterm module. This character is always the "Y with acute" character (0xDD).
There is no hardware issue; another application written for the CYBLE-416045-02 was also loaded into the CY8CPROTO-063-BLE board and the output to teraterm is exactly as intended and shows the application cycling.
If someone has some insight as to what may be happening and how to solve the problem, please let me know. I do have two workspace bundles for a reduced application that shows the problem. One is a complete bundle (424 MB) and the second has only the essentials (20 MB).
Show LessHi - I'm experimenting with the PSoC 6 BLE Pioneer Kit CY8CKIT-062-BLE by watching the PSoC 101 YouTube videos. I'm using PSoC Creator 4.2.0.641.
In video PSoC 6 101: Lesson 2-1a Basic UART Implementation, I cannot get any input from stdin (using Putty) to be echoed back to Putty. I do receive the opening "Started UART" message on Putty, but it appears that once getchar() is called, it never returns.
I double checked the UART pin assignments, retargeting I/O is selected in the PDL and in file stdio_user.h, the #defines for IO_STDOUT_UART and IO_STDIN_UART are both set to UART_HW as outlined in the video. I went back and verified I followed the directions in the video correctly.
I should mention that the kit was obtained from eBay. Are there any switch settings on the board that may be preventing operation?
Any ideas on why I'm not getting stdin with getchar() would be appreciated! Thanks.
code in main_cm4.c:
#include "project.h"
#include <stdio.h>
int main(void)
{
__enable_irq(); /* Enable global interrupts. */
/* Place your initialization/startup code here (e.g. MyInst_Start()) */
UART_Start();
setvbuf(stdin, NULL, _IONBF, 0);
char c;
printf("Started UART\r\n");
for(;;)
{
/* Place your application code here. */
c = getchar();
if (c)
{
printf("%c", c);
}
}
}
Show LessDears,
After Programming using Cypress Programmer 4.1 it seems that Programmer does not send RESET to target microcontroller. I am programming USB AUDIO device. USB Audio device is not correctly connected/recognized... I must manually unconnect cable and reconect and than it is worknig. I verified and Reset checkbox is checked in Cypress Programmer
Could any one have some idea what could be wrong ?
Thanks in advance
Radim
Show LessHi ,
I have recently moved from Psoc4 to Psoc6, and the tool for the chip is Modus tool box.
We are using CY8C6245LQI-S3D42.
I started to create a sample project for USBUART and I see the following issue as in the below image. The tool is trying to do something from git and the git path does not exist.
As a starter it becomes difficult if we are unable to create examples.
Any help will be appreciable.
I am struggling with Modus tool box, I believe psoccreator was much better and easier.
Regards
MSS
Show LessHi,
I am working on PSOC6 CY8C MCU in one of our projects and we want to secure the debug port in NAR.
I am able to lock the debug port (CM0+ and CM4) by configuring sFlash NAR area(0x16001A00), we used Cy_Flash_WriteRow() system call to write into sFlash NAR area.
Now I have some queries which are mentioned below:
1. How to unlock the debug port (CM0+ and CM4) in NAR so that I can re-program new firmware?
2. If it's not possible to unlock the debug port via firmware, is there any other way to do it?
Below are some details:
MCU : CY8C6248BZI-S2D44
MPN :
PCBA = 47616062
PCB = 47616063
Application:
We have some project specific application where we need to make sure debug is locked and can be UNLOCKED again.
Debug Port locking has been successfully evaluated and we are now exploring on unlocking the secure debug port so that our boards should be reused for any further updates.
Please help us in providing information on UNLOCKING secure debug port.
Thank you.