Strange bug on EP9302-based custom board

Fabien CASAS fcasas at altenso.fr
Thu Dec 15 17:29:48 UTC 2005


Well, 10µs would be great regarding the final goal of the board (I2C and 
OSLink comm.). And there's still the solution to speed up the EP9302 (up 
to 200MHz).
50ms is definitely poor performance, but I'm not sure it's the lowest 
working value.

I did no special effort for the clock ISR design: just stop the counter, 
call rtems_clock_tick(), then reload the counter.
I will try to find if my ISR gets interrupted with a tick at 10ms.



Joel Sherrill <joel at OARcorp.com> a écrit :

> Fabien CASAS wrote:
>
>> 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.
>
>
> You will very likely not be able to sustain a clock tick at that rate. 
> You can look at the code that is used to vector ISRs and count the 
> instructions.
>
> How many instructions can actually be executed by the CPU in 10 
> microseconds?  It can't really be all that many.  Assuming single 
> cycle instructions, I get a count of max 400 instructions.  If you mix 
> in any memory loads or stores (and there will be some) and account for 
> whatever wait states you have, then the real number of instructions 
> may be as little as 100.
>
> If you really need to do something at that frequency, you will have to 
> be extremely careful in your design.
>
> --joel
>
>> 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>





More information about the users mailing list