PSoC™ 6 Forum Discussions
USB CDC echo example builds and runs fine right after creating the app in Modus Toolbox 2.4. Problems arise when I use the library manager to update the CY8CPROTO-062-4343W BSP from 1.3.0 to latest 3.x release.
With no other changes, the build now fails with errors:
make: *** [secondstage_build] Error 2
make[1]: *** [/Users/user/mtw/USB_CDC_echo_1/build/CY8CPROTO-062-4343W/Debug/libs/psoc6hal/COMPONENT_PSOC6HAL/source/cyhal_adc.o] Error 1
make[1]: *** [/Users/user/mtw/USB_CDC_echo_1/build/CY8CPROTO-062-4343W/Debug/libs/psoc6hal/COMPONENT_PSOC6HAL/source/cyhal_clock.o] Error 1
make[1]: *** Waiting for unfinished jobs....
conflicting types for 'CYHAL_CLOCK_IMO'
conflicting types for 'CYHAL_CLOCK_EXT'
conflicting types for 'CYHAL_CLOCK_ILO'
conflicting types for 'CYHAL_CLOCK_ECO'
conflicting types for 'CYHAL_CLOCK_WCO'
conflicting types for 'CYHAL_CLOCK_LF'
conflicting types for 'CYHAL_CLOCK_PUMP'
conflicting types for 'CYHAL_CLOCK_BAK'
conflicting types for 'CYHAL_CLOCK_FAST'
conflicting types for 'CYHAL_CLOCK_PERI'
conflicting types for 'CYHAL_CLOCK_TIMER'
conflicting types for 'CYHAL_CLOCK_SLOW'
conflicting types for 'CYHAL_CLOCK_ALT_SYS_TICK'
conflicting types for 'CYHAL_CLOCK_PATHMUX'
conflicting types for 'CYHAL_CLOCK_FLL'
conflicting types for 'CYHAL_CLOCK_PLL'
conflicting types for 'CYHAL_CLOCK_HF'
'cyhal_clock_t' has no member named 'div_type'
'cyhal_clock_t' has no member named 'div_num'
redefinition of '_cyhal_clock_allocate'
'cyhal_clock_t' has no member named 'div_num'
incompatible type for argument 2 of '_cyhal_utils_try_alloc'
too few arguments to function '_cyhal_utils_try_alloc'
'cyhal_resource_pin_mapping_t' has no member named 'inst'
'cyhal_clock_t' has no member named 'div_num'
'cyhal_clock_t' has no member named 'div_type'
'cyhal_clock_t' has no member named 'div_num'
'cyhal_clock_t' has no member named 'div_type'
'cyhal_clock_t' has no member named 'div_num'
'cyhal_clock_t' has no member named 'div_type'
'cyhal_clock_t' has no member named 'div_num'
'cyhal_clock_t' has no member named 'div_type'
'cyhal_resource_pin_mapping_t' has no member named 'inst'
incompatible type for argument 1 of '_cyhal_utils_reserve_and_connect'
incompatible type for argument 1 of '_cyhal_utils_reserve_and_connect'
I also get these warnings:
passing argument 3 of '_cyhal_utils_try_alloc' makes pointer from integer without a cast [-Wint-conversion]
implicit declaration of function 'cyhal_hwmgr_free_clock'; did you mean 'cyhal_hwmgr_free'? [-Wimplicit-function-declaration]
implicit declaration of function '_cyhal_utils_is_new_clock_format'; did you mean '_cyhal_utils_get_clock_count'? [-Wimplicit-function-declaration]
passing argument 2 of '_cyhal_utils_reserve_and_connect' makes integer from pointer without a cast [-Wint-conversion]
passing argument 2 of '_cyhal_utils_reserve_and_connect' makes integer from pointer without a cast [-Wint-conversion]
My problem is that I had configured many peripherals based on the CDC Echo app. Now, even when I downgrade to 1.3.0 again, the errors do not go away and I cannot manage to build the project.
How can I repair the project? Is there a way to better understand what needs to be changed in the example to be compatible with BSP version 3.0.0? Is there a changelog or do I need to manually run diffs on Github?
Thanks!
Show LessHi,
I used to work with PSoC 5LP and now I'm going to use PSoC6.
I have few questions-
1. Is PSoC6 has less uarts/i2c/a2d then PSoC5LP?
2. What is the benefit of usuing the VBUCK?
3. Do I need an external crystal oscillator? If I'm using USB I need extanell oscillator?
4. I saw that every port has it's own power supply pin. Can I give 1.8V to some ports and 3.3V to other?
5. Can I operate only part of the port? For example- give 3.3V to VDDD and all the othere are off.
BR
Shmuel
Show LessHi,
i developed a PSoC 6 based prototype pcb with BLE antenna and a pi matching network similar to the CY5677 BLE USB Dongle.
The antenna is a bit longer as described in AN91445 (Antenna Design and RF Layout Guidelines) and should be tuned by adjusting the length. I want to use the Pi network to tune the chip side. Unlike the system used in AN91445, I now have no real reference point.
The possibility I see would be to connect the VNA to the contact of C20 (see pic) and ground plane. Then I could tune the antenna. But for tuning the chip side I would then have to cut the antenna (and destroy my PCB).
How is this done in practice, for example for the BLE dongle?
Thanks!
Show LessHello.
I attached the Rx Not Empty Interrupt.
When there isn't 'Int_value = __get_BASEPRI();'
When there isn 'Int_value = __get_BASEPRI();'
'Int_value = __get_BASEPRI();' seems meaningless, why does it make a difference?
is there any Errata on this issue?
Thanks and Best regards.
Glenn.
Show LessI want to count at both edges of the clock with TCPWM as a counter. Can this be implemented?
Thanks,
Tetsuo
Has anyone been able to get the PicoVoice Wake Demo project (MTB project) to work on a CY8CKIT-062-BLE?
MTB allows for the CY8CKIT-062-BLE to be used as a BSP and to download the PicoVoice Wake Demo project for a compile.
I downloaded this project for the CY8CKIT-062-BLE and it built without error. However, when I go to run it, it faults out early in the pdm_pcm_clock_init(). A CY_ASSERT is issues and the code locks up in an infinite loop.
Here's a link to a related post: Picovoice-amp-PSoC-6-Evaluation . You'll notice that the CY8CKIT-062-BLE is not the original target BSP for this project.
Show LessHello.
I need the Register Manual.
I can't the documents in Infineon Site.
Please check it.
Thanks.
I am using the PSoC6 BLE Pioneer Kit for an application that needs two op amps. After looking at the data sheet, I was able to choose the correct pins and "OpAmp_Start();" both the components, but when I test them with a scope as a simple voltage follower, only OpAmp0 is operational.
Show LessHi there,
I test BLE with ModusToolbox and use the document "Chapter 9: Bluetooth® LE centrals". In this program is a menu. The program does not respond to my inputs.
The app_bt_management_callback function starts a new task,
…
#if (UART_INPUT == true)
/* Setup UART user input interface now that the stack is running */
xUARTQueue = xQueueCreate( 10, sizeof(uint8_t) );
cyhal_uart_register_callback(&cy_retarget_io_uart_obj, rx_cback, NULL); cyhal_uart_enable_event(&cy_retarget_io_uart_obj, CYHAL_UART_IRQ_RX_NOT_EMPTY , 3, TRUE);
xTaskCreate(uart_task, "UartTask", TASK_STACK_SIZE, NULL, TASK_PRIORITY, &UartTaskHandle); /* start task */
uint8_t helpCommand = '?';
xQueueSend( xUARTQueue, &helpCommand, 0); /* Print out list of commands */
#endif
…
The uart_task outputs the menu and waits for a value to be written into the xUARTQueue.
static void uart_task(void *pvParameters) {
uint8_t readbyte;
for(;;) {
if(pdPASS == xQueueReceive( xUARTQueue, &(readbyte), portMAX_DELAY)) {
switch (readbyte)
{
....
This function is supposed to read my input but doesn't do it.
The program hangs.
void rx_cback(void *handler_arg, cyhal_uart_event_t event) {
(void) handler_arg;
uint8_t readbyte; cy_rslt_t status;
BaseType_t xYieldRequired = pdFALSE;
status = cyhal_uart_getc(&cy_retarget_io_uart_obj , &readbyte, 1);
if(CY_RSLT_SUCCESS == status) {
xQueueSendFromISR( xUARTQueue, &readbyte, &xYieldRequired);
}
portYIELD_FROM_ISR(xYieldRequired);
}
**********Application Start*****************
Task UartTask started!
Task Status_Task started!
Commands:
? Help (this message)
s Start scanning and connect
S Stop scanning
d Disconnect
0...7 Control LED
r Read LED value
Status Tasks
********************************************
Task State Prio Stack Num
********************************************
Status_Task X 0 22 2
IDLE R 0 117 3
Tmr Svc B 3 99 4
UartTask B 5 3988 1
Can someone help me I think it's logically correct, but it doesn't work!! When I have solved this problem, I want to continue with BLE first.
Thanks for the help
Show LessHi,
We insert into PSOC6 pin a 455KHz Clock with 1uSec pulse width.
We have SW that sets up an interrupt for the rising edge of that input. The interrupt handler toggles an output pin each time it receives the interrupt. Effectively this should be dividing the input signal by 2.
We get at the output a frequency of about 100KHz, which is much less than expected. Is the issue that our pulse width is too short to be reliably recognized by the PSoC or is it that the frequency of the input signal is too high and that the frequency at which we are generating interrupts is too high and overloading the interrupt handler causing them to be lost?
thanks and regards,
Shlomi
Show Less