PSoC™ 6 Forum Discussions
Hello,
I am learning PSoC6 from the PSoC6 101 video tutorial series . From the PSoC 6 - 1-1-Introduction Alan Hawse told that PSoC6 chapters contains 4 parts.
I have downloaded the 1st,2nd and 3rd parts. And the last part is "connecting with WiFi & Cloud services".And I do not know the hyperlink of it. How can I get it?
Thanks in advance.
I've been trying to get my BLE over-the-air (OTA) device firmware update (DFU) to work. My bootloader is just a stripped down version of the CE16767 example code. I am fairly sure that it is working right because CySmart has no problem downloading my code and then after the download the system gets through the soft reset all the way the call to SwitchToApp(stackPointer, resetHandler) in Cy_DFU_SwitchToApp(uint32_t appId). The system then seems to lock up in the assembler code in Cy_DFU_SwitchToApp.
In Cy_DFU_SwitchToApp, stackPointer gets set to 0x08008000, which just doesn't seem right. To the best of my understanding, 0x08008000 is the starting address of core1 of the bootloader and the stack start for the main app should be at the end of the ram allocated to App1.
So my best guess is that I've somehow botched the updates I had to make to the 4 dfu_cm*.ld linker scripts. I have attached those scripts. Can anybody spot anything I bungled in them? Or do they look like they should be fine as is and I should look elsewhere?
Thanks for any and all help,
Ed H.
Show Less
I'm trying to adapt this code example to our design requirements. We are currently running this code example on PSoC 6 BLE prototyping kit (CY8CPROTO-063-BLE). I've switched the BLE stack to running on Cortex M0+ following the instructions and changed the toolchain to MDK. However we encounter HardFault during App2 startup, in the Cy_BLE_Start function. Our observations are:
- This issue does not occur when using ARM-GCC toolchain
- App1 (DFU mode) works properly
- With the debugger we were able to trace down the HardFault to function Cy_BLE_StackInit, and from the stack frame the PC register address when the fault occurred belongs to the function CyBle_RcbRegRead
0x10016588 0x00000028 Code RO 10367 i.CyBle_RcbRegRead cy_ble_stack_mdk_controller_soft_cm0p.a(CyBleRcb.o)
Any help would be appreciated. Thanks!
Show Less
I'm trying to implement something like this: Preserving debugging breadcrumbs across reboots in Cortex-M on CM4 in a CY8C6347BZI-BLD53. However, I'm unsure about where I can safely carve out a piece of RAM for saving breadcrumbs. If I look at cy8c6xx7_cm0plus.ld I see:
ram (rwx) : ORIGIN = 0x08000000, LENGTH = 0x24000
but in cy8c6xx7_cm4_dual.ld I see:
ram (rwx) : ORIGIN = 0x08024000, LENGTH = 0x23800
So, I have two ranges:
0x08000000 - 0x08023FFF
and
0x08024000 - 0x080477FF
There is also this comment in cy8c6xx7_cm4_dual.ld:
/* The ram and flash regions control RAM and flash memory allocation for the CM4 core.
* You can change the memory allocation by editing the 'ram' and 'flash' regions.
* Note that 2 KB of RAM (at the end of the RAM section) are reserved for system use.
* Using this memory region for other purposes will lead to unexpected behavior.
* Your changes must be aligned with the corresponding memory regions for CM0+ core in 'xx_cm0plus.ld',
* where 'xx' is the device group; for example, 'cy8c6xx7_cm0plus.ld'.
*/
I am using dual-core BLE, so I have to be careful not to step on that.
So, I started looking at saving data in flash. That looks like a great option. There is lots of room in even one row of sflash_user_data to store a whole cy_stc_fault_frame_t and whatever else I can think of. And, it should persist across power off. However, I am concerned that I can only write to flash by calling Cy_Flash_WriteRow. If I am dealing with a Hard Fault, maybe the stack is corrupted. Can I still call a function? I guess if the fault occurs while the Processor Stack Pointer (PSP) is active, the fault handler will run with the Main Stack Pointer (MSP), and I should be OK. (I'm running FreeRTOS.) But, what if the fault occurs in an Interrupt Service Routine?
Maybe the best option is all of the above, a RAM save area plus a flash row... if I can figure out where to put the RAM area.
Show Less
I'm using psoc6-wifi-bt (CY8CKIT-062-WiFi-BT) , Any Cloud MQTT Client to connect to IBM cloud so does MQTT client in modus toolbox uses SNI(server name indication)? Would appreciate help.....
Show LessI am trying to transfer data via UART into an FTDI USBUART cable at ~1MBaud. This works good except the receive buffer overflows, causing data loss. I have not been able to get any hardware or software flow control to work on CYBLE-416045-EVAL.
It appears that the CYBLE-416045 module does not have any combination of IO pins available for any SCB to use hardware flow control (CTS). The fitter always fails to find a pin for CTS. For some mysterious reason, the architecture requires the CTS pin to be a very specific option on the same port as the Tx/Rx pins. This seems like a silly oversight as any IO pin should be able to be routed to this signal. I also tried exposing the UART terminals in the schematic view (PSoC Creator 4.4) to see if I can use an internal signal, like a register component, but it requires connection to a dedicated IO pin; another very silly design oversight.
The FTDI cable can also send Xon/Xoff bytes, which I am able to receive and process. However, I can't find any way to halt the transmission of bytes already in the UART Tx buffer. I am transferring packets of 44 bytes at a time.
If I simply disable the UART, then all the untransmitted bytes in the buffer are lost. I have not found a way to determine how many bytes are thrown out (so I can send them later). I found this function: Cy_SCB_UART_GetNumLeftToTransmit(UART_1_HW, &UART_1_context); but it always returns zero. Looking in the UART_1_context struct (in the debugger) it always shows the buffer as done transmitting, however the oscilloscope shows that many bytes are still transmitted even after this function is called (I toggle an IO pin to see exactly when the function has been called).
If I rewrite my transmit function to send byte-by-byte and check if Xoff has been received, then I would kill my throughput speed and/or cause a huge unnecessary burden on the CPU.
Does anyone know how to actually pause the UART transmitter, or how stop it without loosing data in the buffer (or just get an accurate count of untransmitted bytes)?
Thanks in advance!
-Will
Show LessI am using the CY8CPROTO-063-BLE kit with an external ADC (the ADS8556-EVAL kit), and an isolated gate driver to drive the attached circuit.
I know that the power electronics switching works because when I apply test duty cycle values in the PSOC (such as 20 to 30%), Vout measures 14-18V on my multimeter. Deadtime in the PSOC PWM settings has been set to about 200 nanosec.
Now, I'm trying to close the feedback loop (inner current loop only). I'm measuring the input current (through R_INPUT_SHUNT) with an isolated amplifier, and reading the value with one channel of the external ADC. I'm using a static setpoint current of 0.3 amps for purposes of testing (I.E. "Can the PSOC drive the input current loop to 0.3 amps?")
--> Problem: as soon as I enable the PWM switching in my program, PSOC Creator says the debugger connection "drops out", and I can't reconnect to the PSOC without a complete power cycle. Could this be caused by switching artifacts of the PWM? If so, what are some techniques I can use to get the debugger/USB connection to operate with PWM switching?
Show LessI'd like to use some flash memory for storing fault data, and I was hoping that it would persist across resets. However, when I run CE220120 and look at the memory at 0x10081400 it's all zeros until the Cy_Flash_WriteRow. The flash memory is declared thusly:
CY_ALIGN(CY_FLASH_SIZEOF_ROW) const uint8_t flashData[CY_FLASH_SIZEOF_ROW] = {0};
After the Cy_Flash_WriteRow, the count data is shown, but if I do a reset, the debugger shows all zeros again.
I tried moving the flash storage to
CY_SECTION(".cy_sflash_user_data") const uint8_t flashData[CY_FLASH_SIZEOF_ROW];
and got the same results.
How can I store some persistent data?
Show Less
I want to port one of my existing projects from an STM32 to a PSOC 6 MCU which implements an HID USB interface that communicates with a desktop application I've developed. I've imported the "USB_HID_Generic" example for the CY8CKIT-062-WIFI-BT target to familiarize myself with how to adapt my existing USB code. Everything in this example seems pretty straightforward except for the ISRs. There are three of them (low/medium/high), and I am not sure how they are used. Are these meant to be adapted for the application, or do they perform the necessary low level USB operations. If it is the former, are there examples of this?
Also, I've noticed that the README.md file for this application throws an error when trying to open it with the default WikiText Editor.
Show LessHi,
I'm looking for CapSense and MagSense documention like Timer, Counter, and PWM (TCPWM) in PSoC 6 MCU: CY8C61x6, CY8C61x7 Architecture Technical Reference Manual (TRM). Could somebody help?
Show Less