PSoC™ 6 Forum Discussions
text.format{('custom.tabs.no.results')}
Hello, I have designed in CY8C6316BZI-BLF53 into a medical product that is going to be used for a clinical trial. I have a handful of boards through our testing have broken and they have done so in the same way. The PSOC is getting power on VDDD and VDDA, but the internal buck isnt working. The latest PCBA that did this had been running a treatment for 40minutes and then it just died in the manner previously described. I couldnt find any schematic on how the power rails are laid out internal to the PSOC and what could have broken exactly in the PSOC for the buck to not work. On these non working PCBAs I am supplying VDDD and VDDA with 3V from a bench supply. Vbuck measures 2.5V, VDDR_HVL measures 1.5V, VDD_NS measures 3V. All the other rails are 0V. Vind1 and Vind2 are both at 0V. The 32.768kHz crystal is running. Is there any information you can supply to help prevent this from happening or any internal PSOC buck schematic? We are in development and dont want this to become a big issue down the road.
I have noticed that in the literature there is a decoupling cap on Vind2 which is missing in my schematic, but unsure without more information if that is the cause of the issue.
Slainte!
Jeff
Dear all,
I am getting started with CY8CPROTO-062-4343W and Modus Toolbox to build a RAM/ROM emulator, connected to the address and data busses of a 8-bit computer. As such, I want to decode some address lines and some other control signals to generate an interrupt (chip select), so the PSoC can either read the 8bit data input and store internally, or output a 8-bit pattern for the provided address.
The operation needed are only combinatorial and the LUTs could certainly do that. But here is my - stupid - problem : how can I configure the LUT ouput to go to one PSoC port and trigger an interrupt ? HSIOM is supposed to allow this routing, but I could not understand how to configure this in Modus Toolbox. Also, can I still read from the firmware the GPIO inputs for signals that are routed to the LUTs (as I will need to read the address lines that were used to define the chip select/interrupt signal) ?
Thanks in advance for your help, my apologies for the rookie's questions !
Philippe
Show LessHi,
I am trying to use the CYPRESS PSoc6 CY8CKIT-BLE and get data from the ADC. I am trying to store the data in each loop in a sort of array and save data for every 150 loops and save it together in the SRAM. I am not sure which functions and libraries will work best for me in this situation.
Could someone help me on the same?
Thank you for your help.
Show LessHi All,
Probably many people struggle finding good quality PCB manufacturer for small pitch Cypress BGA chips.
If you have any recommended PCB maker would be great to know.
I have PCB with CY8C6347FMI chip that consist via-in-pad and micro vias for that chip.
Here is most critical parameters
Min track/spacing 3.3 mil
Min annual ring size 0.05 mm
Min BGA pad size 0.27mm
BGA pad clearance 3.2 mil
Min Hole Diameter 0.15 mm
Thanks in advance.
Show Less
Hi,
Is there a possibility to have two or more memory slots in XIP mode without switching between them manualy?
Now it is only possible to manually select QSPI slave, for example using this sequence:
cyhal_qspi_init(&qspi_psram_obj, QSPI_IO0, QSPI_IO1, QSPI_IO2, QSPI_IO3, NC, NC,NC, NC, QSPI_CLK, PSRAM_SSEL, QSPI_FREQ, 0);
cyhal_qspi_slave_select_config(&qspi_psram_obj, FLASH_SSEL);
/*Entering XIP mode and working with external PSRAM on slot 0...*/
cyhal_qspi_select_active_ssel(&qspi_psram_obj, FLASH_SSEL);
/*Entering XIP mode and working with external FLASH on slot 1...*/
Regards,
Gintaras
Show LessHello
I have used PSOC 4 and 5 since long and I remember that Ports 0,1,2 and 3 are connected to HSIOM in PSOC 4. Therefore UDB output can be routed through only these ports.
I am using PSOC 61xx MCU and there are 13 ports, I would like to know which ports support UDB connections out of the 13 ports and where can I find more information on this.
Also, there are two smart IO ports that support Boolean operations. Does this consume the UDB resource?
Thank you
Show LessI upgraded my firmware to KitProg3 and wanted to run one of the example codes.
The device will not even get acquired. How doI fix this issue?
Open On-Chip Debugger 0.10.0+dev-4.2.0.1430 (2021-03-05-08:22)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
adapter srst delay: 25
adapter srst pulse_width: 25
** Auto-acquire enabled, use "set ENABLE_ACQUIRE 0" to disable
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Info : Using CMSIS loader 'CY8C6xxx_SMIF' for bank 'psoc6_smif0_cm0' (footprint 11100 bytes)
Warn : SFlash programming allowed for regions: USER, TOC, KEY
Info : CMSIS-DAP: SWD Supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : KitProg3: FW version: 2.21.1005
Info : KitProg3: Pipelined transfers enabled
Info : VTarget = 3.278 V
Info : kitprog3: acquiring the device (mode: reset)...
Error: kitprog3: failed to acquire the device
Info : clock speed 2000 kHz
Error: DAP 'psoc6.cpu' initialization failed (check connection, power, transport, DAP is enabled etc.)
** OpenOCD init failed **
shutdown command invoked
** Program operation failed **
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
Error executing event reset-deassert-post on target psoc6.cpu.cm0:
C:/Infineon/Tools/ModusToolbox/tools_2.3/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg:108: Error:
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 279
in procedure 'mxs40_reset_deassert_post' called at file "C:/Infineon/Tools/ModusToolbox/tools_2.3/openocd/bin/../scripts/target/mxs40/psoc6_common.cfg", line 131
at file "C:/Infineon/Tools/ModusToolbox/tools_2.3/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg", line 108
Error executing event reset-deassert-post on target psoc6.cpu.cm4:
C:/Infineon/Tools/ModusToolbox/tools_2.3/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg:108: Error:
in procedure 'ocd_process_reset'
in procedure 'ocd_process_reset_inner' called at file "embedded:startup.tcl", line 279
in procedure 'mxs40_reset_deassert_post' called at file "C:/Infineon/Tools/ModusToolbox/tools_2.3/openocd/bin/../scripts/target/mxs40/psoc6_common.cfg", line 166
at file "C:/Infineon/Tools/ModusToolbox/tools_2.3/openocd/bin/../scripts/target/mxs40/mxs40_common.cfg", line 108
Info : psoc6.dap: powering down debug domain...
Warn : Failed to power down Debug Domains
I am using the PSOC Creator V4.4 with a CY8PROTO-063-BLE board. (The only 'odd' thing abut my configuration is that I am using a iMac M1 computer running Parallels with a Windows ARM VM that has the PSOC Creator software installed - the fact that this works with the debugger and not without makes me thing that this configuration is not part of the problem.)
Using a 'Debug' build and with the debugger active the MCWDT interrupt is being triggered and therefore everything else w working well. However when I program without the debugger (bug still with the 'Debug' build) then everything appears to work until I am supposed to get a periodic MVWDT interrupt that never comes.
What I'm doing is to have a I2C sensor that is is being checked at the start and then periodically as triggered by the MCWDT. When the sensor is read, I update the advertising data that the BLE component is 'broadcasting'.
The BLE component advertises for 2 seconds and so it has finished advertising before the MCWDT interrupt which is currently set to about 6 seconds for testing purposes. The chip is in deep sleep for most of the time and the MCWDT is supposed to trigger the wakeup. (I know the BLE also triggers the wakeup but the code simply loops back to a deep sleep in that state.)
As I say, it all works well when I use the debugger (F5) but I don't get any MCWFT interrupt when I simply program the chip (Ctrl-F5).
I have tried adding GPIO/LED toggles and UART statements into the code and they all work happily but do show that the MCWDT ISR is not called and therefore I never wake up the chip nor do I set the (volatile) state variable used to take the next measurement.
I've checked the code for array index problems and pointers going 'wild' and I'm fairly sure that this is not a problem (but of course one can never be certain). Anyway, it would appear that the same code is being used both with and without the debugger attached.
What difference can simply running under the debugger make?
Susan
Show LessI am experimenting with DMA on the CYBLE-416045-02 module following the scenario in the MTB CAT1 Peripheral driver library documentation. What I find is that everything freezes on the call to Cy_DMA_Channel_Init. I have tried the code before and after the __enable_irq() with no difference. I assume the example just copies src to dst. Can anyone explain or help.
Thanks
#include "cy_pdl.h"
#include "cyhal.h"
#include "cybsp.h"
#include "cy_retarget_io.h"
int main(void)
{
/* Scenario: Initialize a 1D descriptor */
#define DATACNT (8UL)
cy_stc_dma_descriptor_t descriptor;
cy_stc_dma_descriptor_t nextDescriptor;
uint32_t src[DATACNT];
uint32_t dst[DATACNT];
cy_stc_dma_descriptor_config_t descriptor_cfg =
{
.retrigger = CY_DMA_RETRIG_IM,
.interruptType = CY_DMA_DESCR,
.triggerOutType = CY_DMA_DESCR,
.channelState = CY_DMA_CHANNEL_ENABLED,
.triggerInType = CY_DMA_DESCR,
.dataSize = CY_DMA_WORD,
.srcTransferSize = CY_DMA_TRANSFER_SIZE_WORD,
.dstTransferSize = CY_DMA_TRANSFER_SIZE_WORD,
.descriptorType = CY_DMA_1D_TRANSFER,
.srcAddress = &src,
.dstAddress = &dst,
.srcXincrement = 1U,
.dstXincrement = 1U,
.xCount = DATACNT,
.srcYincrement = 0U,
.dstYincrement = 0U,
.yCount = 1UL,
.nextDescriptor = &nextDescriptor,
};
cy_rslt_t result;
/* Initialize the device and board peripherals */
result = cybsp_init() ;
if (result != CY_RSLT_SUCCESS)
{
CY_ASSERT(0);
}
/* Initialize retarget-io to use the debug UART port */
result = cy_retarget_io_init(CYBSP_DEBUG_UART_TX, CYBSP_DEBUG_UART_RX, CY_RETARGET_IO_BAUDRATE);
__enable_irq();
if (CY_DMA_SUCCESS != Cy_DMA_Descriptor_Init(&descriptor, &descriptor_cfg))
{
/* Insert error handling */
}
/*Scenario: Setup and enable the DMA channel 0 of block DW0*/
cy_stc_dma_channel_config_t channelConfig;
channelConfig.preemptable = false;
channelConfig.enable = false;
channelConfig.bufferable = false;
if (CY_DMA_SUCCESS != Cy_DMA_Channel_Init(DW0, 0UL, &channelConfig))
{
}
Cy_DMA_Channel_SetDescriptor(DW0, 0UL, &descriptor);
Cy_DMA_Channel_SetPriority(DW0, 0UL, 3UL);
Cy_DMA_Channel_Enable(DW0, 0UL);
Cy_DMA_Enable(DW0);
printf("DMA Test Code\n");
for (;;)
{
}
}
Show Less