STM32CubeMX ethernet on stm32f107

Posted on June 09, 2015 at 15:53

Please Help!

Is anyone from ST looking at this? It is very straightforward issue with an unmodified STM32CubeMX generated project.

I'm attaching the debug view. The address is correct 0x40029000 and it is the default value 0x20

I've also tried this in Atollic TrueSTUDIO with the same result. And I've added the MCO output of 25 MHz as this is needed, but that didn't change anything either (I've attach the new ioc file with MCO added).

The manual says of the SR bit ''When this bit is set, the MAC DMA controller resets all MAC Subsystem internal registers and logic. It is cleared automatically after the reset operation has completed in all of the core clock domains. Read a 0 value in this bit before re-programming any register of the core.'' Is it possible a clock domain is not setup correctly?

thanks,

Paul

________________

Attachments :

eth_simple.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzQo&d=%2Fa%2F0X0000000bLo%2F8nhlgIeSQqtP8ld_tMajKp7Ci8GdQERs625Vxxw_EaA&asPdf=false

mem_dmab_mr.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzJz&d=%2Fa%2F0X0000000bLn%2FbwGMUjPxMRNHkMJtSdZY6fnRXbrL91GlR4fUlTJkXuY&asPdf=false

Posted on June 09, 2015 at 17:11

Hello,

I had a look on stm32f1xx_hal_eth.c line 215, this line means that we wait that the bit  ETH_DMABMR_SR change to 0. According to RM0008 (page 1050), after a software reset this bit should be cleared automatically before re-programming any register of the core.

http://www.st.com/st-web-ui/static/active/en/resource/technical/document/reference_manual/CD00171190.pdf

So, this line does not mean that the bit ETH_DMABMR_SR take the reset value.

Posted on June 09, 2015 at 17:47

Yes, I understand! It is stuck in the while loop until that bit is 0, but why is that bit staying 1 when the manual says ''it is cleared automatically after the reset operation has completed'' and the hal_eth file is written to expect that? It never gets past that line when I debug the project.

thanks,

Paul

Posted on June 09, 2015 at 18:31

Is anyone from ST looking at this?

It's primarily a user participation forum, and I'm not a Cube/HAL advocate. Forum's are like echo chambers, there may or may not be others listening, or able to provide any assistance. I tend not to respond to any posts that are outside of my are of competence or interest.

In the SPL these kinds of ethernet issues revolve around the correct enablement, and sourcing of clocks. If your part expects the STM32 to generate a 25 MHz, then you're going to have to probe the board and confirm that is in fact getting out of the part, and any clock coming back in is also present. The enabling of the pins and clocks for this are going to have to occur prior to use, and I'm not sure how all this detail hiding used in Cube is going to impact getting this done in the appropriate sequence/order.

I think you're going to have to dig into the workings of the code, and confirm signals externally.

Posted on June 11, 2015 at 15:01

OK, so ST did help with this and the solution is pretty easy. First, counted in the ''core clock domains'' is the ETH_RMII_REF_CLK (PA1), so this must be correct before it will come out of reset. For this board it is provided by the MCO (attached is the STM32CubeMX project that includes this). Second, there is a small bug in STM32CubeMX if you are using PLL3CLK as the clock source for the MCO. To fix this, add the following line:

HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit)

in SystemClock_Config in main.c before calling:

PeriphClkInit.I2s2ClockSelection = RCC_I2S2CLKSOURCE_PLLI2S_VCO;

________________

Attachments :

eth_simple.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzQe&d=%2Fa%2F0X0000000bLk%2FImvRHrbXi2JKWi5Ulv9jEhR49SpXM7s8oFi__XLE_3A&asPdf=false

Posted on June 23, 2015 at 11:48

Hello Thomas,

The issue with PLL3 output on MCO will be fixed in coming CubeMX release.

Besides to the workaround you have provided, it is possible to replace this generated code:

  PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_I2S2;

  PeriphClkInit.PLLI2S.PLLI2SMUL = RCC_PLLI2S_MUL10;

  PeriphClkInit.PLLI2S.HSEPrediv2Value = RCC_HSE_PREDIV2_DIV5;

  HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit);

  

  By:

  

  __HAL_RCC_HSE_PREDIV2_CONFIG(RCC_HSE_PREDIV2_DIV5);

  __HAL_RCC_PLLI2S_CONFIG(RCC_PLLI2S_MUL10);

  __HAL_RCC_PLLI2S_ENABLE();

  

Regards

-Mayla-

Posted on January 19, 2016 at 13:20

Hi Paul,

so I am in nearly the same position as you were in that I am trying to get a basic UDP server up and running on the OLIMEX STM32-P107. However instead of using the STM32Cube MX to generate the underlying code I tried adapting the example for the STM3210C-Eval to the OLIMEX STM32-P107. The code compiles but I get stuck at the same point in stm32fxx_hal_eth.c namely:

 /* Wait for software reset */

  while (((heth->Instance)->DMABMR & ETH_DMABMR_SR) != (uint32_t)RESET)

  {

  }

I have read other posts that suggest:

the application has to set the MII/RMII mode while the Ethernet controller is under reset or before enabling the clocks.

 

But since i was using an ''official STM'' example, I thought that it would have been tested and such issues sorted out....

Can you or anyone else guide me what direction to look into...

Posted on January 19, 2016 at 17:47

But since i was using an ''official STM'' example, I thought that it would have been tested and such issues sorted out....

There have to be dozens of combinations of External PHY, MII/RMII, and clocking schemes, assume at best ST is going to test their own EVAL board implementations, and not everyone elses.

Cube provides ''Rough Framing'' you will still have to do the detail and finish work, and understand what the underlying software and hardware are doing.

Posted on January 19, 2016 at 18:35

Hi clive1,

Following is a snippet from the stmfxx_hal_eth.c file, function HAL_ETH_Init. 

 if(heth->State == HAL_ETH_STATE_RESET)

  {

    /* Allocate lock resource and initialize it */

    heth-> Lock = HAL_UNLOCKED;

    

    /* Init the low level hardware : GPIO, CLOCK, NVIC. */

    HAL_ETH_MspInit(heth);

  }

  

  /* Select MII or RMII Mode*/

  AFIO->MAPR &= ~(AFIO_MAPR_MII_RMII_SEL);

  AFIO->MAPR |= (uint32_t)heth->Init.MediaInterface;

  

  /* Ethernet Software reset */

  /* Set the SWR bit: resets all MAC subsystem internal registers and logic */

  /* After reset all the registers holds their respective reset values */

  (heth->Instance)->DMABMR |= ETH_DMABMR_SR;

  

  /* Wait for software reset */

  while (((heth->Instance)->DMABMR & ETH_DMABMR_SR) != (uint32_t)RESET)

  {

  }

Selection of MII/RMI as can be seen is done after HAL_ETH_MspInit(heth); function has been called, does the application has to set the MII/RMII mode while the Ethernet controller is under reset or before enabling the clocks. Does this mean that:

/* Select MII or RMII Mode*/

  AFIO->MAPR &= ~(AFIO_MAPR_MII_RMII_SEL);

  AFIO->MAPR |= (uint32_t)heth->Init.MediaInterface;

must be called before  HAL_ETH_MspInit(heth) is called ? this was in a driver file that's why i was relectunt to change anything there.

Posted on February 27, 2016 at 11:42

Thomas,

I once had the same problem, it turns out my problem was the other circuit settings were incorrect, so the PHY was not working properly. After fix that problem, PHY reset wait loop had no problems.

Hope it helps.

Regards,