Using Open Source Tools with SAM7X and uTasker project

[Tino]

Hi Mark,
Thanks für the quick reply.

I copied the new files and had to adapt the makefile to the GNU compiler.

Also there seems to be an error in webInterface.c line 210:
HTTP_session->ptrFileStart = (unsigned char*)cSuccessSW_HTML;
HTTP_session->FileLength = sizeof(cSuccessSW_HTML)-1;

cSuccessSW_HTML is undefined.
I tried to resolve it, but finally I just skip the lines.

After that it compiled smoothly. But the outcome it the same. The display backlight flashes at 2 Hertz and no network communication. Though the network LEDs at the PHY are blinking sometimes.



The VS project won't compile anymore. This is the error I get:

Error   1   error LNK2019: unresolved external symbol "void __cdecl fnDoPortSim(int)" (?fnDoPortSim@@YAXH@Z) referenced in function _WinMain@16   WinSimMain.obj   


Maybe just a little thing, but that takes the most time to find

Thanks for your effort!
Tino

[mark]

Hi Tino


cSuccessSW_HTML is defined at the start of webInterface.c, but it is dependent on having a file system declared larger than 160k.
        #if FILE_SYSTEM_SIZE >= (160*1024)                               // support posting new firmware only with large file system
            static const CHAR cWarningHTML[]       = UPLOAD_FAILED;
            static const CHAR cSuccessSW_HTML[]    = SW_UPLOAD_COMPLETED;
        #endif

UPLOAD_FAILED is the defined in app_hw_sam7x.h.

I suggest removing the check of file system size. I will look into this again because I have the feeling some compilers don't get the same value of >= (160*1024)  at both locations - possibly header ordering dependent. I didn't have this problem with my tests but I had a similar occurance in another project...

fnDoPortSim() is in a new file called PortSim.cpp in \WinSim.
The simulator directory contains a project set up with this - if you are using your own simulator project you will need to manually add the new file to the project. Right click on the WinWim folder in VS and then add the file.


As for the fact that the network LED is still blinking but the communication not working, this seems to not be due to the GNU packing anymore - I tested the project with three different GNU versions without any problems.
I think that you will need to debug this. It may be due to a network configuration problem (although the simulator seemed to work well - I assume using the same network settings). Have you deleted the complete FLASH to ensure that no (unexpected) parameters are being taken from the parameter block?
I would see whether the Ethernet frames are really arriving at the Ethernet task. If the arrive there you can see where they are rejected - in ARP or IP (also check the data on the network using Ethereal/WireShark. This may give some indicators.
The PHY may be working but the interface between PHY and CPU not be absolutely correct. This may take a bit more work. However I have had confirmation that the PHY configuration/interface is correct for the Olimex board when the project is compiled with OLIMEX_EX256 in config.h.

I will be away for a day so hope that you make some progress in the meantime. Good luck!!

Regards

Mark

[Tino]

Hi,
I deleted the entire flash and tried it again - same result.

In the meantime I could get rid of the blinking by changing the values in app_hw_sam7x.h.
I watched the IP packets in wireshark and I could see the ping tool requesting the mac for the ip, but no one replied. So something isn't running well.

I cannot believe, no one has running µTasker on an Olimex Board?
I don't have the time to go into the deep of µTasker to figure out the problem. I'll have to try another approach.

Thanks for your help and I really hope this can work someday.

[mark]

Hi Tino

I am sorry that you haven't had success on the Olimex board. I believe the project does run on it since several users have confirmed.

Have you tried the example download code at:
http://www.utasker.com/software/software.html ?

This is generated by the IAR compiler but if it runs on your board it will at least conform that the HW is OK, which would means that it may be an issue with the GNU project for this target.

Regards

Mark

PS. I just visited the Olimex web site and checked the SAM7X board. It seems that there is a revision B board now available and the first circuit diagrams are obsolete.
Can you see whether you perhaps have a rev.- B board?
I couldn't make out the changes between the first and the B-rev circuits and I didn't see any differences in the PHY connection. But may be there is some change which needs to be respected in the SW (?)
Check also that the PHY is not being held in power down mode via PHY_PD jumper.

[Tino]

I downloaded the demo bin and uploaded it to the olimex board.
The display is blinking again. I assume that the ip address of the demo file is 192.168.0.3?
I tried to reach it - no answer.

I have the olimex rev b.
I tried another solution with the exact identical network settings (ip, mask, gateway) and it worked. So the hardware is OK!

[mark]

Hi Tino

Yes, the IP in the demo defaults to 192.168.0.3.

The blinking backlight indicates that the code is running but the fact that it doesn't respond to network activity suggests that something is not set up correctly for the board (this can only really be in the area of the PHY since the rest is internal). Since you have other SW oprating correctly it can not be due to a HW error. Since you have successfully communicated with the simulator using the same default set up it can also not be a network configuration issue.

My educated guess is that there is a subtle change around the PHY - possibly its physical address is different - or the Micrel PHY has a new revision number (although this shouldn't theoretically change anything). When the MII interface is configured, the PHY identifier is read. It is checked with the expected PHY identifier (with the revision bits masked out) and if the check doesn't match the Ethernet controller set up is aborted. This can easily be checked with a debugger since the Ethernet configuration routien in SAM7x.c will return early.

I will order an Olimex board so that I can look into this - I will check that I really get a Rev.B. board (rather than one from old stock) and then I hope to be able to sort it out. Unfortunately it will take a while to receive the board.

If any one else has this board (Rev. B to be sure) and knows how to verify the Ethernet initialisation (by the way, stepping through this in the simulator shows how it should work as a reference) then it would be interesting if they could step through the code to see whether I am correct - and possibly offer a solution...!

Sorry to disappoint for the moment.

Regrads

Mark

[Tino]

Hi,
I commented the following line:
if ((ulPhyIdentifier & PHY_MASK) != PHY_IDENTIFIER) return;

- no change.

[mark]

Hi Tino

Could you see what value was being read?

I ordered the Olimex board today. However it seems that it won't actually arrive until the end of the month. As soon as I have a solution I will post it here.

Regards

Mark

[Tino]

Good news!!!

I was playing around more and finally it works.
Actually I cannot tell what did the trick... But I have to comment the PHY check, else it doesn't work.
The next step is getting the debugger to work. Then I can tell you which value was read.

Thank you for putting so much effort in it!

I think when you offer a complete solution with an Eclipse project and debugger support ready-to-go for standard evaluation boards, even more people will try out your great software because they don't have to get their minds too much into it before they can see results. Like me

Have a great day and I'll keep you updated about my project.

[mark]

Hi Tino

That is good new.

I think that a combination of Olimex and GNU is good for a lot of people and I have in fact ordered a few extra Olimex boards as well so that these can be better integrated.

This year, there will certainly be more emphasis on the ARM devices - for example the NXP LPC family supports a very broad range of applications starting with the LPC2101 with 2k RAM and 8k FLASH at a price of not much more than $1 up to the LPC2478 with Ethernet, USB host/device/OTG 96k RAM and 512k FLASH. They are all fast ARM 7 devices with peripheral compatibility which allows an LPC2378 or LPC2368 (etc.) user to simply make a smaller embedded project based on the cheap and quite tiny devices with almost zero effort: just remove the define for Ethernet and USB (which are not available) and the code will effectively work on the other device (as long as it is not too large for the memory of course). Since all tools remain the same, there is nothing new to be learned and the the same JTAG debugging power is available if needed. Even the little ones run at up to 60MHz and run 32 bit code.

Previously one would probably have dropped down to a cheap 8-bit processor to realise a small extension function - and have to use different tools, set up new projects, compromise development confort etc. but nowadays this can hardly be justified since the HW price saving is usually negligable (and in some cases the 8 bit HW may be even more expensive!).

As well as new device support, there are also new features on the way. This, coupled with an increasing history of successful and reliable projects with the uTasker, makes for an exciting 2008!

Regards

Mark

Note: the NXP example is not the only one. Also take a look at what Luminary Micro is doing with the new Cortex M3 processors...

[mark]

Hi Tino

I have received an Olimex SAM7-EX256 board and can confirm the same problem that you had. The reason is that the PHY is not responding to the PHY address 0x1f - instead it requires the PHY address 0x01.

I have made a change which ensures that the PHY is initialised with the correct address - this I have detailed in the following new post:

http://www.utasker.com/forum/index.php?topic=161.0

In addition I have updated demo software for the SAM7X on the web site to include latest features - one for the ATMEL and one for the OLIMEX board (http://www.utasker.com/software/software.html).

Regards

Mark

[coflynn]

Also - a note about using the SAM-ICE device from Atmel if you have one.

It's true that to support 'flash programming' you need to buy a license from Segger for a lot of $$. However what I just do is this, which if you already have a SAM-ICE might be useful:

I have the "GDB-Server" program and "SAM-PROG v2.4" running at the same time. A debug cycle is:

* Recompile binary

* On SAM-PROG have binary file selected using 'browse'. You only have to do this the first time you open the program
* On SAM-PROG have 'Auto' checkbox
* Hit 'Yes' button, and wait until it finishes

* Start debugging in Eclipse, which will connect you to the GDB-Server
* Find bug - recompile.
* Hit 'stop' to disconnect from GDB-Server

* Hit 'yes' buttong on SAM-PROG
* etc...

I haven't had any problems with both programs running at the same time. You get into trouble if you try to access the JTAG with two programs at once - aka while in the middle of programming accidentally hit anything in the debugger that causes it to send a command to GDB-Server.

If you have a SAM-ICE hope this helps!

  -Colin