This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: STM32F4 Discovery + LwIP

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
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]