Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
projecta98
Level 3
Level 3
10 replies posted 25 sign-ins 5 questions asked

Hi,
I am using ModusToolbox to run the Low-power_CAPSENSE_FreeRTOS example on CY8CPROTO-062-4343W.

It seems to be work fine when using the debugger from ModusToolbox (i.e. the User LED blinks as part of the task).
But if a stop the debugger and reboot the board the application does not seem to run (i.e. the LED does not blink).

Does anyone has suggestion to address this issue?

 

0 Likes
1 Solution
projecta98
Level 3
Level 3
10 replies posted 25 sign-ins 5 questions asked

Hi Aditi,

I got it working without the debugger after addressing the following three issues:

  1. initialize_capsense() in capsense.c returns non-zero code (i.e. error code 6, which causes the system halt) if the system is reset immediately after touching the capacitive sensor (or while the sensor is touched). This problem exists in the original sample and modified version.  There is an assert after the initialize_capsense, which halts the application if there is an error when running without the debugger.

  2. In the modified code, I forgot that I had made a change in the cy8c6xxa_cm4_dual.ld under linker_script/TARGET_CY8CPROTO-062-4343W/COMPONENT_CM4/TOOLCHAIN_GCC_ARM
    • Original:    ram               (rwx)   : ORIGIN = 0x080C0000, LENGTH = 0x08000
    • Modified:   ram               (rwx)   : ORIGIN = 0x080A0000, LENGTH = 0x28000
    • The modified code runs fine (when using debugger) but it hangs on the line retain_sram_selectively() in main.c

  3. Finally, I also had some LED blinking logic added to the original code. This was initializing the same LED pin twice. It appears that a second call to  cyhal_gpio_init() results in error code: 0x4020101. In my example, I had CY_ASSERT(0) called if the cyhal_gpio_init() returned a non-zero value. The CY_ASSERT does not halt the system in debugger mode, but when running standalone it halts the system.
My solutions/workarounds to the above problems:
  1. I don't really need to use the capsense, so I have disabled that task. I only used this example as a starting point because it was for low-power and using FreeRTOS.
  2. I have disabled the call to  retain_sram_selectively() in the main.c (which seems to solve my issue) with a larger memory size. 
  3. Calling cyhal_gpio_free() before cyhal_gpio_init() seems to address this issue.

As of now, I consider this issue closed.

PS: Note that I also worked with the support team on this issue, you might be able to follow up the internal ticket.

View solution in original post

4 Replies
Aditi_B
Moderator
Moderator
Moderator
500 replies posted 5 questions asked 250 replies posted

Hi,

How are you stopping the debugger? Can you share the process with some snapshots of the debugger window?

Thanks

Aditi

0 Likes
projecta98
Level 3
Level 3
10 replies posted 25 sign-ins 5 questions asked

I have tried it multiple ways:

1. Stopping the debugger (using the Terminate button CTRL+F2). 
2. Unplugging the debug cable and power the board with external power supply.

The code which was loaded (that blinks the LED) does not run, unless it is started from the debugger and only runs until the debugger is connected.

 

I am guessing, the issue is related to reset vector. But I have tried with the Debug and Release build configuration and both behave the same.

 

I also tried to program the generated .hex file using PSOC Programmer 3.29.1 tool, but the tool does not recognize  the file and shows an error "Hex File parsing failure. Unknown record type".

 

0 Likes
Aditi_B
Moderator
Moderator
Moderator
500 replies posted 5 questions asked 250 replies posted

Hi,

Have you tried programming the application again via MTB launches menu after stopping the debugger?

Thanks

Aditi

0 Likes
projecta98
Level 3
Level 3
10 replies posted 25 sign-ins 5 questions asked

Hi Aditi,

I got it working without the debugger after addressing the following three issues:

  1. initialize_capsense() in capsense.c returns non-zero code (i.e. error code 6, which causes the system halt) if the system is reset immediately after touching the capacitive sensor (or while the sensor is touched). This problem exists in the original sample and modified version.  There is an assert after the initialize_capsense, which halts the application if there is an error when running without the debugger.

  2. In the modified code, I forgot that I had made a change in the cy8c6xxa_cm4_dual.ld under linker_script/TARGET_CY8CPROTO-062-4343W/COMPONENT_CM4/TOOLCHAIN_GCC_ARM
    • Original:    ram               (rwx)   : ORIGIN = 0x080C0000, LENGTH = 0x08000
    • Modified:   ram               (rwx)   : ORIGIN = 0x080A0000, LENGTH = 0x28000
    • The modified code runs fine (when using debugger) but it hangs on the line retain_sram_selectively() in main.c

  3. Finally, I also had some LED blinking logic added to the original code. This was initializing the same LED pin twice. It appears that a second call to  cyhal_gpio_init() results in error code: 0x4020101. In my example, I had CY_ASSERT(0) called if the cyhal_gpio_init() returned a non-zero value. The CY_ASSERT does not halt the system in debugger mode, but when running standalone it halts the system.
My solutions/workarounds to the above problems:
  1. I don't really need to use the capsense, so I have disabled that task. I only used this example as a starting point because it was for low-power and using FreeRTOS.
  2. I have disabled the call to  retain_sram_selectively() in the main.c (which seems to solve my issue) with a larger memory size. 
  3. Calling cyhal_gpio_free() before cyhal_gpio_init() seems to address this issue.

As of now, I consider this issue closed.

PS: Note that I also worked with the support team on this issue, you might be able to follow up the internal ticket.