PSoC™ 6 Forum Discussions
The architecture TRM shows the ALU ASRC mux in two different ways, and they leave me a bit unsure about what I can expect. In the overview section we have this:
The above schematic would indicate that whenever PI is selected by SRC A, PO = PI. However, in the parallel in/out section, this schematic is used:
This indicates that I can use PI as input to the ALU, perform an operation on it, and store the result in A0 or A1 for parallel output. Which is right?
My goal is to have the following instructions:
- load A0 = D0; A1 = D1
- PO = A0
- PO = A1
- PO = PI & A0
Hello team --
If I have a PSOC 63 BLE connected to another PSOC 63 BLE, one as central and the other as peripheral, and they are communicating with the fastest connection interval (7.5ms), can I also set up each side to be an observer looking for "pings" from a remote acting as a broadcaster? What would the timing look like between Connection Intervals regarding how the 3 advertising channels will be scanned.
Please let me know if this is possible and what the timing looks like on the radio.
Regards,
Corey
Show LessI'd like my application to load a configuration from flash during startup, and then pick the corresponding opcodes for a datapath and store them in the datapath's configuration registers (DPATH_OPC0..3). Can I do that? Are there any best practices or caveats involved?
Show LessMy design is using almost all I/O of the 124-pin BGA package (76/87, or 88%) and depending on where I drop pins I get different timing analysis and PLD packing results. There will be some software controlled pins as well, but most are controlled by UDBs or SCBs and some are analog with their own restrictions. Is there a way to make life easier for the toolchain by picking pins that are (probably) easy to route to from a UDB? Or, putting it differently, are certain UDBs closer to certain ports than others? I know that the possibilities to re-route SCBs are very limited, but there should be an optimal solution for the rest.
There are obvious and documented limitations in the analog routing, where I had to place a few pins on certain AMuxBus segments to help find a solution. Does such a strategy exist for the digital part as well?
Show LessPer our previous discussion: PSOC6: CY8C6247BZI-D54 Pin out
-->The decision was made to use the PSOC 6 MCU CY8C624ABZI-D44 Instead of the CY8C6247BZI-D44. Thank you for your help in helping me persuade my customer to take that huge improvement now instead of later.
Overview:
I received the CY8CPROTO-062-4343W PSoC 6 Wi-Fi BT PROTOTYPING KIT. This kit contains a CY8C624ABZI-S2D44ES2 1943 B 33 CYP 636440 W3A633
1. Is this the latest chip with latest firmware?
Development:
2. I am not able to load the CY8CPROTO-062-4343W kit with wiced IDE, having read forums its my understanding that only modustoolbox may be used. Is that correct?
3. From reading the forums it appears that mbed is preferred and recommended for AWS IoT. Is that correct?
4. If 3. is correct, Then does Cypress recommend and provide a cypress-mbed like they do a cypress-freertos?
5. If available, which cypress provided mbed-application(s) is recommended to use as a base for my AWS IOT development? I need mqtt, tls, tcpip, and stuff I dont know I need 😕
Show LessHi All,
I have two projects using the PSOC 63 (CYBLE-416045-02) modules, as Central and Peripheral.
Both devices use Dual Core BLE, Controller on CM0+ and Host on CM4.
Peripheral is a battery operated device and must use DeepSleep when not active.
I have ran extensive testing (~120hrs continuous) on the communications keeping the Peripheral "awake", and unable to reproduce the issue.
Peripheral handles incoming data (write without response from central) from BLE AppCallBack, and sends Notification right the way with data already available.
What is happening:
- Communication runs fine (7.5ms intervals, 3x16byte packets every 8ms + 16byte every 1sec) in DeepSleep for seemingly random periods
- Anywhere between 5mins - 5hrs after, the Peripheral BLE Stack or Controller hangs somehow
- Central Stack stays CY_BLE_STACK_STATE_BUSY, and will not become FREE, unless I issue Cy_BLE_GAP_Disconnect(), to get back to "Scanning State"
- Peripheral still thinks it is connected, and CM4 goes on doing it's 500ms supervisory tasks in DeepSleep.
- Peripheral functions fine for the rest of the code, I can wake it up, go back to sleep again, and manually trigger BLE operations that fail.
- Attaching to CM0+ Controller core shows nothing suspicious, it only has Cy_BLE_ProcessEvents() and Cy_SysPm_CpuEnterDeepSleep(CY_SYSPM_WAIT_FOR_INTERRUPT), breakpoints here are constantly hit.
After Peripheral hangs, I tried:
- Send Notification - After about 2-3 notifications peripheral reports "CY_BLE_STACK_STATE_BUSY" and stays that way
- Cy_BLE_GAP_Disconnect() reports CY_BLE_ERROR_INSUFFICIENT_RESOURCES every time
Some of the things I tried to narrow things down and help the issue, with no luck:
- Increased Stack and Heap size on peripheral to 1600/1600 and 800/800 on Central
- Disabled debugging printf() on peripheral
- All kinds of ways and places to process received data, process data to be transmitted, call Cy_BLE_ProcessEvents(), Interrupt priorities
Anyone has encountered similar problems in DeepSleep?
How can I effectively debug what is happening under the hood of the BLE component?
Any way to recover from such a state?
Any pointers would be greatly appreciated.
Regards,
Adam
Show LessHello.
Below link has sample projects for Broadcaster and Observer on PSoC4.(Day008 and Day010)
https://github.com/cypresssemiconductorco/PSoC-4-BLE/tree/master/100_Projects_in_100_Days
Are there similar simple PSoC6 sample projects for Broadcaster and Observer?
Best Regards.
Yutaka Matsubara
Show LessI've put a lot of effort into reducing the attached design's appetite for MCs and PTs from >80% to below 50%. However, as soon as I add the 17th timer to the top-level design, routing fails. Why? And how can I proceed?
Show Less