CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER macro issue

[Michel Macena]

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/20190727/b881a3f9/attachment.html>