PSoC™ 6 Forum Discussions
Are there standards for security in a silicon chip or microprocessor that Cypress' PSoC 6 has been evaluated against to provide customers a comparison between other security options?
I.E. Has Cypress' PSoC 6 been appraised by an independent entity, government body or financial institution for its security level?
Show LessIs it possible to stream audio from a client device to multiple peripheral devices at the same time using BLE? I'm trying to determine whether a psoc 6 would suit my needs.
I combined to CE220762 PDM to I2S example with the CE215118 Multi-master single slave project to test this, but when I press the button to start the recording DMA, Cy_BLE_GetNumOfActiveConn() begins to return a non-zero value even if the device is not connected to anything.
My project is attached for reference.
Any help would be appreciated.
Show LessHi,
I'm trying to find the API documentation for the PSOC6 device, I'm particularly looking for the i2c master documentation, but would
also like to know refer to find API documentation in general?
BR
Paul Grant
Show LessHi All,
I'm having difficulty running DMA to UDB FIFO's reliably. The core/PeriBus is clocking at 98MHz and the UDB ALU's are running at PeriBus/2.
Initially the DMA was over-running the UDB FIFO's as there was didn't appear to be any throttling of the DMA (no automatic routing of FIFO full/nempty signals to the DMA engine).
I have routed the f0_bus_stat and f1_bus_stat signals as DMA request signals (f0 is for incoming data and f1 for outgoing data). The fifo nfull signal activates when there is at least 2 spaces in the FIFO and the nempty activates if there are at least 2 bytes to be read. I've set these because the fifo's were still clearly being over/under flowed by the DMA.
This has led me to the belief that the Fifo Req signals are either too slow or extended such that a request for two DMA transfers actually results in more transfers occuring.
I managed to get some stability by reducing the DMA to only transfer one byte per request (even though the levels are set at 2). This appears to allow enough time for the bus status signal to update when the UDB is running at low throughput. However at high traffic levels, the DMA appears to not be able to keep up, presumably because of the overhead involved in each transfer request.
I've read the Component Author Guide chapters 7 and 11, but it would be easier to debug if there was more information about how the bus_stat signals are clocked (to a similar level as the blk_stat signals).
I'm considering trying to condition the request signals into a psuedo-pulsed format, but suspect that this is risky.
I'm aiming for a sustained 6.5MBytes/sec transfer rate for a block of 512 bytes.
I would welcome any advice or experience on reliably running DMA's to UDB FIFO's and any additional considerations I should take into account.
Regards
Zig
Show LessHi there,
We are running a simple project with Bluetooth using only single core CM0+ to test Bluetooth with low power functionality.
We've run into an unknown problem that is better depicted by the Call Stack that we've observed after stopping execution while in debug mode. This is the Call Stack on running into the problem:
0 Cy_SysPm_Sleep(cy_en_syspm_waitfor_t waitFor = <optimized out>) Generated_Source\PSoC6\pdl\drivers\peripheral\syspm\cy_syspm.c 382 0x10002BB2 (All)
1 Cy_BLE_HAL_SysPmSleep(cy_en_syspm_waitfor_t enWaitFor = <optimized out>) Generated_Source\PSoC6\pdl\middleware\ble\cy_ble_hal_pvt.c 1195 0x10003802 (All)
2 ll_wait_to_exit_dsm() ?????? ?????? 0x1000CF1A (All)
3 ll_exit_low_power_mode() ?????? ?????? 0x1000C3B2 (All)
4 CyBle_ControllerExitLPM() ?????? ?????? 0x1000BCBA (All)
5 BT_timer_process_signals() ?????? ?????? 0x1000A512 (All)
6 CyBle_StackTaskHandler() ?????? ?????? 0x1000A730 (All)
7 OS_scheduler() ?????? ?????? 0x1000B566 (All)
8 CyBleStackMgr_ProcessBleEvents() ?????? ?????? 0x10009E76 (All)
9 Cy_BLE_ProcessEvents() ?????? ?????? 0x1000A072 (All)
10 Transmission_BleSsHandler() main_cm0p.c 255 0x1000032E (All)
11 Cy_BLE_BlessInterrupt() Generated_Source\PSoC6\pdl\middleware\ble\cy_ble_hal_int.c 260 0x10003280 (All)
12 <signal handler called>() ?????? ?????? 0xFFFFFFF9 (All)
13 Cy_SysLib_ExitCriticalSection() Generated_Source\PSoC6\pdl\drivers\peripheral\syslib\gcc/cy_syslib_gcc.S 96 0x10002F6E (All)
14 Cy_SysPm_Sleep(cy_en_syspm_waitfor_t waitFor = CY_SYSPM_WAIT_FOR_INTERRUPT, cy_en_syspm_waitfor_t waitFor@entry = CY_SYSPM_WAIT_FOR_INTERRUPT) Generated_Source\PSoC6\pdl\drivers\peripheral\syspm\cy_syspm.c 382 0x10002BB8 (All)
15 SystemCore_TryToSleep() main_cm0p.c 310 0x100004C4 (All)
16 main() main_cm0p.c 361 0x100005AA (All)
The problem seems to be that, at times, the BLESS interrupt will trigger and wake up the device. On wake up, the CPU finishes executing the Critical Section inside Cy_SysPm_Sleep, and then the BLESS interrupt and its callback functions are handled. One of the internal callback functions attempts to put the CPU to sleep mode which causes a reentrant issue.
We've attached the project that we're testing if it helps to reproduce the described problem. Note that the problem doesn't occur until after connectnig to Bluetooth (regardless if a remote device remains connected or if Bluetooth goes back to advertising, the problem occurs).
Best,
Steve
Show LessThe release note says there is this change in SysPM:
SysPM callbacks
In the AFTER_TRANSITION mode the SysPM callbacks are executed in the sequence from last executed to the first registered instead of from last to the first registered.
The cy_syspm.* files are the same as 3.0.3. Is the change from the release note in the source code somewhere? I was given a temporary fixed cy_syspm.c for the mentioned problem for 3.0.3 and those changes are not in 3.0.4.
Show LessHi there,
Is there a way to confirm that PDL 3.0.4 is being used instead of an older version? Whenever right clicking a component (i.e. Bluetooth) and opening the PDL Documentation, we encounter this description which specifies the PDL 3.0.1 is being used.
Best,
Steve
Show LessHi there,
We are having issues with bluetooth advertisement. To preface, we are using single core (cm0+) for Bluetooth, and have registered a callback function for the AppHost using Cy_BLE_RegisterAppHostCallBack() which Processes Events. As suggested in this discussion, Ble connection stops working after 'Max num. of ble connections' times , we have modified the cy_ble_hal_int.c file so that the callback is called during certain events.
Bluetooth can start advertisement, time out, restart, and so on successfully as long as no device has ever been connected. However, after the first connection proceeded by the first disconnection, once advertising times out it fails to restart again. We can confirm it as an issue with the device entering deep sleep while bluetooth is advertising since the issue doesn't occur when we put it into sleep mode instead. Our low-power code is as follows:
for(;;)
{
if(!Cy_SysPm_Cm0IsLowPower())
{
Cy_SysPm_EnterLowPowerMode();
}
cy_en_ble_bless_state_t bleSsState = Cy_BLE_StackGetBleSsState();
if(bleSsState == CY_BLE_BLESS_STATE_ACTIVE || bleSsState == CY_BLE_BLESS_STATE_ECO_STABLE)
{
cy_en_syspm_status_t apiResult = Cy_SysPm_Sleep(CY_SYSPM_WAIT_FOR_INTERRUPT);
}
else
{
cy_en_syspm_status_t apiResult = Cy_SysPm_DeepSleep(CY_SYSPM_WAIT_FOR_INTERRUPT);
}
}
We are wondering what is the problem? Also, what is the best way to debug and stress test functionalities with deep sleep? In debugger mode, the described problem does not occur because the device does not enter deep sleep as it would during regular programming. Thank you.
Show LessI using the PSoc 6 Pioneer kit to go through the PSoC 101 video series. I'm on lesson 2-1 and have hit a snag trying to communicate with the device over the UART.
The device seems to program up fine with the example UART code, but I have no way to test it because I cannot connect to the serial port of the device from PuTTY or any other terminal.
I have installed PSoC Creator on two different computers both running Windows 10.
The device shows up on both in the Device Manager under 'Ports (COM & LPT)' and driver says it is Cypress v.2.0.0.2
I have tried connecting to the port with both computers from PuTTY and both computers give the same error:
"Unable to open connection to COM4
Unable to configure serial port"
This Thread describes apparently the same error:
But the fix there that is the accepted solution is simply to restart the computer, which does not work in our case.
Also: I've run the update manager to see if there was a new driver. But still no luck.
And: Other serial devices are working fine in the terminal. Whatever is going on is specific to the PSoC 6 kit.
Anyone having similar issues?
Thanks,
R
Show LessI am using the PSoC 63 Pioneer board in my custom app but it cannot wakeup from deep sleep using a RTC interrupt. If I wake up from deep sleep through some other way like GPIO, I will get the RTC interrupt afterwards. Does anyone know what is wrong? I copied the source code from the RTC example Custom_TickTimer_RTC01 and it still doesn't work in my project.
Show Less