8 Replies Latest reply on Feb 22, 2015 4:21 AM by userc_41781

    cm3 reset interrupt problem


      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,

        • 1. Re: cm3 reset interrupt problem

          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.

          • 2. Re: cm3 reset interrupt problem

            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.





            • 3. Re: cm3 reset interrupt problem

              Or file a CASE and ask for a board swap -








              To create a technical case at Cypress -








              “Technical Support”


              “Create a Case”




              You have to be registered on Cypress web site first.




              Regards, Dana.

              1 of 1 people found this helpful
              • 4. Re: cm3 reset interrupt problem

                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.





                • 5. Re: cm3 reset interrupt problem

                  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?

                  • 6. Re: cm3 reset interrupt problem

                    You loose nothing by asking.




                    Regards, Dana.

                    1 of 1 people found this helpful
                    • 7. Re: cm3 reset interrupt problem

                      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.





                      1 of 1 people found this helpful
                      • 8. Re: cm3 reset interrupt problem

                        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" ;-)