Strange bug on EP9302-based custom board

Fabien CASAS fcasas at
Wed Dec 14 17:00:36 UTC 2005

(Thanks for replying so quickly !)

Well, the ticker test doesn't run with that BSP (undefined exception 
once again), even when I remove my board-specific drivers.
When I follow Jay's instructions on the ticker application, I find a 
Link Register equal to 0x00498AE0, which is completely out of my  text 
section ( 0x00050000 to 0x0007d05f ).  This explains the Undefined 
exception, as there should be nothing but uninitialized RAM at this 
address ^^.

The call to rtems_task_wake_after is done in the read and write 
functions of my driver, not in the initialization function and not from 
an ISR. I don't think the problem comes from using that particular 
function, as the application crashes before I can do any read or write 
operation on my driver.

I'll try and find an old version of my BSP with which the ticker test 
worked (yes it had worked ;)), and trace the changes.

For now, I've restored a previous version of my BSP, with which my 
(multithreaded-)application works. But the ticker test desperately goes 
into Undefined exception in the middle of the first "puts".


Joel Sherrill <joel at> a écrit :

> Jay Monkman wrote:
>> Fabien CASAS wrote:
>>> Hi all !
>>> I'm porting RTEMS to an EP9302(ARM9)-based custom board, starting from
>>> ARM ports, and I'm stuck on a strange bug.
>>> I've got a base port that provides a console, a clock driver and some
>>> board-specific drivers. This base port seems to run fine, except for
>>> some improvements to be done.
>>> BUT : when I add a call to a function (e.g. a call to
>>> rtems_task_wake_after), or when I just add a local variable into a
>>> function of one of my drivers, the whole executive crashes, before the
>>> function is called.
>> Without this driver, does the ticker test run correctly?
> Always a good question to get answered. :)
> Where are you calling wake after from?  It should NEVER be called from 
> an ISR as it is a blocking call.
> It cannot be called before tasking is started.  That means it cannot 
> be called in driver initialization that occurs before the Init task runs.
>>> - or it hangs at the Undefined exception vector with a link register
>>> pointing to the IRQ exception vector.
>> This is the execption whose handler lives at address 0x00000004? You 
>> need to
>> find out what instruction is causing that.
>> Set a breakpoint at bsp_pretasking_hook() or some other function that 
>> gets
>> called early on.
>> Start you application. When you hit the breakpoint, set a new 
>> breakpoint at
>> 0x0000004.
>> Continue execution.
>> When you hit the breakpoint at 0x0000004, the Link Register will have 
>> the
>> address of 2 instructions past the one that caused you to get the 
>> exception.
>> If you are using software breakpoints, you have to stop execution 
>> before a
>> breakpoint on the execption vectors gets hit. Very early in startup, the
>> addresses of the exception handlers are copied to the exception vectors,
>> overwriting any software breakpoint you've set. When you stop and 
>> restart GDB,
>> the breakpoint gets re-inserted.

More information about the users mailing list