Three chip erc32 Re: CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER macro issue

[Michel Macena]

 Sorry for the late response, but the board is with hardware issues wich
caused the strange behavior. I'm using another board with a single chip
ERC32.
Thanks for the help.

Em ter, 3 de set de 2019 às 17:08, Jiri Gaisler <jiri at gaisler.se> escreveu:

>
> On 9/3/19 9:14 AM, Jiri Gaisler wrote:
>
> Hmm, maybe clock driver code has been changed during the years to read or
> write some register bits that are illegal on the 3-chip ERC32. This would
> cause a trap to error mode and most likely a watchdog reset. I quickly
> looked through the ERC32 clock driver code but could not see anything
> obvious. It could also be an ERC32 interrupt driver issue - enabling
> interrupts seems to trigger the problem. I will try to run ticker on an old
> version of sis that did some more checks for the 3-chip version ...
>
> Could not find any problems with the ERC32 ticker.exe binary on an older
> sis, runs just fine.
>
> One thing to look out for is the watchdog timeout. RTEMS does not touch
> the watchdog, so if the board hardware or firmware does not disable the
> watchdog, program that runs longer than a few seconds will be reset by the
> watchdog. This would apply to ticker ...
>
> Jiri.
>
>
> On 9/3/19 12:57 AM, Joel Sherrill wrote:
>
> Jiri does this ring a bell with the old Tharsys board and 3 chip erc32?
>
> On Mon, Sep 2, 2019, 5:09 PM Michel Macena <mmacena.eng at gmail.com> wrote:
>
>> It is the ERC 32 chipset version (TSC691, TSC692 and TSC693 units), The
>> Board was manufactured by Tharsys, a french company, but it does not
>> exist anymore. The board manual dates from 2000.
>>
>> Em sex, 30 de ago de 2019 às 17:53, Joel Sherrill <joel at rtems.org>
>> escreveu:
>>
>>>
>>>
>>> On Fri, Aug 30, 2019, 11:35 AM Michel Macena <mmacena.eng at gmail.com>
>>> wrote:
>>>
>>>> Thanks for the answer, but the ticker sample program
>>>> has this macro in his system.h header. I can compile a program
>>>> with this macro but when  I load it, the board just ignores it an then
>>>> reset. If I change the
>>>> macro for the opposite one ("does not need the clock driver") the
>>>> program just works, except that I can't
>>>> use any time related routine. Also without the clock drive driver
>>>> enabled I can't communicate with the board (send and receive data).
>>>> I understand that the Macro enables the clock drive but how this
>>>> happens ? It changes a register value  in the chip ?
>>>>
>>>
>>> Setting that macro adds the clock driver to the set of statically
>>> installed device drivers. The code is in bsps/sparc/erc32/clock. It uses a
>>> timer on the erc32.
>>>
>>> Check that it survives initialising the clock and gets the interrupt ok.
>>>
>>> This isn't something I have heard of before. Is this a very early erc32?
>>> Just wondering with nothing specific in mind.
>>>
>>> --joel
>>>
>>>
>>>
>>>> Em sex, 30 de ago de 2019 às 03:21, Sebastian Huber <
>>>> sebastian.huber at embedded-brains.de> escreveu:
>>>>
>>>>> On 30/08/2019 19:09, Michel Macena wrote:
>>>>> > I still have the issue with the macro #define
>>>>> > CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER. I tried
>>>>> > a different version of RTEMS but It didn't work. Can someone explain
>>>>> me
>>>>> > how this macro works? So I can
>>>>> > try to figure out some patch or fix for my hardware.
>>>>>
>>>>> This configuration option enables the clock driver.
>>>>>
>>>>> I would run first the RTEMS test suite on your target. For example
>>>>> start
>>>>> with the ticker sample program.
>>>>>
>>>>> --
>>>>> Sebastian Huber, embedded brains GmbH
>>>>>
>>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>>> Phone   : +49 89 189 47 41-16
>>>>> Fax     : +49 89 189 47 41-09
>>>>> E-Mail  : sebastian.huber at embedded-brains.de
>>>>> PGP     : Public key available on request.
>>>>>
>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>>
>>>>
> _______________________________________________
> users mailing listusers at rtems.orghttp://lists.rtems.org/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190920/bb91d506/attachment-0002.html>