CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER macro issue

[Michel Macena]

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.

Em sáb, 27 de jul de 2019 às 18:42, Michel Macena <mmacena.eng at gmail.com>
escreveu:

> Yes it is on real hardware, it is a real ERC32 chipset. The board was
> developed by Tharsys, but the
> company does not exist anymore. I'm not sure but in some way the hardware
> does not
> like the CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER macro.
>
> I've been using GDB like this:
>
>> sparc-rtems5-gdb
>> /home/inpe/rtems_exemplos/compile_test/hello_test/hello_exp.exe
>> set serial baud 19200
>> target extended-remote /dev/ttyS0
>> load
>> continue
>>
>
> When I use the CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER macro,
> the board  returns all
> prints properly at the serial port.
>
>
> Em sex, 26 de jul de 2019 às 17:47, Joel Sherrill <joel at rtems.org>
> escreveu:
>
>>
>>
>> On Fri, Jul 26, 2019 at 3:13 PM Michel Macena <mmacena.eng at gmail.com>
>> wrote:
>>
>>> I tried the break at _Terminate, for a working program (with the #define
>>> CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER macro) it worked and
>>> returned
>>>
>>>> Breakpoint 1, _Terminate (the_source=the_source at entry=INTERNAL_ERROR_CORE,
>>>>
>>>>     the_error=the_error at entry=5)
>>>>     at
>>>> /home/inpe/masters_project/src/rtems/c/src/../../cpukit/score/src/interr.c:34
>>>
>>>
>>> but for a program with the  #define
>>> CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER macro it didn't work, just
>>> returned the same message as before
>>>
>>>> [Inferior 1 (Remote target) exited with code 020]
>>>>
>>>
>>> I don't know exactly what may be causing this and don't know how can I
>>> track the issue ? any ideas ?
>>>
>>
>> Is this on real hardware? I re-read the first message and wondered about
>> that.
>>
>> But looking at the code again, it is a Classic API Init task and falling
>> off the bottom. This should be a fatal error.
>>
>> I suppose it is possible that the program has exited and the tick ISR is
>> occurring after RTEMS has terminated. But it still should be hitting the
>> _Terminate symbol.
>>
>> --joel
>>
>>
>>
>>>
>>> Em qua, 24 de jul de 2019 às 16:33, Joel Sherrill <joel at rtems.org>
>>> escreveu:
>>>
>>>>
>>>>
>>>> On Wed, Jul 24, 2019, 1:58 PM Michel Macena <mmacena.eng at gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks for the answer.
>>>>> Sorry for my ignorance but I can't see how is this related with my
>>>>> problem.  I didn't get the "Create bad task" problem. Also there is no
>>>>> fatal error with code 20.
>>>>>
>>>>
>>>> No RTEMS bsp makes any effort to return an exit status to the invoking
>>>> environment. What you are seeing gdb print is most likely random garbage.
>>>>
>>>> If you break at _Terminate, you will see why the program exited.
>>>>
>>>>>
>>>>>
>>>>> Em qua, 24 de jul de 2019 às 02:46, Sebastian Huber <
>>>>> sebastian.huber at embedded-brains.de> escreveu:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 23/07/2019 21:30, Michel Macena wrote:
>>>>>> > Hi, I have compiled a test code for an ERC32 target board and
>>>>>> loaded it
>>>>>> > using gdb,
>>>>>> > the code:
>>>>>> >
>>>>>> >     #include <bsp.h>
>>>>>> >
>>>>>> >     #include <stdlib.h>
>>>>>> >     #include <stdio.h>
>>>>>> >
>>>>>> >     rtems_task Init(
>>>>>> >        rtems_task_argument ignored
>>>>>> >     )
>>>>>> >     {
>>>>>> >
>>>>>> >          uint16_t a=6;
>>>>>> >          printf( "Hello World Michel\n" );
>>>>>> >          printf( "numero: %d\n",a );
>>>>>> >
>>>>>> >
>>>>>> >     }
>>>>>>
>>>>>> Please have a look at the INTERNAL_ERROR_THREAD_EXITTED fatal error
>>>>>> description:
>>>>>>
>>>>>>
>>>>>> https://docs.rtems.org/branches/master/c-user/fatal_error.html#internal-error-codes
>>>>>>
>>>>>> If you use GDB, then always set a break point to _Terminate. It will
>>>>>> hit
>>>>>> if the application terminated.
>>>>>>
>>>>>> --
>>>>>> 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 list
>>>>> users at rtems.org
>>>>> http://lists.rtems.org/mailman/listinfo/users
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20190830/5c2f3375/attachment-0002.html>