headers
Alex Lindeijer | 1 Sep 2009 08:24
Favicon

Ethernet traffic causing loss of bytes on UART

Hi
We are running a serial port on 38400 baud and are seeing loss of Rx
bytes. When unplugging the ethernet cable we have no problems.
We are using a MPC8541, it has a PC16550D programming model for the
UART. I see that the driver uses the FIFO and reads until the FIFO is
empty.
The Ethernet driver is a tsec driver .
We encountered similar problems when writing to flash. We got some
verification/write errors with Ethernet traffic going. In that case we
masked the interrupts while writing to flash. But we don't want to do
that when receiving bytes on the serial port of course.

Has anybody else encounter such problems? Any hints in were to look? We
have been looking into this now for some time and are getting a bit
desperate.....;-(

Cheers
Alex Lindeijer

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 6 comments |
headers
Danny Sade | 1 Sep 2009 10:20

Zero vector interrupts (SIVEC=0) on MPC8xxx

Hi All,
Did anyone encounter zero vector interrupt (SIVEC = 0) on the MPC8xxx ?  I recently encountered this kind of
interrupts, and according to Freescale support and the documentation this kind of interrupt may occur
during normal operation and a service routine for this interrupt must be provided.
The thing is that the current HAL implementation, at the macro hal_intc_decode at variant.inc, decodes
this interrupt as a decrementer interrupt.  As a result, whenever this zero vector interrupt is asserted
the tick ISR is called.  If the there are only few such interrupts, this is hardly noticed.  But obviously,
when there are many such interrupts all the time related services (such as cyg_thread_delay() ) cannot
not function the way they should.
I'm not sure what is causing these zero vector interrupts.  I can tell that it is related to the IDMA - whenever
I have a lot of IDMA transactions, I see a lot of zero vector interrupts.

Any ideas?

Thanks

Danny

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 2 comments |
headers
cetoni GmbH - Uwe Kindler | 1 Sep 2009 10:36
Picon

Re: uSTL hello world

Hi John,

> There seems to be a problem with the uSTL hello world example given in
> the uSTL documentation. The code produces no output. However, if I add a
> printf() call after the cout.flush(), then I see _both_ messages.
> 
> This is not a case of printf() flushing the output - I can observe the
> output from cout on the diagnostics channel _before_ the call to
> printf() is made. In fact, if I move the printf() call to the start of
> main(), then everything still works.

I can confirm this on my target. For me it smells like a linker issue. I 
wrote the following main function from the example an added a test 
function with a printf call that is not called from main.

void test()
{
     printf("Hello printf2!\n");
}

int main (int argc, char* argv[])
{
     cout << "Hello world!\n";
     cout.flush();
     return EXIT_SUCCESS;
}

If I execute main then I can see the output of cout. If I remove the 
test function with the printf reference then the main function does not 
print anything. So adding a printf reference makes cout working - so I
(Continue reading)

Permalink | Reply | 12 comments |
headers
Steven Clugston | 1 Sep 2009 10:58
Picon
Picon
Favicon

RE: ARM7 ADC drivers - any progress?


>> Hi Steven
>> I do not know the AT91SAM7S, but assume its pretty the same ADC peripheral.

>> No, I can not think of anything why it should not work on your S-machine.
>> But indeed (and for historical reasons) there is another init-routine in my system - see attachment. If
it works with this, then check out what you really need of it :-) Lazy approach!

>> Another hint: Our board runs with an external 25 MHz clock and parameters are such to bring its main clock
to 48 Mhz (done in configtool).

>> Hope this brings you one step further. Regards Robert

Thanks for the additional code Robert.

I chased it through from just taking single shot software triggered samples with no DMA and in the end, just
changing the code from TC2 to TC1 made it work. For some reason just enabling HW triggering and setting it to
TC2 stops the ADC from returning any results. I've not had chance to find out why yet, but I'm not sure which
TC is being used for the system timer. I had assumed it was TC0, but if it is TC2, then this might explain a few things.

I'm slightly confused by a couple of things, perhaps someone who is familiar with the AT91 hal code might be
able to clearup.

In hal/arm/at91/at91sam7s/current/src/at91sam7s_misc.c:

#ifdef CYGBLD_HAL_ARM_AT91_TIMER_TC
  /* Enable peripheral clocks for TC 0 and 1 if they are to be used */
  HAL_WRITE_UINT32(AT91_PMC+AT91_PMC_PCER,
                   AT91_PMC_PCER_TC0 |
                   AT91_PMC_PCER_TC2);
(Continue reading)

Permalink | Reply | 3 comments |
headers
Tarmo Kuuse | 1 Sep 2009 10:59
Picon
Favicon

Re: How to deconfigure an interface?

Hi Stanislav,

Stanislav Meduna wrote:
> I'd like to be able to change an IP address of an interface
> without reboot. 

Same here.

> The same happens if I try to set the address using SIOCSIFADDR.
> Is this the intended behaviour? Shouldn't the SIFADDR
> change the address and AIFADDR add a new one?

I think it's intended behaviour.

> Is there a way to bring the IP stack back to the clean
> state, or does one needs to deconfigure the interface
> step-by step by removing addresses already configured
> using SIOCDIFADDR (which works)?

There could be a better way, but I just do SIOCGIFADDR to read the 
current addresses from an interface and delete them with SIOCDIFADDR. As 
input, the "struct ifreq" needs the interface's textual name (e.g. 
"eth0"). Works fine.

Another task which needs doing is clearing the routes table. There 
exists a function "cyg_route_reinit()" which simply flushes all routes. 
Unfortunately it also deletes routes for the local loopback and all 
other interfaces you may have. I haven't yet figured out how to delete 
the routes only for a given interface.
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Dallaway | 1 Sep 2009 11:02
Picon

Re: uSTL hello world

Hi Uwe

Uwe Kindler wrote:

> I can confirm this on my target. For me it smells like a linker issue.

I agree that this smells like a linker issue. Does the problem still
occur if you link without -Wl,--gc-sections ?

John Dallaway

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 1 comment |
headers
Christophe Coutand | 1 Sep 2009 11:08

RE: Ethernet traffic causing loss of bytes on UART

Hi Alex,

Which TSEC driver are you using? Have you tried the driver from Edgar:
http://www.ecosforge.net/ecosforge/trunk/ecos_mpc8313/

I think MPC8313 UART driver should also be compliant with MPC8541.

Christophe

-----Original Message-----
From: ecos-discuss-owner <at> ecos.sourceware.org
[mailto:ecos-discuss-owner <at> ecos.sourceware.org] On Behalf Of Alex
Lindeijer
Sent: Tuesday, September 01, 2009 8:24 AM
To: ecos-discuss <at> sourceware.org
Subject: [ECOS] Ethernet traffic causing loss of bytes on UART

Hi
We are running a serial port on 38400 baud and are seeing loss of Rx
bytes. When unplugging the ethernet cable we have no problems.
We are using a MPC8541, it has a PC16550D programming model for the
UART. I see that the driver uses the FIFO and reads until the FIFO is
empty.
The Ethernet driver is a tsec driver .
We encountered similar problems when writing to flash. We got some
verification/write errors with Ethernet traffic going. In that case we
masked the interrupts while writing to flash. But we don't want to do
that when receiving bytes on the serial port of course.

Has anybody else encounter such problems? Any hints in were to look? We
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christophe Coutand | 1 Sep 2009 11:35

RE: Zero vector interrupts (SIVEC=0) on MPC8xxx

Hi Danny,

Spurious or bad interrupts seem to be a known issue on 8260. what type
of CPU are you using?
http://lists.ozlabs.org/pipermail/linuxppc-dev/2004-January/016316.html
http://ozlabs.org/pipermail/linuxppc-embedded/2004-February/013247.html

Most of the HAL for PowerPC are written with the idea that external
interrupt number 0 is never valid, therefore 0 is allocated to the
decrementer interrupt. This is not true for PowerQuick III. For instance
on MPC8572 interrupt number 0 is related to L2 cache. I think the
easiest way for you is to map the decrementer interrupt
(CYGNUM_HAL_INTERRUPT_DECREMENTER) to something else then 0 and change
your variant.inc to handle it properly until you find the reason for the
spurious interrupts.

Christophe

-----Original Message-----
From: ecos-discuss-owner <at> ecos.sourceware.org
[mailto:ecos-discuss-owner <at> ecos.sourceware.org] On Behalf Of Danny Sade
Sent: Tuesday, September 01, 2009 10:21 AM
To: ecos-discuss <at> ecos.sourceware.org
Subject: [ECOS] Zero vector interrupts (SIVEC=0) on MPC8xxx

Hi All,
Did anyone encounter zero vector interrupt (SIVEC = 0) on the MPC8xxx ?
I recently encountered this kind of interrupts, and according to
Freescale support and the documentation this kind of interrupt may occur
during normal operation and a service routine for this interrupt must be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Lunn | 1 Sep 2009 11:50
Picon

Re: ARM7 ADC drivers - any progress?

> I'm slightly confused by a couple of things, perhaps someone who is
> familiar with the AT91 hal code might be able to clearup.

The HAL can get its tick from two different sources. Some devices, ag
the AT91SAM, have a PIT, programmable Interrupt Timer. All AT91 have
TC, Timer Counter. There is a CDL option to control which is used.

    Andrew

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 2 comments |
headers
Mandeep Sandhu | 1 Sep 2009 11:52
Picon
Gravatar

firmware update over the air

Hi All,

Apologies for this slightly off-topic question.

I'm writing my ECOS app which has network connectivity via a wifi link.
I would want to upgrade it over the air using this wireless link.

Are there any standard practices for doing the same?

In this case my storage (flash) requirement will be approx 2 times my app
size right?

Regards,
-mandeep

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 0 comments |

Gmane