Last updated August 24, 2010
The Idea
The amount of memory available today for embedded applications is fast
increasing. This brings the firmware complexity (code size)
to grow up. Many powerful and open source tools are available today to address this challenge.
The idea is to setup an open
Development Environment for
complex both STR91x and STM32F107xx (connectivity line) based embedded application. It must be powerful enough
to simplify and speed up the application developing and testing.
Main Components
The Demo
This demo is only a port of the
STR91x Ethernet demo on Eclipse. It shows how to setup a bidirectional communication channel between the MCU and a PC over a TCP/IP connection. It uses
lwIP version 1.3.2. Please refer to the
instructions provided in the
Eclipse demo (STM32) to install and configure Eclipse, and note that the project is ready to be used with Eclipse Helios.
I developed the first demo version some years ago (2006) on a STR912 based board. On June 2009 STMicroelectronics
announced the new STM32 connectivity line. This new STM32 MCU family bring the power of ARM Cortex M3 core with the Ethernet connectivity. Why not reuse all the work done on STR912? Thanks to the multitasking nature of the project, the goal was simple to achieve, because I changed only one of the network related file!
The project contains two eclipse workspace as shown in the following picture...
Fig. 1
... one for the STR9 project - ARM9_STR91X_Eclipse - and the other for the STM32 project - CORTEX_STM32F107_Eclipse. This directory organization reflect the standard
FreerRTOS source code organization. Inside the two workspace folders the network related files are the same. I simply copied all files (highlighted in Fig.2) from the old STR912 workspace to the new STM32 workspace.
Fig. 2
The Ethernet peripheral driver is the only changed file. It implements the link between the Ethernet peripheral and lwIP stack and is located in a sub-folder of the lwIP component as shown in Fig. 3.
More information about how to run the demo and the demo features are located in the next section and in the
STR91x Ethernet demo web page.
More details...
This section tries to provide a more detailed explanation of the demo architecture and files.
The network task
The following pages, coming from the
Ethernet Demo (STR91x) provide a more detailed explanation of the network related tasks architecture and source files.
Some notes about the Makefile
At the end of the file a special target, named
log, is defined.
This target saves in two files information about the sizes of the sections inside the RTOSDemo.bin file (RTOSDemoSymbolTable.txt), and the total amount amount of FLASH and RAM used (RTOSDemoMemoryListing.txt). To invoke it you can open the Make targets view from the Show View sub-menu of the Window menu, and than double-click on the log target.
Fig.1 - The make size target command
The Make_fsdata tools
One of demo tasks is a simple web server that serves pages stored in the read-only file system implemented in the fs.c and fsdata.c files. I use the Make_fsdata windows application to generate the fsdata.c file, as discussed in this
post. Eclipse make more simple to use this tools:
- Choose the Make_fsdata command from the External Tools button of the toolbar as displayed in the below picture.
- Use the tool as usual to generate the fsdata.c file.
- Look at the output console. It displays some status information about the last tool execution.
The source code organization
Find other information about the directory structure of the demo in this
web page.
Choose the lwIP version
This demo uses the official lwIP version 1.3, but I have included in the package the last sources (the CVS HEAD) of the TCP/IP stack available when writing these notes. To build the demo using a different version of lwIP look the Makefile for the LWIP_DIR and LWIP_PORT_DIR defines. They are located at the beginning of the Makefile. Change them to refer to the wanted version as showed in the following box.
Makefile
#LWIP_DIR=../../Common/ethernet/lwIP/v1_3_0/src
#LWIP_PORT_DIR=../../Common/ethernet/lwIP/v1_3_0/contrib/port
LWIP_DIR=../../Common/ethernet/lwIP/HEAD/src
LWIP_PORT_DIR=../../Common/ethernet/lwIP/HEAD/contrib/port
STR912 specific info
This
web page provide information specific to the STR912 demo project.
STM32F107 specific info
This
web page provide information specific to the STM32F107 demo project.
The Managed Build System (MBS) Plug-in
Starting from version v1.5.0 (for STM32) the
workspace contains two projects. The second project, RTOSDemo_mbs, is open by default whereas the original Makefile project RTOSDemo is now closed.
The RTOSDemo_mbs project has not a Makefile, but you can build it with the Build command. This is because this project uses the managed build system
of the Eclipse framework. This means that the Makefile is automatically
generated and managed by the IDE for all project files. This is a great
features if you don't like to manually edit a Makefile! I configured
this workspace so that the source files are the same for both projects,
so it is possible to use the preferred project type, the Standard
Makefile project (RTOSDemo) or the Managed project (RTOSDemo_mbs). To use
the last one you have to install the GNU ARM Eclipse Plug-in, a great open source project! :-) Simply follow The recommended way in the plug-in installation instruction web page.
Remember
to modify the OpenOCD configuration file
stm32_program_eclipse_jtag.cfg, located in the workspace folder, in
order to tell to OpenOCD the location of the binary image to flash.
#flash write_image ./RTOSDemo/RTOSDemo.bin 0x08000000 bin
flash write_image ./RTOSDemo_mbs/Debug/RTOSDemo_mbs.elf 0x08000000 elf
Uncomment one of the two script command showed above according to the active project. Download
Starting from July 2010 I'm using Dropbox as hosting service.
You find the old versions packaged in one monolithic zip file at the bottom of this web page. The latest version of the demo file is located in the
Download page of the site. To build the demo are needed teh following components:
- The FreeRTOS source files: Source.zip
- The files shared by all demos: Common.zip
- The demo specific files:
- ARM9_STR91X_Eclipse.zip for STR912 MCU, or
- CORTEX_STM32F107_Eclipse.zip for STM32 MCU.
Please look at the
Download web page for more details.
Latest news
-
Uploaded new demo version
Uploaded demo version 1.5.0 (STM32)What's news:- STM32 + Fixed bug #B3.7 + Added support for Managed Build system (MBS)
Posted Aug 24, 2010, 3:32 AM by Stefano Oliveri
-
#B3.7 - STM32 - Bad initialization of the main stack.
New bug report. The problem is in the startup file (startup_stm32f10x_cl.c). For more information please see the Known Issues section of the main demo page.Status:the ...
Posted Aug 24, 2010, 2:44 AM by Stefano Oliveri
-
Uploaded new demo version
Uploaded demo version 1.4.2 (STM32) and 1.3.3 (STR912).What's news:- STM32 + ST Standard Peripheral Library v3.2.0 (CMSIS 1.3.0 compliant).- STR912 + Updated ...
Posted Mar 26, 2010, 11:49 AM by Stefano Oliveri
-
#B3.6 - STM32 - Frame lost or duplicate frame problem under certain circumstance.
New bug report. The problem is in the Ethernet driver (stm32x_ethernetif.c). For more information please see the Known Issues section of the main demo page.Status:the problem ...
Posted Mar 10, 2010, 11:58 PM by Stefano Oliveri
-
#B3.5 - STM32 - Unmanaged error condition in Ethernet driver may generate bus fault
With high Ethernet load an unmanaged error condition in Ethernet driver may generate bus fault. For more information please refer to Known Issue section of the main demo page.Thanks ...
Posted Mar 10, 2010, 11:57 PM by Stefano Oliveri
Known issues
STR91x - The systems hung mixing tasks compiled in THUMB and ARM mode. (#B3.1)
The system hung if the following conditions occurs:
- You define the macro USE_THUMB_MODE = YES in the Makefile in order to mix ARM and THUMB code.
- You define two tasks, Tansk1 and Task2, and the Task1 control function is compiled in ARM mode and the Task2 control function is compiled in THUMB mode. For example if you define the two task control functions in different files, and compile one file in THUMB mode and the other file in ARM mode.
The bug has been introduced in the
port.c file, during the stack initialization performed by the function
pxPortInitialiseStack. The below box displays a fragment of the source code and the wrong code line is
red-highlighted.
The box show that the THUMB bit in the initial SPSR task register is set even if the task control function is compiled in ARM mode.
The problem is fixed in the demo source v1.2.1. For more information see the
Latest news section.
The Network Calculator is unable to connect to the board. (#B3.2)
Everything is working fine, except the calculator. After press the
On button the following error message is displayed: "Error: unable to connect the board."
The problem is fixed in the demo source v1.2.2. For more information see the
Latest news section.
STM32 - Duplicate outgoing Ethernet frames. (#B3.3)
The board send each frame twice. The problem is present in the
Common Demo Files component version xxx and previous.
The problem is in the STM32 Ethernet driver (<FREERTOS_ROOT>\Demo\Common\ethernet\lwIP\v1_3_2\src\netif\stm32x_ethernetif.c file). It is due to a bad initialization value in Tx DMA descriptor in the
vSendMACData function. The below box displays a fragment of the source code and the wrong code line is
red-highlighted.
#B3.3 - stm32x_ethernetif.c
The problem is fixed in demo version v1.4.1.
STM32 - Bad Ethernet driver initialization make board work in promiscuous mode. (#B3.4)
The Ethernet receive logic is set to ReceiveAll packets and drop Broadcast packets. The MAC address is not configured. More deeply, the MAC driver is configured in the
xEthInitialise function in the
Common/ethernet/lwIP/v1_3_1/src/netif/stm32x_ethernetif.c. That function calls
ETH_MACAddressConfig which sets up the station's MAC address correctly. However just a bit below that is a call to
ETH_SoftwareReset which wipes out the MAC address, undoing the previous call. The board seem to work properly only because the program then puts the receiver logic into ETH_ReceiveAll_Enable and ETH_BroadcastFramesReception_Disable because otherwise packets wouldn't be received correctly. The below box display the xEthInitialise function that fix the problem.
#B3.4 - stm32x_ethernetif.c
in demo version v1.4.1.
Thanks David for signaling the problem, and more thanks for giving me the solution! ;-)
STM32 - Unmanaged error condition in Ethernet driver may generate bus fault. (#B3.5)
The function
prvGetNextBuffer in the file
Common/ethernet/lwIP/v1_3_2/src/netif/stm32x_ethernetif.c tries to allocate an empty buffer for 30 times (as defined by the netifBUFFER_WAIT_ATTEMPTS macro
). If it is not able to allocate the buffer the function returns NULL to signal the problem. This function is used by the two function vSendMACData and usGetMACRxData for sending and receiving a frame. But neither functions checks the return value and the next time they attempt to access the NULL buffer a bus fault occurs. This happen with high Ethernet load. #B3.5 - stm32_ethernrtif.c
The problem is fixed in the component Common v1.3.2.
Thanks Stefan for signaling the problem, and more thanks, as usual, for guiding me towards the solution! ;-)
STM32 - Frame lost or duplicate frame problem under certain circumstance. (#B3.6)
The problem is in the use of the
s_lwip_buf by both the receive and transmit code in the Ethernet driver (stm32x_ethernetif.c file). If an incoming packet arrives just after an outgoing packet
was sent, the pointers get messed up which can result in the
received packet getting sent out again and / or loss of a buffer.
The problem is fixed
in the component Common v1.3.2.
Thanks again David for signaling the problem, and more thanks for giving me
the solution! ;-)
STM32 - Bad initialization of the main stack. (#B3.7)
The stack is located in the bss segment so in function
Reset_Handler of startup_stm32f10x_cl.c the stack is first initialed to 0x5A5A in the first for loop, but then re-initialized to 0:
void Reset_Handler(void)
{
register unsigned long *pulSrc, *pulDest;
SystemInit();
// Fill the stack with a known value.
for(pulDest = pulStack; pulDest < pulStack + STACK_SIZE; )
{
*pulDest++ = 0xA5A5;
}
// Copy the data segment initializers from flash to SRAM.
pulSrc = &_flash_data;
for(pulDest = &_data; pulDest < &_edata; )
{
*(pulDest++) = *(pulSrc++);
}
// Zero fill the bss segment.
// Error: Overwrite the stack initialization.
for(pulDest = &_bss; pulDest < &_ebss; )
{
*(pulDest++) = 0;
}
// Call the application's entry point.
main();
}
The problem is fixed
in the component Common v1.3.4 by postponing the stack initialization just before the call to main function.
For more information look at
this post in the forum. In the same post is proposed another solution by changing the SRAM layout in the linker script. I added the files
startup_stm32f10x_cl_v2.c and
stm32_flash_v2.ld that implement this solution. By default the old startup file and linker script are used.
Thanks again
jfgr88 for signaling the problem, and more thanks for giving me
the solution! ;-)
Questions, Suggestions, Bugs, and...
Every feedback is welcome. If you have a suggestion to improve a demo or the web pages, it's ok. If you found a bug in a demo, please let me know. If you have an idea to improve a demo, I'm pleasure to discuss about it. If you have any questions about a demo, I hope to have the answer!
If you want leave a feedback, please use this
web page.
Users wishing to obtain support could also use the
Open Forum.
All
the code is developed for test purpose and it is unsupported. The
author assumes no responsibility for any damage caused by improper uses.
