Strange bug on EP9302-based custom board

[Joel Sherrill <joel@OARcorp.com>]

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


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985