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 <j...@rtems.org> escreveu:
>
>
> On Fri, Jul 26, 2019 at 3:13 PM Michel Macena <mmacena....@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@entry=INTERNAL_ERROR_CORE,
>>>
>>> the_error=the_error@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 <j...@rtems.org>
>> escreveu:
>>
>>>
>>>
>>> On Wed, Jul 24, 2019, 1:58 PM Michel Macena <mmacena....@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.hu...@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.hu...@embedded-brains.de
>>>>> PGP : Public key available on request.
>>>>>
>>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>>
>>>> _______________________________________________
>>>> users mailing list
>>>> users@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>>
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
