Thank you for the reply.
Firstly, In the ISR, I am processing the cause of interrupt by reading
device registers and in addition, it is supposed to read data coming over
the device (its an HDLC device driver). I am not doing any floating point.
In fact, I have not declared any variable float or double. I am neither
allocating memory or deallocating it, I use a preallocated buffer to read
data. I obviously have to check device registers.When using
InterruptAttachEvent(), I call the same function that should have been
called by OS Kernel. The function is exiting properly.
I have removed all printfs that I had put in to debug my driver as printf
may block in ISR or cause problems.
Yes I have tried using mmap yesterday and succeeded indeed. The interrupt
register and queue is being written properly now. Thanks for that to all
those who corrected that approach.
Now only thing, I have to verify read and registration with OS before I can
declare my device driver as first successful one.
I have been told that I should register my device as serial driver (each
channel separately). I am looking into that.
In addition, I also need to check why InterruptAttach brings the whole
There is another question but its regarding QNX IDE, how do I set
breakpoints and wait. I cant get it properly, though I have gone through its
I was thinking if I could debug the driver using it from my Host PC running
on NT and target PC running QNX 6.2.1B PE. Right now I check with gdb or
using printfs (cant use it in ISR for obvious reasons).
“David Gibbs” <email@example.com> wrote in message
Moreshwar Salpekar <> firstname.lastname@example.org> > wrote:
I am writing a device driver.
I have two queries regarding that
When I use InterruptAttach(), the whole system hangs but if I use
InterruptAttachEvent(), there is no problem.Why?
What do you do in the function that is passed to InterruptAttach()?
What you are allowed to do in there is very restricted – most
library functions can not be called from inside an interrupt
handler, and if you do so, you will crash the system.
Also, inside an interrupt handler you have a very small stack, so
don’t use very much stack. (It is the kernel’s stack, since the
kernel calls your interrupt handler.)
Also, you can’t do any floating point.
My device requires
- Make a queue of buffers
- Put the start of the queue into the device register after converting
address into device physical address
I am using calloc function to create queue and then use mem_offset64 ()
convert the head address to physical address and put the address into
register. I initialize the buffers in queue with invalid values.
The device uses physical address of the buffers in queue to write data
I read using virtual address
Now when the device has something to inform, it uses a buffer from queue
store data and interrupts the processor.
I am getting interrupt but the data in the buffer is still invalid
Reading device status reveals that queue is full and no interrupt has
The physical address of the queue is same as what I generated using
mem_offset64 and the virtual address is same that I am using to read
interrupt data from queue. In other words, when I the physical address
the device register to obtain virtual address, I get same value that I
already using for read.
Now my problem is if both the addresses are correct, where is the device
actually writing? Why do not I get to see the data in the interrupt
If you call calloc() or any other flavour of simple allocation, the memory
isn’t promised to by physically contiguous.
As someone else noted, you want to use mmap() with special flags to
allocate physically contiguous memory. The example from the mmap()
/* Allocate a physically contiguous buffer */
addr = mmap( 0, 262144, PROT_READ|PROT_WRITE|PROT_NOCACHE,
MAP_PHYS|MAP_ANON, NOFD, 0 );
To allocate 262144 bytes of physically contiguous memory. Then
mem_offset() or mem_offset64() will give you the physical address
that you need.
It is the combination of MAP_PHYS|MAP_ANON and NOFD that allocate
physically contiguous memory.
QNX Training Services