This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Cortex M3 interrupt handling & context switching
- From: "simon dot kallweit at intefo dot ch" <simon dot kallweit at intefo dot ch>
- To: Remko TronÃon <remko at el-tramo dot be>
- Cc: eCos Disuss <ecos-discuss at ecos dot sourceware dot org>
- Date: Mon, 03 Nov 2008 14:22:24 +0100
- Subject: Re: [ECOS] Cortex M3 interrupt handling & context switching
- References: <490ACEB5.1010601@intefo.ch> <133fd4c60810310255p7b248173j888faeffd3c2ac0b@mail.gmail.com>
Remko TronÃon wrote:
Hi Simon,
Any ideas why this could fail? I can give more details on the implementation if necessary.
I'm not sure if this is of help in any way, but I was playing around
with eCos 2.0 a few weeks ago on a (virtual) ARM7TDMI board. When
trying the unadapted application on a (virtual) Cortex R4, some
problems arose due to restartable instructions. An LDM instruction
that adapted the SP was interrupted, the interrupt handler modified
SP, and when restarting the LDM instruction, the adapted SP was used
again, which resulted in a bad stack frame pop. I should check if the
problem persists in eCos CVS, and maybe investigate a bit further.
Thanks for the pointers. The Cortex R4 is as far as I know pretty
different from the M1/M3 architectures. Anyway, I have a solution now,
which seems to work *fingers crossed*. At least my serial driver now
seems to be stable and all serial tests passed multiple times. There
were two bugs in the existing code. The first problem was that the
cyg_scheduler_sched_lock counter went out of control under some
circumstances, which of course then prevented any further context
switching. The other problem was mangling with the system handler
register. I still have the two possible exception call path's to do a
context switch (the first being PendSV->SVC then second being
Thread->SVC). When restoring the system handler register I only change
the relevant bits (SHCSR_SVCALLACT and SHCSR_PENDSVACT). This does
prevent unwanted interrupt masking and seems to work so far. I'm still
unsure if my approach is correct and stable, only further testing will
show. Also I'm still eager to see ecoscentric's solution, they might
have a better more correct solution :)
Anyway, things are shaping up. If anyone is still interested in the
port, let me know. I'll switch to mercurial repositories in the near
future, until then all source is still available on the inthemill SVN.
Simon
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss