Strange bug on EP9302-based custom board

[Fabien CASAS]

Ok, I've restored a version of my BSP with which the ticker test works, 
and then I've added, one by one, my board specific drivers.
All worked fine !
Then I wanted to lower the tick value (I'm not using the 
CONFIGURE_MICROSECONDS_PER_TICKS for now). The ticker test works fine 
when I set the tick value to 50ms. But when I set the tick to 10ms, the 
ticker test crashes with an Undefined exception.

I may think that this is the cause of the problem I explained first, as 
I was configured with a tick at 5ms.

Do you think that this crash is due to my clock ISR, which takes too 
long (it does nothing special, though) ?

My EP9302 is running at 40MHz, and I need a tick at about 10µs, which is 
okay regarding the counter I'm using.


Fab
 







Fabien CASAS a écrit :

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