[ECOS] Re: STM32F4 Discovery + LwIP

[Valentin BOUSSON <ml-ecos@belphegor.eu>]

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 <valentin@bousson.com>:
>> 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