[ECOS] Re: STM32F4 Discovery + LwIP
Valentin BOUSSON
ml-ecos@belphegor.eu
Fri Apr 11 15:00:00 GMT 2014
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 <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
More information about the Ecos-discuss
mailing list