Strange bug on EP9302-based custom board

[Fabien CASAS]

(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".


Thanks,
Fab






Joel Sherrill <joel at OARcorp.com> 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.
>
>
>