- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The causes of the interrupt are -
How do you handle them, your ISR code does not seem to manage the
causes ?
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
File a CASE on this, something is wacky.
Now will not build for me either.
To create a technical or issue case at Cypress -
“Support”
“Technical Support”
“Create a Case”
You have to be registered on Cypress web site first.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I disabled glitch filtering and the project succesfully built.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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