Hello, I am trying to get the web server demo up and running on a SAM7X-EK development board.  I am using  IAR Workbench v4.30A connecting to the board with the IAR J-Link JTAG debugger.  I have encountered many of the issues that most people have had on this forum concerning this board and demo.  The current issue I am working out involves the program getting stuck in a test loop that toggles the LEDs.  Can anyone help me out?  I am not sure why I am getting stuck in this loop.  Thank you. Below is the loop that I am currently stuck in, it is contained within ParTest.c void vParTestToggleLED( unsigned portBASE_TYPE uxLED ) {     if( uxLED < ( portBASE_TYPE ) NB_LED )     {         if( AT91F_PIO_GetInput( AT91C_BASE_PIOB ) & ulLED_MASK[ uxLED ] )         {             AT91F_PIO_ClearOutput( AT91C_BASE_PIOB, ulLED_MASK[ uxLED ]);         }         else         {             AT91F_PIO_SetOutput( AT91C_BASE_PIOB, ulLED_MASK[ uxLED ] );                            }     } }

?Can’t see a loop in the code you have posted. The demo worked out of the box for me.  Have you modified the code at all?  If not then check you have the correct interface set in the code.  The code will use either MII or RMII interface depending no a #define and the choice must match your hardware. Also obviously you have to set the IP address to be correct for your network :-) I think these was an issue some time back regarding the macro files for the J-LINK?  Is this what you refer to?

I spoke wrong, the code simply gets stuck in either the first or the second if statement, depending on when I stop my program from running.  There is no loop.  The only changes that I have made to my code are in setting the IP address, which I have changed to 192.168.100.100.  My device, which is the demo board, is operating in RMII mode.  The only thing I am thinking at this point is that it is the board itself or the IAR J-Link.  The board I have received was an early version of the development board that I received from a supplier.  The identifying numbers on it are ZE-03  94 V-0  3105.  They are located below the RS232 Com Port.  Please let me know what version you are using, and if you believe that this could cause my problem.  I am going to go back to the original version of the demo software and start over again in order to eliminate the possibility that I have changed something else.  Thank you. Javier

Hi Javier, I also had one of the original boards.  ZE-03 94 V-0 2305…maybe even older than yours if the last number means anything. Anyway – there is a timing issue with using the early boards if using RMII mode.  The latest FreeRTOS version defaults to using MII mode as Atmel changed the hardware for production units.  Some hardware mods are required to the original boards to use MII mode.  This hardware issue will not cause the problem you are having however so can be ignored for now. Are you using the latest V3.2.4 FreeRTOS code?  If so then you need to change the default back to RMII mode. Another thing V3.2.4 did was change very slightly the init sequence for the EMAC to allow it more time to auto initialise.  I think this change is only required when using MII mode (?), and again will not cause the problem you are having. I’m a little unsure what you mean by ‘gets stuck’.  Are you saying that the step instruction stops working in the debugger?  Or that there is an exception at that point and you jump to a data abort or invalid instruction exception?  A little more detail would be good. If you power down the board, power it back up again, then download the code and run it in the debugger so it is the first execution after power up – does the problem still happen?  If the first run works but subsequent runs do not then there is likely to be a macro initialisation issue.  Does it run when you are not using the debugger but just programming it into flash?  This could be a sign of the same thing. The code really should run exactly as downloaded with just the IP address, MAC address and gateway addresses set.  I know several people who have used it successfully.  One person did report problems when powering the board through a USB hub. Regards.

Richard, Thank you very much for your very helpful comments.   The code that I was using was version 3.2.1, I downloaded this particular version from the Web Server example page.  I have downloaded the latest version now, it seems to be acting the same.  Is there any good documentation concerning the FreeRTOS on the web?  I would like to read up a little more on how this OS works compared to others. Another question that I have concerns my version of IAR Workbench.  I am using IAR Embedded Workbench Kickstart for ARM 4.30A.  I assume this version will work considering it is what IAR distributes currently on their webpage.  The only changes that I have made to code are: IP: 192.168.100.100 Router IP: 192.168.100.1 fixedethadr: 1 MAC address: 00:01:02:03:04:05 USE_RMII_Interface: 1 I am having trouble following my code due to the fact that I cannot successfully single step through the program.  When doing this it acts very erratic and never actually reaches ‘main’.  But somehow, when I simply run the program in debug it runs until it encounters the statement that I have showed you above.  I cannot see any reason as to why the program hits this point to begin with.  There are no exceptions that the program jumps to; it simply shows when I stop the program that it is on one of these current steps.  What were the issues you spoke of when using RMII mode?  I wonder if somehow these issues are causing at least part of my problem.  Finally, if you have actually seen this program up and running, are there any signs that it works (ie LEDs flashing) that indicates that it is working besides being able to view the webpage?  Thank you very much for all of your help. Javier

I have stepped through the code, and I beleive the problem is caused in the Cstartup.s79 file.  When the code is supposed to branch to main (memory location 0x1AEC) it instead branches to a line within SAM7_EMAC.c (0x0A3C).  This line then executes the code from this point, but never reaches main.  I have noticed that this Cstartup file is different than the ones provided in the examples from Atmel.  I was wondering if these files should ever even be changed, considering the fact that the startup file from Atmel works fine.  Any input would be appreciated. Javier

To use FreeRTOS the startup file has to configure the stacks for IRQ and supervisor modes, and then switch to supervisor mode prior to calling main() (the kernel can only be started from supervisor mode – after that the mode is handled by the kernel).  Also the interrupt handling has to be as per the demo.  Therefore the startup file is required to be different. If in the debugger you are seeing a branch to one address but you are actually branching to a different address then I can only think it is a linking problem or that the code being compiled is somehow different to that being shown in the debugger. Does this happen on the first download following the board being reset? Regards.

Where are you downloading the code from?  The port page on the main site (http://www.freertos.org/portsam7xiar.html) describes how the LED’s flash when the demo is running.  There is also a lot of documentation describing how it works (an example for the AVR rather than ARM). Regards.

Will the Kickstart version of IAR Workbench 4.30A compile and run code the size of the FreeRTOS?

Absolutely – no problem.  The uIP WEB server demo will compile using the KickStart.