PSoC™ 6 Forum Discussions
Hello,
I am using PSoC 6 PROTO kit. I am trying to achieve synchronization in between two cores by using semaphores and sharing single UART port in two cores, CM4 and CM0+. I am getting a slight issue in the output. I checked with semaphore example provided by cypress then I created a empty project for dual core. With the help of Device Configurator I initialized the UART port and User LED on the board.
Same as "Semaphore Example" I am trying to send data to UART from both cores. But the project I created it shows some discrepancy. CM4 UART gets executed twice and CM0+ UART for once8[CM4 CM4, CM0+, CM4 CM4], whereas the output should be [CM4 , CM0+, CM4]. Please refer to attached output image.
The project I created is same as example project, I checked the clock is also same. but not getting why I am getting expected output. Need your help in understanding. As far as concept is concerned it is able to synchronize the shared resource, but not able to understand discrepancy in the output.
Thanks
Rushikesh
Show LessI'm attempting to load the Setup Package for CY8CKIT062WiFiBT
DOWNLOAD - CY8CKIT062WiFiBTSetupOnlyPackage_RevSS.exe
The process stops with a note that the PDL 3.0 is missing
I have PDL 3.1 loaded.
The "Download" button for PDL 3.0 sends me to a 401 error - page not found
Greg
Show Less
I am using PSoC 6 BLE Pioneer Kit. regarding my application, I need to have a digital output on P8[0] to P8[8] but it didn't work I tried the same program on other ports like P5[0] to P5[6] I got the digital output and it works fine. since I need a high number of digital output in my work, how can I make P8 work?
Show LessHello
This is the first time I have made a custom PCB for PSOC-6 device. I had been using PSOC-4 and 5 till date. Mistakenly the VDD_NS pin has been connected to GND instead of 3.3V. I am using Kitprog to program the device using SWD however I get a programming error. The device number is CY8C6137BZI-F54.
- Is it OK let the VDD_NS pin at 0V if we configure to use the LDO instead of SIMO buck?
- Is it possible that the programming error is because of the VDD_NS pin being connected to 0V instead of 3.3V? (I have configured the system settings for LDO and not SIMO)
Thank you
Show Lesserror occurring in KEIL IDE which weren't shown when executed in PSOC creator. Not able to resolve the error either. attached is the image of the problem I am facing. please let me know where is this going wrong.
thanks
Show LessI was using HAL PWM code to set the PWM resource to 100% dutycycle. What I got is that at 100% dutycycle, the PWM turned OFF (effectively 0%).
The issue is actually in the function cyhal_pwm_set_period_and_compare().
This is because:
cyhal_pwm_set_duty_cycle(&obj, 100, frequencyhal_hz)
{
...
uint32_t period = obj->clock_hz / frequencyhal_hz;
uint32_t width = (uint32_t)(100 * 0.01f * period);
cyhal_pwm_set_period_and_compare(obj, period, width); /* Here period = width @ 100% dc */
{
...
Cy_TCPWM_PWM_SetPeriod0(obj->base, obj->resource.channel_num, period - 1u); /* The period count is corrected here */
...
else
{
Cy_TCPWM_PWM_SetCompare0(obj->base, obj->resource.channel_num, compare);
/* Although the period was corrected (period-1) the compare in this case is period + 1. The compare count was not corrected. */
/* When compare > period, the result is an effective 0% dc */}
May I recommend the following changes to function cyhal_pwm_set_period_and_compare():
static cy_rslt_t cyhal_pwm_set_period_and_compare(cyhal_pwm_t *obj, uint32_t period, uint32_t compare)
{
if (period < 1 || period > (uint32_t)((1 << CYHAL_TCPWM_DATA[obj->resource.block_num].max_count)) - 1)
return CYHAL_PWM_RSLT_BAD_ARGUMENT;
period = period - 1u; /* Make the period count correction here. */
/* This fixes the issue where period == compare (ie duty_cycle == 100 percent) */
if (compare > period)
compare = period;
cyhal_gpio_t pin = obj->pin;
cyhal_gpio_t pin_compl = obj->pin_compl;
Cy_TCPWM_PWM_SetCompare0(obj->base, obj->resource.channel_num, 0u);
Cy_TCPWM_PWM_SetPeriod0(obj->base, obj->resource.channel_num, period);
bool swapped_pins = (CY_UTILS_GET_RESOURCE(pin, cyhal_pin_map_tcpwm_line_compl) != NULL) && (CY_UTILS_GET_RESOURCE(pin_compl, cyhal_pin_map_tcpwm_line) != NULL);
bool is_center_aligned = (TCPWM_CNT_TR_CTRL2(obj->base, obj->resource.channel_num) == CY_TCPWM_PWM_MODE_CNTR_OR_ASYMM) ||
(TCPWM_CNT_TR_CTRL2(obj->base, obj->resource.channel_num) == CY_TCPWM_PWM_MODE_CNTR_OR_ASYMM_UO_SWAPPED);
if ((swapped_pins) && (!is_center_aligned))
{
Cy_TCPWM_PWM_SetCompare0(obj->base, obj->resource.channel_num, period - compare);
}
else
{
Cy_TCPWM_PWM_SetCompare0(obj->base, obj->resource.channel_num, compare);
}
return CY_RSLT_SUCCESS;
}
Len
Show LessWe are using the CY8CMOD-064S0S2-4343W board design developed by Cypress and have created an identical board called Cloud Lock.
On the new Cloud Lock board the VCCD input supply is designed to use the internal Buck regulator as the source, same as the original design.
VDD_NS is sourced off board using a 2.5vdc supply and is the source for the internal buck regulator.
The output of the internal buck regulator is VIND1 this goes through a 2.2uH inductor to VBUCK which supplies the input power to VCCD through a zero ohm resistor (R26 see attached PDF for schematic)
When the power is first applied to the board there is no output from the internal buck on VIND1 and in looking at the TRM for the P64 the buck defaults to an “OFF” state.
The first-time power is applied to the P64 how do we get the buck regulator to output so we can get the device operational?
Show LessHi Everyone,
A few weeks ago I posted a message here complaining that Cy_TCPM_Counter_SetPeriod() is not behaving as documented. In my application I need to dynamically change the period of a counter anywhere from 1 to 400 Hz to generate a periodic interrupt that will trigger other events. The problem was that no mater what period I tried to set, the counter ignored it and remained running at the initial frequency when it was initialized. Frustrated I resorted to just de-initialize and reinitialize the counter with the new frequency. A few weeks later the problem came back to bite me again when I needed to change the period of a timer in PMW mode, and posted a second message here.
After detailed code review and debugging, and stepping through the code, I finally found a few errors in my code, AND, understood how the API really has to be used. This is not clearly documented anywhere, at least in the places where I looked (this forum and others).
First, don't repeat my errors:
1. Pay attention to the type of parameters that each function expects. For example,
Cy_TCPWM_TriggerStart_Single(Timer_1_HW, Timer_1_NUM); // The second parameter must be the timer NUMBER
Cy_TCPWM_TriggerStart(Timer_1_HW, Timer_1_MASK); // The second parameter must be the timer MASK (or the OR '|' combined mask of several timers, if you want to start them all in sync)
2. Double check the parameters used in the PDL documentation. In one instance the example has the second parameter incorrect (it uses counter MASK where it should use counter NUMBER, twice!). All xx_Single() versions of the functions work on a single timer and expect the timer number. That error in the example led me to believe that xx_MASK and xx_NUMBER are interchangeable, when they are NOT.
3. You must STOP the counter to make changes to the period, duty cycle, compare values, etc. There may be instances where this is not necessary, but better safe than sorry, in the PDL documentation the examples do not mention this, (at least for the functions that I used).
4. It seems that Cy_TCPWM_TriggerStopOrKill_Single() is not an atomic operation. You must test and make sure that the counter has stopped before continuing. This was the principal problem I had since the beginning.
So, here is the the safe method to alter counter parameters that I came up with:
uint32_t loops; // this variable is for debugging purposes only
void Change_Timer_1_Frequency(uint32_t _new_frequency)
{
uint32_t period = 0;
/* validate frequency range */
if (_new_frequency < MIN_FREQUENCY || _new_frequency > MAX_FREQUENCY)
return;
period = _Timer_1_clock / _new_frequency;
loops = 0;
Cy_TCPWM_TriggerStopOrKill_Single(Timer_1_HW, Timer_1_NUM);
/* IMPORTANT: wait for the timer to stop before changing registers */
while (Cy_TCPWM_Counter_GetStatus(Timer_1_HW, Timer_1_NUM) & CY_TCPWM_COUNTER_STATUS_COUNTER_RUNNING )
loops++;
Cy_TCPWM_Counter_SetCounter(Timer_1_HW, Timer_1_NUM, 0);
Cy_TCPWM_Counter_SetPeriod(Timer_1_HW, Timer_1_NUM, period);
Cy_TCPWM_TriggerStart_Single(Timer_1_HW, Timer_1_NUM);
}
I introduced the variable Loops for testing purposes. In a simple, Hello World type of program when only this code is running Loops may be 0, most of the time. But as the program grows in complexity with interrupts and external events going on at the same time, that won't be the case. In my application Loops ends up anywhere from 65 a to over 600 iterations before the counter stopped!
In summary, I thing that PDL is a good helper, but its documentation is minimal and the examples just snippets not really tested in an actual program. As a former boss of mine used to say "Trust is good, check is better!"
Show Less
In the description of cyhal_i2c_master_write():
"I2C master blocking write.
This will write size
bytes of data from the buffer pointed to by data
. It will not return until either all of the data has been written, or the timeout has elapsed"
Will this function also block the interrupts (e.g. uart, timer ) until it finished?
Show Less