Ethernet/UDP problem

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?

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.

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.

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.

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...

>>>> 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.

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.