Browse the Community
Discussions regarding PSoC and MCU products.
Universal Serial Bus (USB) forums have discussions regarding Low-Full & High Speed Peripherals, Superspeed Peripherals, USB Hosts Hubs Transceivers, and USB EZ-PD Type C product solutions for PCs and consumer device topics.
Memory Discussion Forums discussions regarding NOR Flash, SRAM, nvSRAM and F-RAM - performance and reliability with discrete memory densities ranging from 4K-bit to 2G-bit topics.
Discussion forum regarding Other Technologies including Power Management and Clocks topics.
Software including ModusToolbox, PSoC Creator, WICED Studios and Wi-Fi Bluetooth for Linux .
I am seing an abnormal behavior of register VMONSTAT, for some reason (we still do not know why) the register is indicating that QVR (Voltage reference) is not ok, even though we know for sure that there is voltage on the output pin, also make not sense that the register is reporting that QT1 and QT2 (Trackers) are ok, when according to datasheet QVR is directly related with QT1 and QT2 in other words make no sense that QT1 and QT2 be working when QVR don´t.
This is what I am seing on VMONSTAT:
Also another question will be, whats the difference beetween VMONSTAT and DEVSTAT, because according to Errata Sheet
Rev. 3.0, VMONSTAT is only indication when a voltage is enable (not if is out of range) and this seems to be the same as DEVSTAT, in the situation descripted above this is what I see on DEVSTAT:
From my point of view make no sese that DEVSTAT is reporting VREF as "enable" but VMONSTAT is reporting it as "Not enable"Show Less
we are using Config Wizard for a project with TLE989x.
Problem is, the tool seems to expect a hard coded folder structure, which is incompatible with the way we structure our git repositories. We tried changing it manually, but we did not try brute forcing / guess the used hash algorithm. (not our job)
We integrated the ConfigWizard with IAR Workbench as demonstrated in the examples. Any attempt to change the structure leads to something being broken in the process...
Can you please show us a way to clean up our repository?
Best regardsShow Less
I'm working with a customer where we are performing a feasibility study to use the PSoC4 (or maybe 6) as a touch controller for displays with the size around 15 inches. I understand the Multitouch automotive PSoC portfolio, such as the GEN7L could be a fit, but the available flash and RAM for user code doesn't seems enough for the application, so my questions are:
1 - Is it possible to use the capsense solution from the non-auto PSoC part for display touch sensing? (It's a PCAP techology)
Please note that due to the size of the screen, it may be required around 80-100 IO's combined as Tx/Rx to perform the scanning.
I couldn't find any demo board for this purpose, similar to this one CY3290-CYAT8168X. Note this one is, again, automotive part.
In summary, is it possible to use a non-auto PSoC to work similar as the Multitouch devices?
Marcelo - FAE at Neutronics
Using AURIX TC377TX, Bootloader and APP are stored in 1M space from 0x80000000 to 0x800FFFFF of PF0. When APP erasing 128 Logical Sector starting from 0x80100000 of PF0, Program Fetch Fetch Fetching Error (PSE) Trap is causing and Fetch Bus Error (FBE) is raised in CPU- >CPU0- > PMI- > PSTR (Program Trap Register)
But erasing the 128 logical starting at PF1 0x80300000 is fine.
Check the 2MPFLASH SPACE STARTING at 0x80100000 and there is no code.
Can you tell us why the Fetch Bus Error is dangerous? How do I find out what does it mean?
Hi Infineon community,
I'm currently developing a project in ModusToolbox using the CY8CPROTO-063-BLE, along with the Bluetooth_LE_Hello_Sensor. My aim is to create five distinct characteristics, but I've encountered an issue where only a maximum of four characteristics are visible in the AIROC Bluetooth Connect App. The same limitation occurs with other Bluetooth applications as well. Could there be a specific reason why the fifth characteristic is not being displayed?
Luis FloresShow Less
I need to use the ASCLIN module in ASC mode to make two Tricore tc3 communicate using the UART protocol. One tc3 will be the Tx and the other will be the Rx and each transmission must be 5 bytes long.
For this purpose, I created two projects in ADS, one for the transmitter and the other for the receiver.
I have some doubts about the receiving mechanism, reading the description of the ASC mode in the manual "Infineon-AURIX_TC3xx_Part2-UserManual-v02_00-EN" in section 18.104.22.168 I did not quite understand what happens each time a byte is received.
Referring to the example "ASCLIN_UART_1_KIT" I did not understand what the receive buffer g_ascRxBuffer[UART_RX_BUFFER_SIZE + sizeof(Ifx_Fifo) + 8] is used for, and I did not understand what element to associate it with in the manual description.
I would also like to understand what happens inside the receiving ISR, in particular what the function IfxAsclin_Asc_isrReceive(&g_ascHandle) does.
I would like to understand the communication mechanism because I would like to try out the various interrupt modes: single move, batch and combined to see which one is best for my application.
Thank you in advance for your helpShow Less
Can someone point me to the SMIF component for PSOC 5, and the example code download project? I realize SMIF probably will not work with cypress FRAM, as I*f*n appears to be moving away from cypress products, but it will be worth 2 or 3 hours to see.
To avoid re-inventing the wheel, I tried looking at the SMIF component for PSOC 5. I am interfacing to FRAM from Cypress (now I*f*n) It no longer exists. Or, if it exists, it has been hidden. All I want is to interface with serial spi FRAM on the PSOC 5, using work others have done as a starting point.
Why not PSOC 6? If not interested in that question skip the next paragraph.
I have a lot of custom designing of components, so Modus Toolbox is out, as there is no UDB design interface for that environment. I need to assign pins, so modus toolbox is out, since custom assigning pins is almost forbidden in that environment. So psoc 6 is out (for the most part), since support in PSOC Creator is deprecated. I need high temperature operation, and the psoc 6 is not yet qualified for us, so it is out. I need 5v operation, so all psoc 6 is out, even if high temperature qualified.
There are (search based) hints of SMIF component firmware somewhere, but it is always a cypress.com reference, and I*f*n has fully removed the DNS entries for cypress.com, so there is no help there. (I keep getting DNS server errors clicking on links inside documents downloaded from I*f*n!). I found the PDF files for the SMIF, but there is no indication of the firmware in the download page. ALL references to SMIF is for the PSOC 6 (and the associated problems), but none for the PSOC 5.
Hi Infineon Community,
I'm experiencing a connection issue with the CY8PROTO-063-BLE when using the AIROC Bluetooth Connect App. On one smartphone, I can successfully connect, view services and characteristics, and use them without any problems. However, with another, newer phone, despite the device being visible, I'm unable to establish a connection. It attempts to connect but fails to do so. The same issue occurs when trying to connect with an iPad. What could be causing this problem that prevents the connection from being established? Both iPhones are running the latest iOS version.
Luis FloresShow Less
Dear Infineon support team / community,
I'm working on a board populated with TLE9877 and I got some legacy code running. First it seemed fine using the bootrom functions to erase and blankcheck the flash. Also I had no problem to read out register or the whole flash content.
Since I do not have an application yet I made up some data for flashing. I filled 0x11000000-0x1100000F with 0xAA and 0x11000000-0x1100000F with 0x55. It did work without issue so far as long as the power was up. The test sequence consisted of erase, write, verify and read of the flash.
The desaster came when I tried to repeat the test sequence. Now the first command using a bootrom function did not work. It still enters debug mode and I can read out registers and also the flash content but starting CPU commands always fail with a timeout.
Does anybody know how to reset the device to erased state?
Is there a special mode I triggered when writing into the first 32 flash locations? I suspect the user reset vectors.
I checked error flash in several registers but until now I could not find strange bits. NVM seems fine without error.
▪ SCU_SYS_STRTUP_STS: 0x50
▪ SCU_NVM_PROT_STS: 0xF
▪ SCU_MEM_STS: 0x0
▪ SYS_STRTUP_CFG: 0
Are there any other registers I could check? Maybe protection or security flags?
I looked in to DHCSR register. It's value is 0x01090005. The bit I did not expect to appear is S_LOCKUP.
Is there a way to find out what went wrong calling the bootrom functions? Is there a status register?
Is there another way to call those functions? I did it manually without a code in RAM, see below:
Halt(); WriteCoreRegister ( CoreRegister::LR, 0x18000B01 ); // return addr is breakpoint: WriteToMemory ( 0x18000B00, (uint32)0xbe00be00 ); // write bkpt (0xBE00) to memory //set arguments WriteCoreRegister ( CoreRegister::R0, 0x18000400 ); // uint32* cbsl_nvm_size WriteCoreRegister ( CoreRegister::R1, 0x18000404 ); // uint32* code_nvm_size WriteCoreRegister ( CoreRegister::R2, 0x18000408 ); // uint32* data_nvm_size WriteCoreRegister ( CoreRegister::SP, 0x18000AFC ); // set SP, don't know if it's used WriteCoreRegister ( CoreRegister::PC, 0x000038B5 ); // user_nvm_config Run(); WaitForHalt ( 100_ms );