Software Forum Discussions

Hi Community, 

I'm currently working with CapSense Touch Switch Application. I'm using CY8C4245AXI-483, CY8C4245LTI-M445 MCUs. I want to use an API with which I can Reset or give a Refresh to my Capacitive Touch application for a moment(lets assume for 2 seconds) and then the CapSense will be active again. The step or implementation I need is because sometimes my touch gets unresponsive until and unless I remove the power supply and give it back again. 

I've came across a solution is to use "WDT Reset" as suggested by ChatGPT. But It'll simply restart my program, making it hard to debug the issue if some other issue hits my application. 

I hope you understand my issue and Terms. If not please feel free to ask me more about it. I'll be happy to explain my issue.

Thanks and Regards,

Pankaj

Recently, I cannot start a debug session, yet I can do the flash operation. I've tried other targets, regenerating launches, and rebooting, and none of them work. It's not clear why the debug session isn't completing.  Using a Kitprog 3. 

Console:

Started by GNU MCU Eclipse
Open On-Chip Debugger 0.11.0+dev-4.3.0.1746 (2021-09-16-07:59)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
adapter srst delay: 25
adapter srst pulse_width: 25
** Auto-acquire enabled, use "set ENABLE_ACQUIRE 0" to disable
cortex_m reset_config sysresetreq
cortex_m reset_config sysresetreq
Warn : SFlash programming allowed for regions: USER, TOC, KEY
Info : Using CMSIS-DAPv2 interface with VID:PID=0x04b4:0xf155, serial=1B1A05DD00189400
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : KitProg3: FW version: 2.30.1155
Info : KitProg3: Pipelined transfers enabled
Info : VTarget = 3.294 V
Info : kitprog3: acquiring the device (mode: reset)...
Info : clock speed 2000 kHz
Info : SWD DPIDR 0x6ba02477
Info : psoc6.cpu.cm0: hardware has 4 breakpoints, 2 watchpoints
***************************************
** Silicon: 0xE2F0, Family: 0x100, Rev.: 0x24 (B3)
** Detected Device: CYBLE-416045-02
** Detected Main Flash size, kb: 1024
** Flash Boot version: 1.20.1.45
** Chip Protection: NORMAL
***************************************
Info : psoc6.cpu.cm4: hardware has 6 breakpoints, 4 watchpoints
Info : starting gdb server for psoc6.cpu.cm0 on 3332
Info : Listening on port 3332 for gdb connections
Info : starting gdb server for psoc6.cpu.cm4 on 3333
Info : Listening on port 3333 for gdb connections
Info : SWD DPIDR 0x6ba02477
Info : kitprog3: acquiring the device (mode: reset)...
psoc6.cpu.cm0 halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00001f34 msp: 0x080477a8
** Device acquired successfully
** psoc6.cpu.cm4: Ran after reset and before halt...
psoc6.cpu.cm4 halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x1600400c msp: 00000000
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections


Error message:

Error in final launch sequence
Failed to execute MI command:
load C:/.....hex
Error message from debugger back end:
Error finishing flash operation
Failed to execute MI command:
load C:/.....hex
Error message from debugger back end:
Error finishing flash operation
Error finishing flash operation

Hello,

I am using the PMG1-S3 evaluation board (CY7113) to run the sample project "USBPD_DRP_EPR" provided on gitHub.

When I write and run FW from Modus Toolbox with [USBPD_DRP_EPR Program (KitProg3_MiniProg4)], it works fine, but when I run it with [USBPD_DRP_EPR Debug (KitProg3_MiniProg4)], the following error message appears.

（Error: Failed to read memory at xxx）

--------------------------------------------------------------------------------------

Started by GNU MCU Eclipse
Open On-Chip Debugger 0.12.0+dev-5.0.0.2401 (2023-05-16-04:28)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "swd". To override use 'transport select <transport>'.
adapter speed: 2000 kHz
** Auto-acquire enabled, use "set PSOC4_USE_ACQUIRE 0" to disable
cortex_m reset_config sysresetreq
Info : Using CMSIS-DAPv2 interface with VID:PID=0x04b4:0xf155, serial=051E07C203011400
Info : CMSIS-DAP: SWD supported
Info : CMSIS-DAP: Atomic commands supported
Info : CMSIS-DAP: FW Version = 2.0.0
Info : CMSIS-DAP: Interface Initialised (SWD)
Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1
Info : CMSIS-DAP: Interface ready
Info : KitProg3: FW version: 2.50.1383
Info : KitProg3: Pipelined transfers enabled
Info : KitProg3: Asynchronous USB transfers enabled
Info : VTarget = 3.276 V
Info : kitprog3: acquiring the device (mode: reset)...
Info : clock speed 2000 kHz
Info : SWD DPIDR 0x0bc11477
Info : [psoc4.cpu] Cortex-M0+ r0p1 processor detected
Info : [psoc4.cpu] target has 4 breakpoints, 2 watchpoints
*****************************************
** Silicon: 0x3501, Family: 0xC5, Rev.: 0x12 (A1)
** Detected Family: PMG1-S3
** Detected Device: CYPM1311-48LQXI
** Detected Main Flash size, kb: 256
** Chip Protection: OPEN
*****************************************
Info : gdb port disabled
Info : starting gdb server for psoc4.cpu on 3333
Info : Listening on port 3333 for gdb connections
Info : SWD DPIDR 0x0bc11477
Info : kitprog3: acquiring the device (mode: reset)...
[psoc4.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xa1000000 pc: 0x10000040 msp: 0x20007fe8
** Device acquired successfully
Started by GNU MCU Eclipse
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Power dropout detected, running power_dropout proc.
Sensed power dropout.
Sensed power restore, running reset init and halting GDB.
Info : SWD DPIDR 0x0bc11477
Info : SWD DPIDR 0x0bc11477
Info : SWD DPIDR 0x0bc11477
Info : kitprog3: acquiring the device (mode: reset)...
[psoc4.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xa1000000 pc: 0x10000040 msp: 0x20007fe8
** Device acquired successfully
Info : accepting 'gdb' connection on tcp/3333
Info : New GDB Connection: 1, Target psoc4.cpu, state: halted
Warn : Prefer GDB command "target extended-remote :3333" instead of "target remote :3333"
Info : SWD DPIDR 0x0bc11477
Error: Failed to read memory at 0x10000040
semihosting is enabled
Warn : No RTOS could be auto-detected!
Warn : No RTOS could be auto-detected!
Verifying region (0x00000000, 64356)... Match
Info : All data matches, Flash programming skipped
Info : SWD DPIDR 0x0bc11477
Info : kitprog3: acquiring the device (mode: reset)...
[psoc4.cpu] halted due to debug-request, current mode: Thread
xPSR: 0xa1000000 pc: 0x10000040 msp: 0x20007fe8, semihosting
** Device acquired successfully
Info : psoc4.cpu: bkpt @0x00000405, issuing SYSRESETREQ
[psoc4.cpu] halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x00000404 msp: 0x20008000, semihosting
===== arm v7m registers
(0) r0 (/32): 0x40100004
(1) r1 (/32): 0x00000405
(2) r2 (/32): 0x00000000
(3) r3 (/32): 0x00000000
(4) r4 (/32): 0x20008000
(5) r5 (/32): 0x08000000
(6) r6 (/32): 0x0ffff0e0
(7) r7 (/32): 0x00000000
(8) r8 (/32): 0x00020149
(9) r9 (/32): 0x802a4010
(10) r10 (/32): 0x1fff8000
(11) r11 (/32): 0x00000000
(12) r12 (/32): 0x016e3600
(13) sp (/32): 0x20008000
(14) lr (/32): 0x1000012b
(15) pc (/32): 0x00000404
(16) xpsr (/32): 0x61000000
(17) msp (/32): 0x20008000
(18) psp (/32): 0x30082884
(20) primask (/1): 0x00
(21) basepri (/8): 0x00
(22) faultmask (/1): 0x00
(23) control (/3): 0x00
===== Cortex-M DWT registers
Info : Power dropout detected, running power_dropout proc.
Sensed power dropout.
Sensed power restore, running reset init and halting GDB.
Info : SWD DPIDR 0x0bc11477
Info : SWD DPIDR 0x0bc11477
Info : kitprog3: acquiring the device (mode: reset)...
** Device acquired successfully
Info : SWD DPIDR 0x0bc11477
Error: Failed to read memory at 0x10000040
Info : SWD DPIDR 0x0bc11477
Error: Failed to read memory at 0x10000040
Info : SWD DPIDR 0x0bc11477
Error: Failed to read memory at 0x10000102
Info : SWD DPIDR 0x0bc11477
Error: Failed to read memory at 0x10000102

--------------------------------------------------------------------------------------

What is the cause of the error?

Similar errors have also occurred in other samples.

Regards.

use example RFCOMM_Serial_Port:

change some code:

static uint8_t spp_rx_flow_enable = 1;

void spp_connection_up_callback(uint16_t handle, uint8_t* bda)

{

    WICED_BT_TRACE("%s handle:%d address:%B\n", __FUNCTION__, handle, bda);

    spp_handle = handle;

    spp_rx_bytes = 0;

    spp_rx_flow_enable = 1;

}

void app_interrupt_handler(void *data, uint8_t port_pin)

{

    WICED_BT_TRACE("gpio_interrupt_handler pin:%d send_offset:%d\n", port_pin, app_send_offset);

    time_start = clock_SystemTimeMicroseconds64() / 1000;

     /* Get the status of interrupt on P# */

    if (wiced_hal_gpio_get_pin_interrupt_status(BUTTON_GPIO))

    {

        /* Clear the GPIO interrupt */

        wiced_hal_gpio_clear_pin_interrupt_status(BUTTON_GPIO);

    }

    // If we are already sending data, do nothing

    // if (app_send_offset != 0)

    //     return;

    // app_send_data();

    if (spp_rx_flow_enable) {

        spp_rx_flow_enable = 0;

    } else {

        spp_rx_flow_enable = 1;

    }

   

    wiced_bt_spp_rx_flow_enable(spp_handle, spp_rx_flow_enable);

    WICED_BT_TRACE("spp_handle:%d, enable:%d\n", spp_handle, spp_rx_flow_enable);

}

 

1. APP connect to 20706

2. APP send data to 20706, 20706 receive it .

3. 20706 click button, spp rx flow is disable.

4. APP send data continue to used up all credit.

5. 20706 click button, spp rx flow is enable.

6. APP send data continue.

 

 

two BUG:

1. 20706 lost data , when enable rx flow again, lost data 2 3 4 5

2. APP can not send data anymore, because 20706 not send a new credit when enable rx flow again.

 

I was optimistic we might finally have an OTA solution for the CYBLE-046415, but I'm not seeing an answer yet. I made a try at getting this to work, but can't seem top plug all the holes. 

1. Changed BSP to CY8CPROTO-063-BLE
2. Added template for TARGET_CY8CPROTO-063-BLE
3. Added psoc63_1m_cm0_int_swap_single.json to flashmap directory from github
4. Upgraded flashmap.py in scripts by copying from mtb_shared\mcuboot\v1.8.3-cypress\boot\cypress\scripts

But even though no internal flash is defined, it keeps trying to run the qspi configurator. 

The project is attached. Can you fix it?

$ make eclipse
make -C bootloader_cm0p eclipse MTB_APPLICATION_SUBPROJECTS="bootloader_cm0p blinky_cm4" MTB_APPLICATION_NA
ME="MCUboot-Based_Basic_Bootloader" && make -C blinky_cm4 eclipse MTB_APPLICATION_SUBPROJECTS="bootloader_c
m0p blinky_cm4" MTB_APPLICATION_NAME="MCUboot-Based_Basic_Bootloader" && true
make[1]: Entering directory '/cygdrive/c/Users/%USER%/mtw32/MCUboot-Based_Basic_Bootloader/bootloader_cm0p'
Removing .mtbqueryapi file...
Searching installed tools in progress...
Searching installed tools complete
../mtw32/MCUboot-Based_Basic_Bootloader/bootloader_cm0p/libs/mtb.mk:51: warning: overriding recipe for target 'bsp-assistant'.. AND MANY MORE OVERRIDES

=============================================================
= Generating cy_flash_map.h and flashmap.mk =
=============================================================
python ./scripts/flashmap.py -p PSOC_063_1M -i ./flashmap/psoc63_1m_cm0_int_swap_single.json -o ./source/cy
_flash_map.h > ./flashmap.mk
=============================================================

make[2]: Leaving directory '/cygdrive/c/Users/%USER%/mtw32/MCUboot-Based_Basic_Bootloader/bootloader_cm0p'
[INFO] Log file= "C:/Users/%USER%/AppData/Local/Temp/qspi-configurator-cli/qspi-configurator-cli-20230901.230
543.389-6888.log"

[INFO] Command line= "C:/Users/%USER%/ModusToolbox/tools_3.1/qspi-configurator/qspi-configurator-cli.exe --co
nfig"

Missing value after '--config'.
--config=
Error: Configuration file path is not set. Use the --config argument to set the configuration file.
make[1]: *** [../../mtb_shared/core-make/release-v3.2.2/make/core/bwc.mk:149: _mtb_build__legacy_project_pr
ebuild] Error 1
make[1]: Leaving directory '/cygdrive/c/Users/%USER%/mtw32/MCUboot-Based_Basic_Bootloader/bootloader_cm0p'
make: *** [C:/Users/%USER%/ModusToolbox/tools_3.1/make/application.mk:61: eclipse] Error 2

Hi,

I am following the guide for the DFU applications for PSOC6. 

My understanding for this processor (PSOC 61xx) is that it does have 2 cores, but the user only has access to the CM4 core.

When I compare the GCC linker file to the one generated from the DFU, I am seeing areas for 2 cores.

Is there a more specific version available for the PSOC 61 series? I don't want to waste Flash or RAM by reserving it for a purpose that is not used.

Here is the DFU-generated linker file:

Here is the default linker file (cy8c6xx6_cm4.ld):

I have asked about CYW43353 bt host wake here:

https://community.infineon.com/t5/Wi-Fi-Bluetooth-for-Linux/CYW43353-BT-host-wake-on-LWB5/td-p/471652

The thread was then locked and the accepted answer points to tutorial for CY20xxx parts.

Forgive me asking,  but will this actually work with CYW43353 series as well ?

Is it true then that the commands for BT host wake are the same across the whole range of your BT ICs ?

Kind regards.

Good morning,

I'm trying to configure the POSIF peripheral to read the position from an encoder. I'm facing a problem setting the RUN bit. After I've done all the configuration of POSIF and CCU4 registers I try to set the run bit of POSIF writing:

POSIF0->PRUNS = 1;

However, with step-by-step debug I can see that the bit is never set (the bit RB of register POSIF0->PRUN is always 0). The same happens even if I move this code at the very beginning of the main.

Is the writing to the PRUN register protected? Do you have any suggestions?

Thank you very much

Best regards

Francesco 

I bought some amount of CYW20719B1 (CYW20719B1KUMLG in specific) for some project I'm working on. I set them on a small board with a UART connection. I got them working with BtAttach and was able to communicate using standard Linux bluez. However, all of them have the same BT-Mac address of AA:AA:AA:AA:AA:AA. My question is what's the simplest way to flush a new address to the chip, as I have many boards to process. I read in this very forum something about .btp files, but either I don't understand something, or I don't have the .btp file for this chip. Where do I get the right .btp file if I really need one?

Thanks ahead,

Assaf