I am searching for the description of the IRQ-Handlers, which are defined in the stm32f4xx.c file. I can't find any description of them.
For example:
void WEAK CAN1_TX_IRQHandler(void);
void WEAK CAN1_RX0_IRQHandler(void);
void WEAK CAN1_RX1_IRQHandler(void);
void WEAK CAN1_SCE_IRQHandler(void);
Ok, some of them are clear, but where can I find the information, what CAN1_SCE means and under which conditions they occur?
Could anyone help me to find the description of the handlers?
Reference manual, CAN interrupts. For every interrupt source there is a handler.
It is Status Change Error Interrupt.
The error and status change interrupt can be generated by the following events:
Error condition, for more details on error conditions please refer to the CAN Error Status register (CAN_ESR).
Wakeup condition, SOF monitored on the CAN Rx signal.
Entry into Sleep mode
Related
I am using SDK 12.0.0.
I am working with low_power_pwm_init() to initialise the pwm and I have passed a handler while initialising. I want to stop the pwm from the handler hence I am calling low_power_pwm_stop() from the handler. I observe that the pwm doesnt stop.
I tried to investigate the reason for this and found that pwm_timeout_handler() in low_power_pwm.c is restarting the pwm. Below is the snippet that is suspect.
if (p_pwm_instance->pwm_state == NRF_DRV_STATE_INITIALIZED)
{
p_pwm_instance->pwm_state = NRF_DRV_STATE_POWERED_ON;
err_code = app_timer_start(*p_pwm_instance->p_timer_id, p_pwm_instance->timeout_ticks, p_pwm_instance);
APP_ERROR_CHECK(err_code);
}
In low_power_pwm_stop(), p_pwm_instance->pwm_state is assigned NRF_DRV_STATE_INITIALIZED and in the above snippet the timer is started if the driver state is NRF_DRV_STATE_INITIALIZED, causing the pwm to be ON again.
Is this a bug?
I had posted this question on nordic's devzone and below is the answer that I got from a nordic employee.
Hi,
I can see that this will be the case and will report it internally.
You can set a flag in the event handler and call the stop routine in
main.
Ole
So I guess this is a bug in nordic's sdk code.
I use Sample Grabber Sink in my Media session using most of code from msdn sample.
In OnProcessSample method I memcpy data to media buffer, attach it to MFSample and put this one into main process pointer. Problem is I either get memory leaking or crashes in ntdll.dll
ntdll.dll!#RtlpLowFragHeapFree#8() Unknown
SampleGrabberSink:
OnProcessSample(...)
{
MFCreateMemoryBuffer(dwSampleSize,&tmpBuff);
tmpBuff->Lock(&data,NULL,NULL);
memcpy(data,pSampleBuffer,dwSampleSize); tmpBuff->Unlock();
MFCreateSample(&tmpSample);
tmpSample->AddBuffer(tmpBuff);
while(!(*Free) && (*pSample)!=NULL)
{
Sleep(1);
}
(*Free)=false;
(*pSample)=tmpSample;
(*Free)=true;
SafeRelease(&tmpBuff);
}
in main thread
ReadSample()
{
if(pSample==NULL)
return;
while(!Free)
Sleep(1);
Free=false;
//process sample into dx surface//
SafeRelease(&pSample);
Free=true;
}
//hr checks omitted//
With this code i get that ntdll.dll error after playing few vids.
I also tried to push samples in qeue so OnProcess doesn't have to wait but then some memory havent free after video ended.
(even now it practicaly doesn't wait, Session rate is 1 and main process can read more than 60fps)
EDIT: It was thread synchronization problem. Solved by using critical section thanks to Roman R.
It is not easy to see is from the code snippet, but I suppose you are burning cycles on a streaming thread (you have your callback called on) until a global/shared variable is NULL and then you duplicate a media sample there.
You need to look at synchronization APIs and serialize access to shared variables. You don't do that and eventually either you are accessing freed memory or breaking reference count of COM object.
You need an event set externally when you are ready to accept new buffer from the callback, then the callback sees the event, enters critical section (or, reader/writer lock), does your *pSample magic there, exits from critical section and sets another event indicating availability of a buffer.
I have a mainwindow app, when shortcut is triggered, a dialog will popup to show some information, the user may do some configuration in this dialog, then a signal is sent back to the mainwindow, the mainwindow will do some further work. the pseudo code looks like this:
void MainWindow::actionConfigure_triggered()
{
configureDialog = boost::shared_ptr<configure>(new configure(this));
configureDialog->show();
connect(configureDialog.get(), SIGNAL(reload()), this, SLOT(clean_reload()));
}
but when I triggered this function several times, segmentation fault happens. I use debugger to trace the execution, SIGSEGV received when executing boost::checked_delete function.
Any help will be highly appreciated! Thanks in advance.
I just want the configure dialog to be created and deleted dynamically, or there are other better ways to implement this?
According to your backtrace the bug seems somewhere in destructor of configure and has little to do with the shared_ptr (except that it is the shared_ptr that calls the destructor)
Check if there are double deletes of your object, if yes there is probably some other reference to it which is not a shared_ptr deleteing the object.
In my user space Linux application, I have a thread which communicated to the main process through a pipe. Below is the code
static void _notify_main(int cond)
{
int r;
int tmp = cond;
r = write( _nfy_fd, &tmp, sizeof(tmp) );
ERROR( "write failed: %d. %s\n", r, strerror(r) );
}
Pretty straight forward. It's been working fine for quite a while now. But recently, the write call will fail with "interrupted system call" error after the programme went under some stress test.
Strangely, the stuff actually went through the pipe no problem. Of course I'd still like to go to the bottom of the error message and get rid of it.
Thanks,
The write(2) man page mentions:
Conforming to
SVr4, 4.3BSD, POSIX.1-2001.
Under SVr4 a write may be interrupted and return EINTR at any point, not just before any data is written.
I guess you were just lucky that it didn't occur so far.
If you google just for the "interrupted system call", you will find this thread which tells you to use siginterrupt() to auto-restart the write call.
From http://www.gnu.org/
A signal can arrive and be handled while an I/O primitive such as open
or read is waiting for an I/O device. If the signal handler returns,
the system faces the question: what should happen next?
POSIX specifies one approach: make the primitive fail right away. The
error code for this kind of failure is EINTR. This is flexible, but
usually inconvenient. Typically, POSIX applications that use signal
handlers must check for EINTR after each library function that can
return it, in order to try the call again. Often programmers forget to
check, which is a common source of error.
So you can handle the EINTR error, there is another choice by the way, You can use sigaction to establish a signal handler specifying how that handler should behave. Using the SA_RESTART flag, return from that handler will resume a primitive; otherwise, return from that handler will cause EINTR.
see interrupted primitives
When using a serial port via POSIX, it's recommended to save the original attributes using tcgetattr() before changing them with tcsetattr(), and then restore them before closing the port. What about when a program is terminated by pressing control-C or when the program receives SIGINT? I haven't seen this covered in any of the serial tutorials.
Apparently an atexit() function wouldn't be sufficient, because it's not called by the default SIGINT handler. So it seems installation of a signal handler would be necessary that restores the attributes to any serial ports still open. Is it even safe to call tcsetattr() from a signal handler?
One might simply dismiss this issue as insignificant, but it's common to terminate a program with control-C, especially one that can take tens of seconds to complete operations. If it's OK not to preserve serial port settings in this case, then there seems little reason to preserve them at all. If anything, it might be better not to bother, rather than do it inconsistently.
I found some examples of source code doing the above, but nothing well-documented. I guess I'm interested in some discussion of whether this is a good idea. Thanks.
After further research I think I've answered this to my satisfaction.
First, in the man page for signal I noticed that a signal handler is specifically allowed to call tcsetattr(), along with a few others:
The signal handler routine must be very careful, since processing elsewhere was interrupted at some arbitrary point. POSIX has the concept of "safe function". If a signal interrupts an unsafe function, and handler calls an unsafe function, then the behavior is undefined. Safe functions are listed explicitly in the various standards. The POSIX.1-2003 list is ... `raise()` ... `signal()` ... `tcsetattr()` [trimmed to relevant ones]
This strongly suggests that the POSIX committee had this exact kind of thing in mind, and leads to a straight forward approach where you change the SIGINT handler once you've opened serial and saved its attributes, then in your handler, restore them and the old SIGINT handler, then re-raise the signal:
static void (*prev_sigint)( int );
static termios saved_attr;
static int fd;
static void cleanup( int ignored )
{
tcsetattr( fd, TCSANOW, &saved_attr );
signal( SIGINT, prev_sigint );
raise( SIGINT );
}
int main( void )
{
open_serial_and_save_attrs();
prev_sigint = signal( SIGINT, cleanup );
...
}