Olimex LPC2378-STK - Another Ethernet problem

[gwiezdnik]

Hi All!

I have run uTasker on my Olimex board, but uTasker does not work correctly. I have read previous problems, but this advices not help me.

This is behaviour of my board:

* After power on led blinking, and ethernet led's also power on

* After TCP/IP request to board (via web browser from another computer) led stop blinking, and after few seconds (maybe 5 seconds) ethernet led's goes to power off

* After maybe one second later ethernet led's again goes power on, and led start blinking

* Web browser show Network timeout message

Could You help me?

I write elf file via ARM-USB-OCD and OpenOCD program (by command flash write_image erase uTaskerV1.3.elf elf

I hope someone maybe help me...

Greetings,
Damian

PS. Sorry for my english :/

[mark]

Hi Damian

It sounds as though the board is resetting when a communication attempt is made. However it is not possible to know what the problem is that causes this without studying some more details.

Could you try the following?

1) Download the reference for your Olimex board form here: http://www.utasker.com/SW_Demos.html
and see whether it behaves the same or not. This may help identify whether it is a HW problem, a build problem or a loading problem.

2) If you monitor the activity with Wireshark are there any Ethernet frames being set by your board?

3) Can you ping the board? Does it also crash when you try this or only when you try to browse?

4) Can you say which compiler you are using?

5) If it turns out to be a problem with the generated file you can send a hex file (for loading with FLASH MAGIC) so that it can be tried on our reference board.

Regards

Mark

[gwiezdnik]

1) Download the reference for your Olimex board form here: http://www.utasker.com/SW_Demos.html
and see whether it behaves the same or not. This may help identify whether it is a HW problem, a build problem or a loading problem.

This works great.

2) If you monitor the activity with Wireshark are there any Ethernet frames being set by your board?

Yes. System sends packets in both cases. Look at this:

BAD HEX FILE (COMPILED MANUALLY):

Code: [Select]

> flash write_image erase C:/pp/Applications/uTaskerV1.3/GNU_LPC23XX/uTaskerV1.3.hex
auto erase enabled
Padding image section 0 with 2 bytes
wrote 53611 byte from file C:/pp/Applications/uTaskerV1.3/GNU_LPC23XX/uTaskerV1.3.hex in 6.234375s (8.397713 kb/s)

Wireshark:

1 0.000000 AsustekC_85:15:cc Broadcast ARP Who has 192.168.0.3?  Tell 192.168.0.2
2 5.390692 AsustekC_85:15:cc Broadcast ARP Who has 192.168.0.3?  Tell 192.168.0.2
3 10.890624 AsustekC_85:15:cc Broadcast ARP Who has 192.168.0.3?  Tell 192.168.0.2
4 16.390571 AsustekC_85:15:cc Broadcast ARP Who has 192.168.0.3?  Tell 192.168.0.2

CORRECT HEX FILE (DOWNLOADED):

Code: [Select]

> flash write_image erase c:/uTaskerV1.3_Olimex_LPC2378-STK.hex
auto erase enabled
Padding image section 0 with 4 bytes
Padding image section 1 with 8 bytes
Padding image section 2 with 2 bytes
wrote 50348 byte from file c:/uTaskerV1.3_Olimex_LPC2378-STK.hex in 6.062500s (8.110180 kb/s)

Wireshark:

21 110.929719 AsustekC_85:15:cc Broadcast ARP Who has 192.168.0.3?  Tell 192.168.0.2
22 110.929852 00:00:00_00:00:00 AsustekC_85:15:cc ARP 192.168.0.3 is at 00:00:00:00:00:00
23 110.929858 192.168.0.2 192.168.0.3 ICMP Echo (ping) request
24 110.930086 192.168.0.3 192.168.0.2 ICMP Echo (ping) reply
25 111.930131 192.168.0.2 192.168.0.3 ICMP Echo (ping) request
26 111.930330 192.168.0.3 192.168.0.2 ICMP Echo (ping) reply


3) Can you ping the board? Does it also crash when you try this or only when you try to browse?

Board crash on any TCP/IP request - ping and http also.

4) Can you say which compiler you are using?

Here You are:

Code: [Select]

C:\pp\Applications\uTaskerV1.3\GNU_LPC23XX>cs-make --version
GNU Make (Sourcery G++ Lite 2009q1-161) 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i686-pc-mingw32

My make command:

Code: [Select]

C:\pp\Applications\uTaskerV1.3\GNU_LPC23XX>cs-make -f make_uTaskerV1.3_GNU_LPC23XX


5) If it turns out to be a problem with the generated file you can send a hex file (for loading with FLASH MAGIC) so that it can be tried on our reference board.

It look's like that I have problem with compiler - HEX files sizes also are different (50348B, 53611B).

This is what I have done:

* Download uTaskerV1.3_beta-LPC.zip

* Download uTaskerV1.3_beta-LPC_3.zip

* Unpack uTaskerV1.3_beta-LPC.zip

* Unpack uTaskerV1.3_beta-LPC_3.zip

* Copy SP files to main files with overwrite option

* Select Olimex board in config.h

* Disable LCD SUPPORT in config.h

Should I do something else...?

But if original bin file works fine, there are a hope to run this sources on my board...

Greetings,
Damian

[gwiezdnik]

Hi...

Now, I compile sources with Yagarto, and effect is the same Do You have any idea...?

Greetings,
Damian

[mark]

Hi Damian

I have tried your code on my Olimex board and it behaves as you say. The board works until an Ethernet frame is received and then it crashes - I can see that it is due to an exception but I can't say anything else about it just yet.

However I note that you are using the latest version of CodeSourcery (2009q1) and the uTasker project was released based on tests with the 2008q1, which I am still using for all work. I just recompiled the project (using 2008q1) and tested again without any problems so I conclude that there is a problem when compiled with the 2009q1.

I suggest that you first use the 2008q1, which is still available for download on the CodeSourcers web site. I assume that it will then work correctly.

In the meantime I will download the 2009q1 version and see whether I can get it running with the project. Once I have identified what the problem is with the new GCC version I will report back, hopefully with a fix too.

Regards

Mark

[mark]

Hi

I have now installed the CodeSourcery 2009q1 and rebuilt the project with it.
I can confirm that Ethernet receptions cause the board to crash. The next step is to debug this...

Regards

Mark

[mark]

Hi Damian

I have managed to identify a problem when using the 2009q1 GCC version as follows:

        return (unsigned char)EMAC_RxConsumeIndex;                       // buffer index received from

This was causing an exception (abort), presumably because the EMAC_RxConsumeIndex register can only be accessed as a long word.
Breaking down the line I get this:

        return (unsigned char)(*(unsigned long*)(ETHERNET_CONTROLLER_BLOCK + 0x118));
which means that the value will be read from the register as an unsigned long and then reduced to an unsigned char (8 bit) for the return.

The assembler code was however not doing this, but rather accessing directly an unsigned char, which was causing an abort error.

I found that this could be stopped by declaring the register differently as:

#define EMAC_RxConsumeIndex              *(volatile unsigned long*)(ETHERNET_CONTROLLER_BLOCK + 0x118)

Please try this change and tell me whether it solves your problem.

Regards

Mark

[gwiezdnik]

Hi!!!

Your message is very helpful - I have replace definition of EMAC_RxConsumeIndex and now uTasker works fine!!!

Thanks a lot!

Damian

[mark]

Hi Damian

That is good news.

Good luck.

Regards

Mark