PDA

View Full Version : interrupts



gdeber
04-09-2003, 12:49 PM
can any1 tell me info about managing interrupts?(int vector table, int handling ecc).

...or tell me where i can found doc...

tanx and sorry for my poor english!!

g3gg0
04-09-2003, 01:40 PM
on RAM 0x00000000 (its the same like 0x00100000) the ARM expects
the int table... it consists of longjumps (4 byte, ARM32 code) to the inthandler of your choice.

search for "ARM_doc.pdf" in yahoo.com and you'll find the processor
datasheet....
but you have still to enable the interrupts in the phone what is a little
bit more work

i already made this and my code runs perfectly...

i will release the new MADos package the next days...
watch http://nokiafree.org/forums/t40843/s.html

wumpus
04-09-2003, 03:22 PM
Search for the ARM7dtmi data sheet, it tells the exact how and what of interrupt processing.
The DCT3 specific part is checking the FIQ or IRQ lines in the approciate I/O port and acting accordingly, after which 1 is written to that line to confirm it was handled.

wumpus
04-09-2003, 10:35 PM
Oh another thing.. make sure there is enough STACK space, ARM has different stacks for each mode (FIQ/IRQ/System/etc).
If two mode stack pointers are equal, and the processor switches, your program dies horribly.

g3gg0
05-09-2003, 12:17 AM
Oh another thing.. make sure there is enough STACK space, ARM has different stacks for each mode (FIQ/IRQ/System/etc).
If two mode stack pointers are equal, and the processor switches, your program dies horribly.

yes, i really can confirm this :D

gdeber
05-09-2003, 12:25 PM
Oh another thing.. make sure there is enough STACK space, ARM has different stacks for each mode (FIQ/IRQ/System/etc).
the stack pointer (SP) is only one?


If two mode stack pointers are equal, and the processor switches, your program dies horribly.

how i can prevent this?

wumpus
05-09-2003, 01:41 PM
Set up the stacks properly..

For example, like this:


@ stack setup
adr r3, _stacksizes @ r3 = _stacksizes
ldr r1, _stackbase @ r1 = [_stackbase]
mrs r2, CPSR
bic r2, r2, #0x1F @ CPSR minus M bits
@ loop
b .beginstackloop
.stackloop:
orr r0, r2, r0 @ or mode and CPSR base
msr CPSR_cf, r0 @ set CPSR
ldrh r0, [r3,#2] @ get size
add r1, r1, r0 @ add size to stack base
mov SP, r1
add r3, r3, #4 @ next record
.beginstackloop:
ldrh r0, [r3,#0] @ r0 = mode
cmp r0, #0
bne .stackloop @ if not zero, loop

@ Go to System mode
orr r0, r2, #0x1F @ M = 11111 System
msr CPSR_cf, r0
... (rest of initialisation)



@ Stack sizes (mode, size in bytes)
_stacksizes:
.short 0x11, 0x100 @ FIQ
.short 0x12, 0x100 @ IRQ
.short 0x13, 0x10 @ Supervisor mode
.short 0x17, 0x10 @ Abort
.short 0x1B, 0x10 @ Undefined
.short 0x1F, 0x100 @ System
.short 0x00

g3gg0
05-09-2003, 03:39 PM
the stack pointer (SP) is only one?
how i can prevent this?

watch the arm_doc.pdf for "banked registers"

in FIQ/IRQ subroutine you have these registers on its own:
LR SP CPSR SPSR(saved CPSR from previous mode)
i hope i didnt forget anything :)

donjt forget: you cant change from USER to FIQ
you have first switch the privileged states and THEN to user :)
else u will fail like me... i tried to do a multitasking handler...
and i needed to get the userspace SP and LR... i didnt know
about 'STMEA {...} ^' (note the ^) which will work with usermode
registers

wumpus
05-09-2003, 04:02 PM
In FIQ, registers R8-R15 are all banked.. in IRQ only R13-R15

g3gg0: Userspace handler? Why? There is little to protect against anyway.

g3gg0
05-09-2003, 05:10 PM
In FIQ, registers R8-R15 are all banked.. in IRQ only R13-R15

g3gg0: Userspace handler? Why? There is little to protect against anyway.

oh, these are too? didnt know :)
the scheduler runs in FIQ mode, so i need to save the registers (LR)
of the current running "userspace" code and save it...
then i have to restore the registers (incl PC) and leave the handler.
each process has its own stack..

doesnt work yet :-P

wumpus
05-09-2003, 05:51 PM
Which state changes are exactly forbidden?
As I don't use User and Supervisor modes will I get into trouble with this?

Arghh I ran into trouble with my code upload facilities (program too large), it won't take long before I must start flashing as well

g3gg0
05-09-2003, 06:28 PM
Which state changes are exactly forbidden?
As I don't use User and Supervisor modes will I get into trouble with this?

Arghh I ran into trouble with my code upload facilities (program too large), it won't take long before I must start flashing as well

hahaha : )
so use MADos... u can choose the actions via menu ; p
and if u flash one 64k block into flash or if u upload 64 into ram
wont make any difference
i use rolis: Ctrl-W, enter, enter, pwron, enter, 4 seconds, ready


FIQ:
if a FIQ is triggered, the handler routine is in FIQ mode.. (privileged mode)
if u switch to user mode in this routine you cannot get back to FIQ again
you may switch from one privileged mode to an other, but not from
user mode to a privileged mode

wumpus
05-09-2003, 06:51 PM
hahaha : )
so use MADos... u can choose the actions via menu ; p
and if u flash one 64k block into flash or if u upload 64 into ram
wont make any difference
i use rolis: Ctrl-W, enter, enter, pwron, enter, 4 seconds, ready
I still use my modified KNOK and bootstrap loader, only have to press enter on the host side and the monitoring results come in :-) Most control logic remains on the PC, no phone side UI needed yet.

Although I did one ui based experiment: some timing tests on the LCD, with disappointing results; the serial interface is more than fast enough to do PWM based monochrome, the problem is that the display update/hsync is not synchronisable so 'tearing' always happens..

And yes, one day I will integrate my stuff with MADos, but I'm too busy with experimenting right now. SIMI and MDI :-)

g3gg0
05-09-2003, 07:06 PM
hehe : )
i tried PWM on LCD also, but also disappointing *g
lets overclock the LCD ; p

yeah, im frightened about the fact that everyone is developing
his own code and framework....
in the end everyone has something but nothing with a mainstream
line... different compilers, different schemes so nothing would fit
together.. so im trying to get all those developers right now at the
beginning together - thats in fact easier than doing this in 4 months
when everyone has its own framework half-done...

e.g. so now you have serial io with host, but MADos project misses
especially this part... still everyone works on his own package : )
except krisha and me ; )

: )

wumpus
05-09-2003, 07:14 PM
Well, at least we're all working on mostly different things, you have done multitasking, keyboard i/o, sound and lcd.. I have the serial debugging interface, DSP working with nokia codeblocks, documentation. If we combined it we'd have an almost full framework.

wumpus
05-09-2003, 07:57 PM
I put the source of the host program I use to upload the code (and receive serial packets) on Blacksphere, under Software.. have fun
It's Linux but should work under Cygwin without much changes..

g3gg0
05-09-2003, 08:03 PM
I put the source of the host program I use to upload the code (and receive serial packets) on Blacksphere, under Software.. have fun
It's Linux but should work under Cygwin without much changes..


wow nice thanx : )
btw... what does the DSP firmware in ROM handle and for what
nokia uploads extra code blocks?

wumpus
05-09-2003, 08:08 PM
btw... what does the DSP firmware in ROM handle and for what
nokia uploads extra code blocks?
The codeblocks are for bootstrapping, initialisation and all around wasting space in both the MCU and DSP memory :P

Serious: they exist so it is possible to update the DSP code without putting in a new ROM (as the DSP ROM is not flashable). It is like a layer between MCU and DSPROM. They don't do phone-specific things though AFAIK. The latest 3310, 3330 and 3410 firmwares look like they have the same version of them.. B60.6.*forgot the last number*

I'm still figuring out what the exact codeblocks do.. I've only seen 0x00, 0x01 and 0x14 used. Soon I'll post the code I use to upload them, and hopefully a working MDI send/receive interface..

wumpus
05-09-2003, 09:05 PM
Although I like to see the DSP as black box that 'does things' without really caring how it does it, to keep things managably complex: it has it's own I/O port ranges (pa0..paXXX), flags, and scheduling system.. madness!

*added section on dsp codeblocks on blacksphere