From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19069 invoked by alias); 11 Apr 2014 15:00:15 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 19045 invoked by uid 89); 11 Apr 2014 15:00:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mo4.mail-out.ovh.net Received: from 6.mo4.mail-out.ovh.net (HELO mo4.mail-out.ovh.net) (188.165.36.253) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Apr 2014 15:00:11 +0000 Received: from mail194.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with SMTP id 71B80FFB4E4 for ; Fri, 11 Apr 2014 17:00:08 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 11 Apr 2014 17:00:07 +0200 Received: from unknown (HELO ?10.68.150.24?) (valentin@bousson.com@193.57.249.1) by ns0.ovh.net with SMTP; 11 Apr 2014 16:59:59 +0200 Message-ID: <5348036E.2030901@belphegor.eu> Date: Fri, 11 Apr 2014 15:00:00 -0000 From: Valentin BOUSSON User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jerzy Dyrda , ecos-discuss@ecos.sourceware.org References: <53313DCE.8030104@belphegor.eu> <53315497.4040903@dallaway.org.uk> <53319FED.7040802@dallaway.org.uk> <53466671.3050304@bousson.com> <53469AA0.60808@belphegor.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 247416505833156720 X-Ovh-Remote: 193.57.249.1 () X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejuddrieekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeejuddrieekucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-IsSubscribed: yes Subject: [ECOS] Re: STM32F4 Discovery + LwIP X-SW-Source: 2014-04/txt/msg00008.txt.bz2 Hello, I'm desperate to see that it seems I have done all like you, and nothing even went out my Ethernet port.. First, For the sequential input,**I noticed a*bug*. When I compile my project with the sequential mode, the simple.c for the simple mode implementation seems to be also linked, that induces some symbols conflicts. I didn't succeed to disable this linking error, but wrapping the simple.c code by an ugly #if 0 + #endif, errors disappear. Then, I had some errors to flash my memory, when my ecos configuration included also the io_flash package. I'm not sure that the bug comes from a real conflict, but I write it down here. I will test better later. If I'm right, this plugin is for building some flash filesystem, but is useless for my lwip issue. Finally, I tried all the combination possible to parametrize either ethernet driver / or LwIP stack, and nothing yet. Did you published somewhere your project, or could you show me the ecos configuration you used ? Unfortunatly, I debug blindly, I can only use gdb with step by step execution, and all seems ok, but How do you do, guys, to debug with your HW? On STM32F4, I see many output with USART and serial line, but I have for now no cable for that, and I don't know how to output eCos debug outputs. Thanks again. Valentin BOUSSON On 10/04/2014 15:30, Jerzy Dyrda wrote: > Hello Valentin, > >> I thought than once the program start, with nothing more than an empty main and the init phase of eCos, >> I would have all the necessary threads running for ARP or ping response (at least). > Yes, you are right. It's needed to call stack initialization procedure > like that in case of sequential mode : > cyg_lwip_sequential_init(); > > Best regards, > jerzy > > 2014-04-10 15:20 GMT+02:00 Valentin BOUSSON : >> Thanks for your help, but I have already tried this configuration, >> then my problem may come from the way I use lwip stack. >> >> I thought than once the program start, with nothing more than an empty main >> and the init phase of eCos, I would have all the necessary threads running >> for ARP or ping response (at least). >> >> If you confirm me this behaviour, that's I'm missing something in my eCos >> config. Did you add anything in the initialisation phase ? >> >> thanks. >> >> Valentin BOUSSON >> >> >> >> >> On 10/04/2014 13:53, Jerzy Dyrda wrote: >>> Hello Valentin, >>> >>> >>> On Thursday 10 of April 2014 11:37:53 you wrote: >>> >>> >>>> I took into account all the modifications you make me do onto my ecos >>>> build, and so I did : >>>> - in my ecos.db, I added : >>>> / >>>> / >>>> /target stm32f4discovery-bbext {/ >>>> / alias { "STMicroelectronics STM32F4-Discovery board with >>>> DM-STF4BB extension board" }/ >>>> / packages {/ >>>> / CYGPKG_HAL_CORTEXM/ >>>> / CYGPKG_HAL_CORTEXM_STM32/ >>>> / CYGPKG_HAL_CORTEXM_STM32_STM32F4DISCOVERY/ >>>> / CYGPKG_IO_FLASH/ >>>> / CYGPKG_DEVS_FLASH_STM32/ >>>> / CYGPKG_IO_SERIAL_CORTEXM_STM32/ >>>> / CYGPKG_IO_ETH_DRIVERS/ >>>> / CYGPKG_DEVS_ETH_PHY/ >>>> / CYGPKG_DEVS_ETH_CORTEXM_STM32/ >>>> / }/ >>>> / description "The stm32f4discovery--bbext target provides the >>>> packages needed/ >>>> / to run eCos on the STMicroelectronics STM32F4-Discovery board >>>> with the DM-STF4BB (STM32F4DIS-EXT)."/ >>>> /} >>>> / >>> Genau. >>> >>> >>>> / >>>> /- in my current folder, I was able to generate a configuration with >>>> this template, and I added the package concerning LWIP. My configuration >>>> is linked to the mail. >>>> >>>> - I addedin >>>> packages/hal/cortexm/stm32/stm32f4discovery/current/include/plf_io.h the >>>> pins configurationJerzy gave me, and the custom driver. >>> Genau. >>> >>> >>>> If I understand >>>> well, The type of PHY interface is MII, and we have to check the "MII >>>> pins remapped". >>> Nope. PHY interface type is RMII. So it has to be set RMII interface >>> in ecc file: >>> >>> >>> # Type of interface used to connect with PHY : MII or RMII >>> # >>> cdl_option CYGSEM_DEVS_ETH_CORTEXM_STM32_INTF { >>> # Flavor: data >>> user_value RMII >>> >>> # value_source user >>> # Default value: RMII >>> # Legal values: "MII" "RMII" >>> }; >>> >>> but please use graphical eCos Configuration Tool to fix it. >>> >>>> - Concerning the system initialization : >>>> "" >>>> John said : >>>> >>>> You might also be necessary to modify the the hal_system_init() function >>>> in the STM32F4-Discovery platform HAL to setup the ethernet hardware. >>>> Compare with the hal_system_init() function from the STM32x0G platform >>>> HAL. >>>> >>>> "" >>>> Concerning this modification, I must admit I'm very new to such embedded >>>> platform/systems (as you may have already noticed ;) ), and I don't >>>> understand how I am supposed to adapt it. All those pin configuration, >>>> clocks linking, etc.. are really obscure to me (for now). >>>> Jerzy, how did you do ? >>>> The only bunch of code that seems to be useful is concerning the PHY >>>> should look like : >>>> >>>> #if defined(CYGHWR_HAL_CORTEXM_STM32_PHY_CLOCK_MCO) >>>> // Use HSE clock as the MCO1 clock signals for PHY >>>> { >>>> cyg_uint32 acr; >>>> >>>> HAL_READ_UINT32(base + CYGHWR_HAL_STM32_RCC_CFGR, acr); >>>> acr |= CYGHWR_HAL_STM32_RCC_CFGR_MCO1_HSE | >>>> CYGHWR_HAL_STM32_RCC_CFGR_MCO1PRE_1; >>>> HAL_WRITE_UINT32(base + CYGHWR_HAL_STM32_RCC_CFGR, acr); >>>> } >>>> #endif >>>> >>>> , right ? (I'm no Idea what I'm doing here :/) >>> No, you don't need it. Clock for PHY is provided by on-board oscillator. >>> >>>> - I am trying to compile a simple program that use it, polling on tcp >>>> connection, and I observe nothing. I observe no frame at all on the >>>> wireshark interface plugged to the stm32. Do you have some advice to >>>> test the low-level protocol, instead of the whole ip stack at once ? >>> I use the same stuff i.e Wiresharke + ping ;) >>> >>> >>> Best regards, >>> jerzy >>> >>> 2014-04-10 11:37 GMT+02:00 Valentin BOUSSON : >>>> Hello John & Jerzy, >>>> >>>> I took into account all the modifications you make me do onto my ecos >>>> build, >>>> and so I did : >>>> - in my ecos.db, I added : >>>> / >>>> / >>>> /target stm32f4discovery-bbext {/ >>>> / alias { "STMicroelectronics STM32F4-Discovery board with >>>> DM-STF4BB >>>> extension board" }/ >>>> / packages {/ >>>> / CYGPKG_HAL_CORTEXM/ >>>> / CYGPKG_HAL_CORTEXM_STM32/ >>>> / CYGPKG_HAL_CORTEXM_STM32_STM32F4DISCOVERY/ >>>> / CYGPKG_IO_FLASH/ >>>> / CYGPKG_DEVS_FLASH_STM32/ >>>> / CYGPKG_IO_SERIAL_CORTEXM_STM32/ >>>> / CYGPKG_IO_ETH_DRIVERS/ >>>> / CYGPKG_DEVS_ETH_PHY/ >>>> / CYGPKG_DEVS_ETH_CORTEXM_STM32/ >>>> / }/ >>>> / description "The stm32f4discovery--bbext target provides the >>>> packages needed/ >>>> / to run eCos on the STMicroelectronics STM32F4-Discovery board >>>> with >>>> the DM-STF4BB (STM32F4DIS-EXT)."/ >>>> /} >>>> / >>>> >>>> >>>> / >>>> /- in my current folder, I was able to generate a configuration with this >>>> template, and I added the package concerning LWIP. My configuration is >>>> linked to the mail. >>>> >>>> >>>> - I addedin >>>> packages/hal/cortexm/stm32/stm32f4discovery/current/include/plf_io.h the >>>> pins configurationJerzy gave me, and the custom driver. If I understand >>>> well, The type of PHY interface is MII, and we have to check the "MII >>>> pins >>>> remapped". >>>> >>>> >>>> >>>> >>>> - Concerning the system initialization : >>>> "" >>>> John said : >>>> >>>> >>>> You might also be necessary to modify the the hal_system_init() function >>>> in the STM32F4-Discovery platform HAL to setup the ethernet hardware. >>>> Compare with the hal_system_init() function from the STM32x0G platform >>>> HAL. >>>> >>>> "" >>>> Concerning this modification, I must admit I'm very new to such embedded >>>> platform/systems (as you may have already noticed ;) ), and I don't >>>> understand how I am supposed to adapt it. All those pin configuration, >>>> clocks linking, etc.. are really obscure to me (for now). >>>> Jerzy, how did you do ? >>>> The only bunch of code that seems to be useful is concerning the PHY >>>> should >>>> look like : >>>> >>>> #if defined(CYGHWR_HAL_CORTEXM_STM32_PHY_CLOCK_MCO) >>>> // Use HSE clock as the MCO1 clock signals for PHY >>>> { >>>> cyg_uint32 acr; >>>> >>>> HAL_READ_UINT32(base + CYGHWR_HAL_STM32_RCC_CFGR, acr); >>>> acr |= CYGHWR_HAL_STM32_RCC_CFGR_MCO1_HSE | >>>> CYGHWR_HAL_STM32_RCC_CFGR_MCO1PRE_1; >>>> HAL_WRITE_UINT32(base + CYGHWR_HAL_STM32_RCC_CFGR, acr); >>>> } >>>> #endif >>>> >>>> , right ? (I'm no Idea what I'm doing here :/) >>>> >>>> >>>> - I am trying to compile a simple program that use it, polling on tcp >>>> connection, and I observe nothing. I observe no frame at all on the >>>> wireshark interface plugged to the stm32. Do you have some advice to test >>>> the low-level protocol, instead of the whole ip stack at once ? >>>> >>>> >>>> >>>> Thank you, >>>> Valentin >>>> >>>> >>>> >>>> >>>> On 25/03/2014 16:25, John Dallaway wrote: >>>>> Hi Jerzy and Valentin >>>>> >>>>> On 25/03/14 12:34, Jerzy Dyrda wrote: >>>>> >>>>>> ... I have already brought up network interface on >>>>>> >>>>>> STM32F4DISCOVERY + DM-STF4BB (AFAIK this is original name of base >>>>>> board from Embest, now as I see it's called STM32F4DIS-BB). >>>>> Great! Maybe we can work together to get ethernet support for this >>>>> platform added to the eCos repository. I think it would be preferable to >>>>> define a new target such as "stm32f4discovery_bb" in ecos.db which >>>>> includes the STM32 ethernet package. We can then make the necessary >>>>> changes within the platform HAL source code conditional on >>>>> CYGPKG_DEVS_ETH_CORTEXM_STM32. We need to bear in mind that some users >>>>> of the STM32F4-Discovery board may wish to wire up a different PHY >>>>> component rather than using STM32F4DIS-BB. >>>>> >>>>> John Dallaway >>>>> eCos maintainer >>>>> http://www.dallaway.org.uk/john >>>>> -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss