PSoC™ 6 Forum Discussions

Hi there

I'm struggling adding a simple dual core example. I found the example CE216795_PSoC6CualCPU that included two examples. Choosing "PSoC6DualCpuBlinky" it contains 2 sources (one for the cm0p and one for the cm4) and some make files.

So I opened ModusToolbox and clicked on "New Application". There I selected my DevBoard (PioneerKit CY8CKIT-062-WiFi-BT) and set up a Dual-CPU_Empty_PSoC6_App.

Now I guess I need to replace the "main.c" failes, but where do I put the "design.modus", makefile.init", "modus.mk" and the "makefile"?

Thx for any help.

Cheers Nik

Is possible to buy CY8CMOD-062S2-43012 (module with PSoC 62 and CYW43012 without base board) which is part of CY8CKIT-062S2-43012 development board for soldering on custom design pcb? I have not seen it anywhere separately.

Platform: CY8CPROTO-062-4343W, MTB 2.2

1) I need two pins to function as either GPIOs for bit-banging a proprietary protocol,  or as a high-speed UART. I need to switch between these functions in real time. What is the "cleanest" way to implement this: HAL, PDL-only, PDL plus DeviceConfig?

With HAL, the resources are allocated in real-time, so I'd need to "free" the UART or GPIOs before initializing/allocating the pins for the other function, right?

2) I have a similar situation with a 4-pin resistive touch display panel where I have to switch pins between ADC inputs and GPIO outputs. Here I am thinking of also using HAL but this would require allocating and freeing the ADC and GPIOs on every scan of the touchscreen. Would using PDL be cleaner?

I'm still not clear when to use HAL or PDL. I wish there was a checklist that would help answer that question. I feel like using the HAL is always the the best approach... except when isn't.  🙂 

Thanks for any help.

Actually i tried flashing the sample snip code of snip.gpio to my target board which is CY8CKIT_062 but it is not able to flash and display some errors which i could not understand since im new to this field so kindly help anybody...

the error output in the console goes like this:

Downloading Bootloader ...
Building apps lookup table
"**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****"
Downloading DCT ...
"**** OpenOCD failed - ensure you have installed the driver from the drivers directory, and that the debugger is not running **** In Linux this may be due to USB access permissions. In a virtual machine it may be due to USB passthrough settings. Check in the task list that another OpenOCD process is not running. Check that you have the correct target and JTAG device plugged in. ****"
Downloading resources filesystem ... build/snip.gpio-CY8CKIT_062/filesystem.bin at sector 1 size 104...
tools/makefiles/wiced_apps.mk:335: recipe for target 'FILESYSTEM_IMAGE_DOWNLOAD' failed
make.exe[1]: *** [FILESYSTEM_IMAGE_DOWNLOAD] Error 1
Makefile:351: recipe for target 'main_app' failed
make: *** [main_app] Error 2

PSoC Creator gives me static timing reports for -40° C, and I can't find a place to change that.

When, for example, the clock summary states 72 MHz required and the maximum is 85 MHz, will my device work at 60° C or 80° C as well?

I want to use resistive pull-up/down on a pin and just tried it with P9[6] (CYBLE-416045-02). That resulted in the output looking a lot like "strong drive" (both towards high and towards low, with sharp edges). When I used P10[1] instead, the behavior was as expected. The pin is driven by a PWM block. The architecture TRM (002-18176 Rev. *J) mentions that peripheral IO drive mode is different from DSI IO drive mode, but I don't know which actually applies in my case.

The goal is to use two IOs and a single external pull-up resistor (8k2 or 8k66 to 5V, safe for the clamping diodes) to produce 3-state PWM for an NCP81253 gate driver:

The pins "pwm" and "pwm_n" are used to see the raw PWM output on a scope.

pwm_H and pwm_L are used together to generate the 3-state PWM output:

• pwm_L can directly pull the output (TP) low
• pwm_H can pull the output to mid-level using the internal pull-down resistor when pwm_L is high-Z
• when pwm_H is high and pwm_L is high-Z, the internal pull-up (towards 3V3) and the external pull-up pull the output to 4V0 (with the internal pull-up being typically 5k6). This is high enough to be interpreted as "high" by the NCP81253.
• the internal pull-up in pull-up/down mode isn't necessary, but doesn't hurt in this case. If there was a mode that featured resistive pull-down only, I'd use it.

The project is attached.

Questions:

• Are there any restrictions regarding IO pin drive configuration?
• If so, where can I find them?
• Is there any part of IO pin configuration that I overlooked?

My target application (CY8C6347BZI-BLD54 or -BLD34, both 124-BGA) needs 12 resistive pull-up/down IOs, preferably in places that simplify PCB layout, preferably next to another IO configured as open drain pulling low (as in the attached project, for a total of 24 IOs for 12 gate drivers). I don't want to try all of those manually, especially given that I don't have a suitable dev board for that kind of trial and error experiment.

Using the PSoC6 PDM to PCM converter to convert data input from two digital MEMS microphones in PDM format to 16 bit PCM.  The PDM clock is determined by dividing a high frequency clock (16307.692kHz) by 8 = 2038.46kHz, which is further divided by 64 to determine the PCM sampling rate = 31.85kHz.  This PCM data is then downsampled by a factor of 4, and written to the I2S TX_FIFO where 16 bit words are output at a frame rate of 7.963kHz.  More specifically, two separate DMA transfers are used to transfer data output by the PDM to PCM converter to an audio buffer, and from the audio buffer to the I2S TX_FIFO.  When I listen to the I2S audio output, it is as expected for the first 1-2 minutes after program execution, but then I hear static, indicating that data is being read from the audio buffer faster than it is being written to.  This problem does not occur if there is no downsampling and the same value is used for the PCM sampling rate and I2S frame rate.  Any suggestions on how to ensure correct synchronization  of the PDM to PCM converted data and I2S audio output when the data is downsampled first?