cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC 4

ToVa_285016
Contributor

 Hi,

   

See the attached project.  It runs fine for a while, but eventually gets stuck here:

   

CY_NORETURN

   

CY_ISR(IntDefaultHandler)

   

{

   

    /***************************************************************************

   

    * We must not get here. If we do, a serious problem occurs, so go into

   

    * an infinite loop.

   

    ***************************************************************************/

   

    while(1)

   

    {

   

 

   

    }

   

}

   

Any ideas?

   

Thank you,
Tom

0 Likes
15 Replies
ETRO_SSN583
Esteemed Contributor

The causes of the interrupt are -

   

 

   

   

 

   

How do you handle them, your ISR code does not seem to manage the

   

causes ?

   

 

   

Regards, Dana.

0 Likes
ToVa_285016
Contributor

 Hi,

   

I added some interrupt code, but it never makes it there, just ends up in the CY_NORETURN anyways.  I know I am making some rediculos mistake...  I tried all three types of ISR input.

   

See attached.

   

Thank you,

   

Tom

0 Likes
ETRO_SSN583
Esteemed Contributor

I do not see any test for buffPtr exceeding array bounds ?

   

 

   

That could cause some crazy behaviour.

   

 

   

The ISR_BT should be a level triggered interrupt.

   

The ISR_QD should be a rising edge triggered interrupt.

   

The ISR_TARE should be a rising edge triggered interrupt.

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Esteemed Contributor

One other consideration -

   

 

   

   

 

   

Add the 20K from base to ground, that absorbs Icbo and keeps

   

the transistor off in case the PSOC pin become disconnected or

   

tristated or the transistor is in high T environment, generating a

   

lot of Icbo.

   

 

   

The transistor should be driven into sat, thats generally considered

   

Ic/10 current into base, so calc your series base R to achieve that.

   

 

   

Lastly the diode clamps on the relay coil, do not use generic small signal

   

diodes or rectifiers. Prefer use a fast rectifier, one that can handle the safe

   

area I-V that is generated by the coil.

   

 

   

Regards, Dana.

0 Likes
ToVa_285016
Contributor

 Thank you both for the informaiton.  I have updated the ISR inputs.  The buffPTR might be an issue, but there is no data currently going to the module.  

   

I have run across a more annoying error, that is I reconstructed some of the project, and with an identical set up, it now tells me that it is unable to pack the deisign into 4 UDBs (see attached).  I have tried to replace components and start over, but to no avail.

   

Any suggestions?

   

As far as the main project, I totally got rid of the UART interrupt, and it is still doing the same thing, in fact it happens much faster now.  I have also confirmed that it only freezes like this when passing over the 0 point a number of times.  I can go for ever in one direction, but not back and forth over the zero point.  Not sure if this is a red herring...
Thank you,
Tom

0 Likes
ETRO_SSN583
Esteemed Contributor

File a CASE on this, something is wacky.

   

 

   

Now will not build for me either.

   

 

   

    

   

          

   

To create a technical or issue case at Cypress -

   

 

   

www.cypress.com

   

“Support”

   

“Technical Support”

   

“Create a Case”

   

 

   

You have to be registered on Cypress web site first.

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Esteemed Contributor

I disabled glitch filtering and the project succesfully built.

   

 

   

Regards, Dana.

0 Likes
ToVa_285016
Contributor

 Thank you - I like simple fixes.  Unfortuantely I am still where I started with the system freezing up when I try to use a quadrature decoder... 

   

Any other ideas about that issue?

   

Thank you,

   

Tom

0 Likes
Bob_Marlowe
Expert II

The "NORETURN" system halt usually gets executed when an illegal instruction is executed or a non-existing memory area is accessed.

   

Did you already try to increase stack size which has been reduced in 3.1 per default?

   

 Can't you determine from the call-stack window where the interrupt occurs in the program?

   

Bob

0 Likes
ETRO_SSN583
Esteemed Contributor

This might help -

   

 

   

Default Stack and Heap Sizes

   

The default stack and heap sizes for new projects have been adjusted to more closely match real-world
requirements.When new projects are created, the stack size is set to be a fraction of the total SRAM in
the target device.The heap is set to a small value - 128 bytes - for all devices.You can, of course, modify
these settings in the Design-Wide Resources System Editor.For example, if you are not using any heap
based memory allocation the heap can safely be set to 0 bytes.
Note that some example projects and application notes were originally created on older versions of PSoC
Creator and use the larger default sizes.These projects will continue to build and run perfectly because
they have sufficient memory allocated.However, if you attempt to reproduce the example yourself in your
own project you may need to adjust the stack and heap.However, the example documentation will not tell
you to do that because the original project did not require the settings to be changed.

   

 

   

The heap and stack size were reduced in 3.1, try restoring to 3.0 levels 4K and 16K respectively.

   

3.1 default settings are now 128 bytes and 2K.

   

 

   

Regards, Dana.

0 Likes
ToVa_285016
Contributor

 The current heap and stack are 0x100 and 0x400 respectively.  The program says I have a max of 4096 bytes, so I cannot do 4k and 16k.  I will take that ratio and use it with the 4096 bytes and see what happens.

   

Thank you for your input!  I am learning things believe it or not...

   

Tom

0 Likes
ToVa_285016
Contributor

 I tried to change heap to 0x400 and stack to 0x0C00, and it gave me an error of 'regionRAM overflowed with stack'.  I thought I had 4096 to deal with?  So I changed it to 0x400 and 0x800 for heap and stack respectively.  This seems to have solved the problem!

   

Could one of you explain what happened with this change, and how it might be related to the ISR_NORETURN?  I just want to avoid this in the future.  

   

Thank you,

   

Tom

0 Likes
Bob_Marlowe
Expert II

When the stack is running into your variables or gets clobbered there might be the chance that an access to an invalid memory location is executed. This will fire an M0-core internal interrupt that branches to the No-return function.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

 I would like to continue with more questions about IntDefaultHandler...

   

1) Can I write my own to replace this one?

   

2) If I stop on a breakpoint inside IntDefaultHandler, is there any way to see which vector got me there?

   

Thanks, Jim

0 Likes
Bob_Marlowe
Expert II

The "vector" that sent you to the defaulthandler is used by the hardware fault interrupt, illegal instruction and NMI. Of course you may write your own handler, but what are you up to do when your system does not run? You can have a look at the call stack to see what the last functions were and you will see where the interrupt got fired. (Debug -> Windows - Call Stack)

   

You may use a watchdog to reboot your system.

   

 

   

Bob

0 Likes