EmbDev.net

Forum: ARM programming with GCC/GNU tools Ethernet/UDP problem


Author: Starter (Guest)
Posted on:

Rate this post
0 useful
not useful
I wish to establish an UDP connection between PC and ARM in cost of
minimal resources.
I have read manual and FreeRTOS demo. Manual has no example - demo is
"all-in-one": is has much more knowledge and much too difficult.

I need a VERY simple UDP connection: send and receive single packets
from/to the given computer in C++. I have read that ARM has built-in
error correction method (CRC). Thanks for any help.

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Starter wrote:
> I wish to establish an UDP connection between PC and ARM in cost of
> minimal resources.

Which ARM?

> I have read manual and FreeRTOS demo. Manual has no example - demo is
> "all-in-one": is has much more knowledge and much too difficult.

Which one of the FreeRTOS examples?

> I need a VERY simple UDP connection: send and receive single packets
> from/to the given computer in C++. I have read that ARM has built-in
> error correction method (CRC). Thanks for any help.

Maybe some devices offer support for CRC "in hardware" but it depends on
the integrated functions of the controller in use.

Author: Starter (Guest)
Posted on:

Rate this post
0 useful
not useful
Martin Thomas wrote:
> Starter wrote:
>> I wish to establish an UDP connection between PC and ARM in cost of
>> minimal resources.
>
> Which ARM?
AT91SAM7S256

> Which one of the FreeRTOS examples?
FreeRTOS_4_0_0_armgcc

I have develop some programs based on this - but may hardly check it
because of limitations (no step mode, no variable check, etc.)

>> I need a VERY simple UDP connection: send and receive single packets
>> from/to the given computer in C++. I have read that ARM has built-in
> Maybe some devices offer support for CRC "in hardware" but it depends on
> the integrated functions of the controller in use.
First I need transport a packet. Error detection is the next.
Which program may use at PC for test?

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
Maybe I don't get you question right. The AT91SAM7S does not offer any
hardware-support for ethernet. If you need some kind of network
connection addional hardware is also needed.

The network examples from FreeRTOS demonstrate usage of external
ethernet-controllers (i.e. "Wiznet"-modules) or are for devices with
internal ethernet-functions (i.e. AT91SAM7X). Additional software is
needed on the controller for both approaches and depend on the functions
already available in the hardware. In the FreeRTOS examples for
"network" I have seen are based on Adam Dunkel's uIP or lwIP and are
extended with interface-functions to communicate with the "MAC". I have
never used "bare" UDP but TCP/IP so I can not realy help with UDP only.

"FreeRTOS_4_0_0_armgcc" is not an official FreeRTOS distirbution. Maybe
you mean the "stripped" version in the WinARM example-directory. The
latest full version and additional examples are available from
www.freertos.org .

If you'd like to stay with the AT91SAM7S you could connect the
stand-alone ethernet controller from Microchip (ENC*). Should be rather
easy to connect and use and example-applications are available at least
for other controller families.

Examples for AT91SAM7X are already available from freertos.org. While
the AT91SAM7X offeres integrated Ethernet-Functions an additional IC
("PHY") is still needed to connect to the media.

> First I need transport a packet. Error detection is the next.
> Which program may use at PC for test?
I have used netcat for some tests with "TCP/IP over GPRS". Etherreal
might be helpful too.

Author: Jonathan Dumaresq (dumarjo)
Posted on:

Rate this post
0 useful
not useful
Martin Thomas wrote:
>
>
> The network examples from FreeRTOS demonstrate usage of external
> ethernet-controllers (i.e. "Wiznet"-modules) or are for devices with
> internal ethernet-functions (i.e. AT91SAM7X). Additional software is
> needed on the controller for both approaches and depend on the functions
> already available in the hardware. In the FreeRTOS examples for
> "network" I have seen are based on Adam Dunkel's uIP or lwIP and are
> extended with interface-functions to communicate with the "MAC". I have
> never used "bare" UDP but TCP/IP so I can not realy help with UDP only.
>
>

I have done it with a sam7x from the freertos sample. I have used the
UDP and the TCP at the same time without problem.

Jonathan

Author: Starter (Guest)
Posted on:

Rate this post
0 useful
not useful
Jonathan Dumaresq wrote:

> I have done it with a sam7x from the freertos sample. I have used the
> UDP and the TCP at the same time without problem.

I have got a solution for this problem but it uses polling technique.
I have tried turn it to use interrupt but got some problems:

I think ARM EMAC (Ethernet) need acknowledge every interrupt by reading
a register at start of interrupt handler:
  i = AT91C_BASE_AIC->AIC_IVR;

and show the end of current interrupt by writing a register:
  AT91C_BASE_AIC->AIC_EOICR = 0;

This is the part of pre-programming interrupt:
    AT91C_BASE_AIC->AIC_SMR[AT91C_ID_EMAC_B] = AT91C_AIC_PRIOR_HIGHEST |
    AT91C_AIC_SRCTYPE_POSITIVE_EDGE;
//     AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL ;
//    AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE;
I don't know which trigger method to use? I figured method "level" is
not good because of permanent call of interrupt (failed handshake, I
think).
Other methods causes interrupt never run.

Author: Jonathan Dumaresq (dumarjo)
Posted on:

Rate this post
0 useful
not useful
Starter wrote:
> Jonathan Dumaresq wrote:
>
>> I have done it with a sam7x from the freertos sample. I have used the
>> UDP and the TCP at the same time without problem.
>
> I have got a solution for this problem but it uses polling technique.
> I have tried turn it to use interrupt but got some problems:
>
> I think ARM EMAC (Ethernet) need acknowledge every interrupt by reading
> a register at start of interrupt handler:
>   i = AT91C_BASE_AIC->AIC_IVR;
>
> and show the end of current interrupt by writing a register:
>   AT91C_BASE_AIC->AIC_EOICR = 0;
>
> This is the part of pre-programming interrupt:
>     AT91C_BASE_AIC->AIC_SMR[AT91C_ID_EMAC_B] = AT91C_AIC_PRIOR_HIGHEST |
>     AT91C_AIC_SRCTYPE_POSITIVE_EDGE;
> //     AT91C_AIC_SRCTYPE_INT_HIGH_LEVEL ;
> //    AT91C_AIC_SRCTYPE_INT_POSITIVE_EDGE;
> I don't know which trigger method to use? I figured method "level" is
> not good because of permanent call of interrupt (failed handshake, I
> think).
> Other methods causes interrupt never run.

I don't remember if i use it in interrupt or polling. But the transfer
from the MAC to Software is done by DMA.

Jonathan

Author: Xx Yy (Guest)
Posted on:

Rate this post
0 useful
not useful
Jonathan Dumaresq wrote:
> Starter wrote:
>> Jonathan Dumaresq wrote:
>>
>>> I have done it with a sam7x from the freertos sample. I have used the
>>> UDP and the TCP at the same time without problem.

I have got a solution for this problem but it has some minor problems.
In some cases works correctly.
Other cases (exactly same program!) runs but refuses connection.
Sometimes it depends on translation (side effects - eg. a new dummy
variable exists or not) and program shows true effect only after HW
reset (i.e: without reset it works like previous version).
So: wrong version is wrong, right version is right after HW reset -
all 2 versions work like previous reseted version if it loaded with SW
reset.

The all difference is the behaviour of MII_BMCR: 2100h and un-writable
on false case and works correctly on normal case.

Author: Toth Jozsef (joke)
Posted on:

Rate this post
0 useful
not useful
Xx Yy wrote:
> Jonathan Dumaresq wrote:
>> Starter wrote:
>>> Jonathan Dumaresq wrote:
>>>
>>>> I have done it with a sam7x from the freertos sample. I have used the
>>>> UDP and the TCP at the same time without problem.
>
> I have got a solution for this problem but it has some minor problems.
> In some cases works correctly.
> Other cases (exactly same program!) runs but refuses connection.
> Sometimes it depends on translation (side effects - eg. a new dummy
> variable exists or not) and program shows true effect only after HW
> reset (i.e: without reset it works like previous version).
> So: wrong version is wrong, right version is right after HW reset -
> all 2 versions work like previous reseted version if it loaded with SW
> reset.
>
> The all difference is the behaviour of MII_BMCR: 2100h and un-writable
> on false case and works correctly on normal case.


All your routines are correct? What kind of your physical frontend used?

regards

Author: Xx Yy (Guest)
Posted on:

Rate this post
0 useful
not useful
First Second wrote:

>> The all difference is the behaviour of MII_BMCR: 2100h and un-writable
>> on false case and works correctly on normal case.
>
>
> All your routines are correct? What kind of your physical frontend used?

If I use (or not) some dummy variables or change length of a string,
program behaviour changes. It is sure variable addressing problem - but
how? And how to find it? Very few variables are in this situation...
mostly constants.
Not stack problem: program runs correctly. Some functions (for PHY setup
and connect) called during this process: all work and return correctly -
only reg above refuses write and work.

Author: Xx Yy (Guest)
Posted on:

Rate this post
0 useful
not useful
Xx Yy wrote:
> First Second wrote:
>
>>> The all difference is the behaviour of MII_BMCR: 2100h and un-writable
>>> on false case and works correctly on normal case.
>>
>>
>> All your routines are correct? What kind of your physical frontend used?
>
> If I use (or not) some dummy variables or change length of a string,
> program behaviour changes. It is sure variable addressing problem - but
I located this constant in "lst" file:

WRONG version:
.ascii  ",\011P: \000"
 2057 0300 2C09503A
 2057      2000
 2058 0306 0000         .align  2
 2059                .LC46:

GOOD version:
.ascii  ",\011: \000"
 2057 0300 2C093A20
 2057      00
 2058 0305 000000       .align  2
 2059                .LC46:

All differece is letter "P" - but this is aligned so other parts of
program are exactly the same. Final executable file like this.
This part of program is at flash area so I don't think overwrite
error...

Author: Xx Yy (Guest)
Posted on:

Rate this post
0 useful
not useful
>>>> The all difference is the behaviour of MII_BMCR: 2100h and un-writable
>>>> on false case and works correctly on normal case.
I have found a possible reason for this behaviour:
maybe fiber (optical) mode. At this mode these pins are R/O.
I checked pin 24 and 44 which determine this settings at startup: they
are correct and NOT fiber settings. Trying SW reset PHY chip - but it
seems read these pins only at HW reset.

Author: Xx Yy (Guest)
Posted on:

Rate this post
0 useful
not useful
Xx Yy wrote:
>>>>> The all difference is the behaviour of MII_BMCR: 2100h and un-writable
>>>>> on false case and works correctly on normal case.
> maybe fiber (optical) mode. At this mode these pins are R/O.
I have solved this problem: it IS fiber optical mode. It MUST use a weak
pull-down resistor to use Ethernet settings. PHY chip reads pin setings
ONLY at HW reset.
Also maybe SW solution: SW pull-down this pin at start and process
later.

Ethernet traffic is perfect now at 10Mb/s!

Next problem: SAME system is faulty at 100MB/s. All difference is speed
settings. Cable is capable this speed. In best case card receives
messages correctly and CAN NOT answer. Error message at sending is "Used
Bit Read".
SAME answer sent correctly at 10Mb/s. There is one sending buffer and
interrupt handles this: clear after send immadiately.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.