You are here

cm3 reset interrupt problem | Cypress Semiconductor

cm3 reset interrupt problem

Summary: 8 Replies, Latest post by martinschalk on 22 Feb 2015 04:21 AM PST
Verified Answers: 4
Last post
Log in to post new comments.
user_55680729's picture
10 posts

Dear Cypress Developer Community!

I am dealing with a simple Psoc 5 project using a TIMER and a UART and sometimes the debugger wont start my application.

After the reset interrupt entering the function "Reset"

__attribute__ ((naked))
void Reset(void)
    __asm volatile(



causes the system to get stucked, so the main function is never reached.

Having a look at the disassembly view I can see, that the cs3-start-routine got stucked in a while loop, see red marked lines:

0x00000010 <__cs3_start_c>:
 350:     uint8 buffer[] = {  (uint8)(BAL_MSG_ID_ACK << 8),
 351:                         (uint8)(BAL_MSG_ID_ACK),
 352:                         BAL_MSG_LENGTH_ACK,
 353:                         val
 354:                      };
0x00000010 push    {r7, lr}
0x00000012 ldr    r0, [pc, #50]    ; (64 <__cs3_start_c+0x54>)
0x00000014 ldr    r3, [pc, #50]    ; (68 <__cs3_start_c+0x58>)
0x00000016 b.n    5c <__cs3_start_c+0x4c>
0x00000018 ldr    r4, [r3, #4]
0x0000001A ldr    r1, [r3, #8]
0x0000001C ldr    r5, [r3, #c]
0x0000001E cmp    r4, r1

  77:     return BPL_TransmitMessage(buffer, 4);
0x00000020 beq.n    3c <__cs3_start_c+0x2c>
0x00000022 movs    r2, #0
0x00000024 b.n    32 <__cs3_start_c+0x22>
0x00000026 adds    r6, r4, r2
0x00000028 adds    r2, #8
0x0000002A ldrd    r8, r9, [r6]
0x0000002E strd    r8, r9, [r1, #0-8]
 335: }
0x00000032 mov    ip, r1
0x00000034 adds    r1, #8
0x00000036 cmp    r2, r5
0x00000038 bne.n    26 <__cs3_start_c+0x16>



I used to have this problem some weeks ago, but it somehow did not appear after I programmed the device with some other test application. However it popped up again and I cannot start any debug session, also the bootloader wont start my appication.

I am using a development board and my device is a CY8C5568AXI-060 and I am using the PSoC Creator 2.2.
(Higher PSoC Creator Versions will not work as they no more support that silicon version)

Any idea, what could cause this behavior?


Best regards,

user_55680729's picture
10 posts

I forgot to mention, that I can still debug other applications, which means it is not necessarily a hardware problem.

I connect the device via usb with my laptop and already tried another cable because sometimes, lets say in 1 of 100 attempts, it works. Besides programming the device always works fine.



user_1377889's picture
9260 posts

Your PSoC5 should have been replaced with am LP version for free, probably you missed that. Only very few CDC members still use a 3.3 version of Creator, so helping you is difficult.

A suggestion could be to contact your local Cypress FAE or distri and ask for a (late) replacement of your boards / chips.



user_14586677's picture
7646 posts

Or file a CASE and ask for a board swap -






/* Style Definitions */
{mso-style-name:"Table Normal";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman";

To create a technical case at Cypress -


“Technical Support”

“Create a Case”


You have to be registered on Cypress web site first.


Regards, Dana.

user_55680729's picture
10 posts

Thank's for your reply Bob! 

It's been a while since I've bought that development board and now I'm using it at home for some private project, so if it is no need, I try to avoid bying new devices unless I can get a LP version for free ;-)

I cant upgrade to a higher Creator version as the CY8C5568AXI-060 was a special silicon version, which is no longer supported in the creator's device list. Well, I don't expect too much and if I have to replace it, than I'll do so, but in this certain issue I want at least find out, why my device behaves like this.

I just figured out, that the programm is started by the bootloader so the problem only occures when I try to start a debug session.

I have created a new project from the scratch, copied all my files and the problem disappeared ... well for the moment, but I'm afraid it comes back sooner or later and I still have no clue where it comes from.

At work I had a similar issue with an psoc3 and it turned out that our RC-filters at the debug pins caused a delay causing the debugger beeing unable to connect. But in my case I'm using the development board this should not be the reason.



user_55680729's picture
10 posts

Thank's for the hint Dana!

I've bought this development board when I was a student, now I'm no longer a student and use it for provate purposes.

Do you think I can still get a board swap?

user_14586677's picture
7646 posts

You loose nothing by asking.


Regards, Dana.

user_1377889's picture
9260 posts

You may visit Cypress at "embedded world" in Nürnberg. I am quite certain that you can get help (and lots of information) at the Cypress boot. The representative for cypress in Germany will attend, there will be give-aways, BLE-solutions will be shown and a lot of nice people will be present.



user_55680729's picture
10 posts

Thank's for the support, Bob and Dana!

I've been to Embedded World last year and got a psoc4, which would probably do it  for me.
Nevertheless your suggestion to replace the device is reasonable and would certainly solve the problem.

I just hoped to find out, what exactly is the reason for this behavior, because you never know when you have to deal with these kind of problems and it is a relieve beeing able to put such problems to the section "lessons learned" ;-)


Log in to post new comments.