On 21/9/19 8:34 am, Michel Macena wrote:
> 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.
Many thanks for let us all know.
Chris
___
users mailing
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 escreveu:
>
> On 9/3/19 9:14 AM, Jiri Gaisler wrote:
>
> Hmm, maybe clock d
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
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. I
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 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 ma
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 escreveu:
>
>
> On Fri, Aug 30, 2019, 11:35 AM Michel Ma
On 30/08/2019 18:33, Michel Macena wrote:
Thanks for the answer, but the ticker sample program
has this macro in his system.h header.
In case the ticker sample program doesn't run properly on your ERC32
board, then it makes no sense to start application development. You have
to figure out why
On Fri, Aug 30, 2019, 11:35 AM Michel Macena 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 on
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, exc
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.
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 Mac
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
On Fri, Jul 26, 2019 at 3:13 PM Michel Macena 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,
>>
>>
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_pr
On Wed, Jul 24, 2019, 1:58 PM Michel Macena 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
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.
Em qua, 24 de jul de 2019 às 02:46, Sebastian Huber <
sebastian.hu...@embedded-brains.de> escreveu:
>
>
> On
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
#include
#include
rtems_task Init(
rtems_task_argument ignored
)
{
uint16_t a=6;
printf( "Hell
Hi, I have compiled a test code for an ERC32 target board and loaded it
using gdb,
the code:
#include
>
> #include
> #include
>
> rtems_task Init(
> rtems_task_argument ignored
> )
> {
>
> uint16_t a=6;
> printf( "Hello World Michel\n" );
> printf( "numero: %d\n",a );
>
>
> }
>
>
18 matches
Mail list logo
