[ECOS] How to make a code from RAM startup to ROM startup?

[ECOS] How to make a code from RAM startup to ROM startup?

[Ling Su]

Hello everyone,

I am nearly finished debugging my code using RAM startup binary and GDB
stub, so I am looking for the method to make a ROM startup binary so that I
can burn it into a FLASH. Anyone can highlight me the steps I should follow?
Now I have a couple questions as following,

<1>. I changed the CYG_HAL_STARTUP from RAM to ROM in ecos.ecc, is that
enough?
<2>. If my code have some diag_printf() procedure call, should I remove
them?
<3>. Actually we I debugging my code, I find the serial port 1 is very
unstable due to the use of diag_printf(), since the call doesn't go through
serial driver, and some conflicts will happen easily when I am writing to
serial 1, and diag_printf write to serial 0. If I use GDB to debug, I am not
sure if gdb stub will keep polling the serial port if I doesn't set up any
break point and just let it free run after downloading the code, since I
always meet serial port write failure, I think this point might be
suspicious. Anyone know this? Please shed me some light! Thanks!

Best Regards,
-Ling

Re: [ECOS] How to make a code from RAM startup to ROM startup?

[Jesper Skov]

>>>>> "Ling" == Ling Su <lingsu@palmmicro.com> writes:

Ling> <1>. I changed the CYG_HAL_STARTUP from RAM to ROM in ecos.ecc,
Ling> is that enough?

It should be.

Ling>  <2>. If my code have some diag_printf() procedure call, should
Ling> I remove them?

If you do, the HAL IO driver should not be included and you'll save
some space.

Ling>  <3>. Actually we I debugging my code, I find the serial port 1
Ling> is very unstable due to the use of diag_printf(), since the call
Ling> doesn't go through serial driver, and some conflicts will happen
Ling> easily when I am writing to serial 1, and diag_printf write to
Ling> serial 0. If I use GDB to debug, I am not sure if gdb stub will
Ling> keep polling the serial port if I doesn't set up any break point
Ling> and just let it free run after downloading the code, since I
Ling> always meet serial port write failure, I think this point might
Ling> be suspicious. Anyone know this? Please shed me some light!

It's not quite clear to me what you are asking for, but using both the
HAL IO and the serial IO driver on the same controller is not
guaranteed to work.

Jesper

RE: [ECOS] How to make a code from RAM startup to ROM startup?

[Dan Conti]

> >>>>> "Ling" == Ling Su <lingsu@palmmicro.com> writes:
>
> Ling> <1>. I changed the CYG_HAL_STARTUP from RAM to ROM in ecos.ecc,
> Ling> is that enough?
>
> It should be.

You probably have to save the tree to a new directory and build there. At
least that is my experience w/ the config tool. Certain other changes don't
save properly, like changes to the memory layout (unless you rm
install/lib/target.ld then save the tree and build), etc.

-Dan

Re: [ECOS] How to make a code from RAM startup to ROM startup?

[Ling Su]

> Ling>  <3>. Actually we I debugging my code, I find the serial port 1
> Ling> is very unstable due to the use of diag_printf(), since the call
> Ling> doesn't go through serial driver, and some conflicts will happen
> Ling> easily when I am writing to serial 1, and diag_printf write to
> Ling> serial 0. If I use GDB to debug, I am not sure if gdb stub will
> Ling> keep polling the serial port if I doesn't set up any break point
> Ling> and just let it free run after downloading the code, since I
> Ling> always meet serial port write failure, I think this point might
> Ling> be suspicious. Anyone know this? Please shed me some light!
>
> It's not quite clear to me what you are asking for, but using both the
> HAL IO and the serial IO driver on the same controller is not
> guaranteed to work.
>

So, sounds to me it is no way to handle serial debugging with the GDB stubs,
since it is built on HAL_IO. The current situation for me is, I realized
that the HAL_IO and serial IO might have conflict problems, so I removed all
the diag_printf() call. I just use GDB to download the code onto the board,
then issue a "continue" command to let it run, in this case, I am not sure
if the HAL_IO layer still alive to access serial port?

I remember there is some serial test cases, which use obviously serial IO
running under GDB, they are all working very well. From Jesper's
explanation, I guess they should fail at least sometime, right?

Look forward to hearing some answers!

Best Regards,
-Ling

Re: [ECOS] How to make a code from RAM startup to ROM startup?

[Jesper Skov]

>>>>> "Ling" == Ling Su <lingsu@palmmicro.com> writes:

Ling> So, sounds to me it is no way to handle serial debugging with
Ling> the GDB stubs, since it is built on HAL_IO. The current

Correct, you cannot assume debugging to work on the same line you use
for IO with the serial device driver.

Ling> situation for me is, I realized that the HAL_IO and serial IO
Ling> might have conflict problems, so I removed all the diag_printf()
Ling> call. I just use GDB to download the code onto the board, then
Ling> issue a "continue" command to let it run, in this case, I am not
Ling> sure if the HAL_IO layer still alive to access serial port?

It should not be - the HAL_IO in ROM is used for the download. When
you issue the continue command, the RAM application will take control
of the board - and if it does not contain any diag_printf calls, it
should have no HAL_IO code either.

Ling> I remember there is some serial test cases, which use obviously
Ling> serial IO running under GDB, they are all working very
Ling> well. From Jesper's explanation, I guess they should fail at
Ling> least sometime, right?

No - they have been written carefully to allow both the IO serial
driver and GDB communication to coexist on the same line.   They use a
strict protocol that allow a clean separation of the two data streams
- you cannot guarantee the same with an application that uses the
serial while you try to debug it on the same line.

Jesper

Re: [ECOS] How to make a code from RAM startup to ROM startup?

[Ling Su]

> Ling> situation for me is, I realized that the HAL_IO and serial IO
> Ling> might have conflict problems, so I removed all the diag_printf()
> Ling> call. I just use GDB to download the code onto the board, then
> Ling> issue a "continue" command to let it run, in this case, I am not
> Ling> sure if the HAL_IO layer still alive to access serial port?
>
> It should not be - the HAL_IO in ROM is used for the download. When
> you issue the continue command, the RAM application will take control
> of the board - and if it does not contain any diag_printf calls, it
> should have no HAL_IO code either.
>
> Ling> I remember there is some serial test cases, which use obviously
> Ling> serial IO running under GDB, they are all working very
> Ling> well. From Jesper's explanation, I guess they should fail at
> Ling> least sometime, right?
>
> No - they have been written carefully to allow both the IO serial
> driver and GDB communication to coexist on the same line.   They use a
> strict protocol that allow a clean separation of the two data streams
> - you cannot guarantee the same with an application that uses the
> serial while you try to debug it on the same line.
>

Thank Jesper for the clear explaination, but I got more detail questions.
:-) The board I am using (vrc4373) has two serial ports, so I only the
second serial port for my only application, and the first serial port for
GDB downloading purpose. The serious problem I am facing is, I can smoothly
go through the handshaking phase between PC and the evaluation board, but we
the data transfer begans, the serial port will usually dead in the middle,
at that time I checked the Interrupt line of ther 85C30 (serial port) chip,
it is a low, which means the interrupt is activated but no acknowledegment,
so it can not receive any more interrupt. I tried many ways to figure out
what's wrong, unfortunately no outcome. :( Could anyone (or Jesper) please
kindly offer some clue on why the serial port is so fragile on large data
transfer? Thanks in advance!

Best Regards,
-Ling