LwIP with SBSFU

[Arno1]

Hello,

I'm trying to get LwIP working on a STM32F769I-DISC1 board but with the SBSFU bootloader.

I started out with a basic project, generated with CubeMx, that sends UDP packets every 500ms (no operating system, just LwIP Raw API). This works, the board gets an IP address and I receive the data.

I then changed the linker script and project settings to work with the X-Cube-SBSFU bootloader which builds and starts up but will not get an IP address. It just keeps waiting for an address.

The changes I made to run with the bootloader are as follows:

• Changed STM32F769NIHx_FLASH.ld as attached (STM32F769NIHx_FLASH_bootloaded.ld)
• added includes to gcc settings in AC6 Systems Workbench
  • Middlewares/ST/STM32_Secure_Engine/Core
  • 2_Images_lwip/2_Images_SECoreBin/Inc
  • 2_Images_lwip/2_Images_SBSFU/SBSFU/App
  • 2_Images_lwip/Linker_Common/SW4STM32
• changed linker to gcc -z max-page-size=8
• add to linker libraries (-l) :se_interface_app.o
• add to Library search path (-L) the path where se_interface_app.o can be found
• add to other options (-Xlinker) -L ../../Linker_Common/SW4STM32
• And finally to the post build steps I added postbuild.sh

Then, in main.c I change SCB->VTOR to INTVECT_START and include mapping_export.h

I also needed to add an implementation for SysTick_Handler() because CubeMx didn't generate one.

Does anyone know why the ethernet interface that works, won't work when using the bootloader?

If you need more information, please let me know.

Thanks in advance.

Best regards,

Arno

[Jocelyn RICARD]

Hello Arno,

well I don't see anything missing from your description, so difficult to say what's wrong.

Only way to progress is to go for debugging your application to try to find where things go wrong.

For this you first need to deactivate the protections in SBSFU .

Best regards

Jocelyn

[Arno1]

Hi,

From what I've been able to find so far is that in stm32f7xx_hal_eth.c in HAL_ETH_GetReceivedFrame()

the heth->RxDesc->Status ETH_DMARXDESC_OWN bit is always set. Thus it never gets into the

if(((heth->RxDesc->Status & ETH_DMARXDESC_OWN) == (uint32_t)RESET)) section.

The value of heth->RxDesc->Status is always 0x8000 0000.

I've attached a set of relevant files. The two *.cap files are text files from the minicom output and show the difference in output between a working version (works2.cap) and non working version (works_not2.cap) with bootloaded.

The bootloader is the same as provided in the X-Cube-SBSFU package apart from the banner text. All protections are disabled and I enabled debugging for LwIP (see lwipopts.h).

The relevant printfs can be found in stm32f7xx_hal_eth.c.

I would be most thankful if you or anyone could have a look to see what goes wrong.

Thank you and regards,

Arno

[Arno1]

my answer here should have been a reply to your message instead.

[Jocelyn RICARD]

Hello Arno,

I suspect issue comes from :

#if !defined(BOOTLOADED)

 /* USER CODE END Init */

 /* Configure the system clock */

 SystemClock_Config();

 /* USER CODE BEGIN SysInit */

#endif

The SBSFU is doing a basing clocking which is probably not the one you need in your application.

Best regards

Jocelyn

[Arno1]

That didn't make any difference.

My best guess is there may be a DMA issue here.

In HAL_ETH_TransmitFrame(...) there are the following lines:

  /* When Tx Buffer unavailable flag is set: clear it and resume transmission */
  if (((heth->Instance)->DMASR & ETH_DMASR_TBUS) != (uint32_t)RESET)
  {
    /* Clear TBUS ETHERNET DMA flag */
    (heth->Instance)->DMASR = ETH_DMASR_TBUS;
    /* Resume DMA transmission*/
    (heth->Instance)->DMATPDR = 0;
  }

As stated previously, heth->RxDesc->Status remains 0x8000 0000, meaning the own bit remains active while it should at some point deactivate.

By stepping through the code I found heth->RxDesc->Status only changes value after line 7 in the code snippet above (to 0x015a 0321).

So for some reason when running the code with SBSFU, heth->RxDesc->Status doesn't change its value (verified using printfs before and after that line).

[Arno1]

I also tried building the ethernet connection into the 2_Images_UserApp project as delivered in the STM32CubeExpansion_SBSFU_V2.2.0 package but there

is an error in the drivers that are included here.

The 2_Images_UserApp uses the same drivers as the SBSFU and SeCoreBin projects use but for the STM32F769I-DISC1 there is an error in the configuration (stm32f7xx_hal_conf.h) where there is the following macro:

#define DP83848_PHY_ADDRESS             0x01U

However, the STM32F769I-DISC1 doesn't support the DP83848 chip as far as I can tell. The DP83848 requires an MII connection but only RMII is available for the LAN8742A chip.

[Jocelyn RICARD]

Hello Arno,

I checked this point, this is related to some inconsistency in the provided stm32f7xx_hal_conf.h file in STM32F769I-Discovery examples.

Some havethe LAN8742 and some the DP83848.

I guess this is related to copy paste of examples on other F7 family. As most of the examples don't use this value this was not noticed.

I will report this issue.

Best regards

Jocelyn

[Arno1]

Hi @Jocelyn RICARD​ ,

So far all I can find is that the Ethernet DMA does not seem to be able to access data. I checked whether the buffer addresses are correctly assigned to the DMA so it knows where to write its data

• Buffer1Addr: 0x20026730, Buffer2NextDescAddr: 0x20024864, DmaTxDesc: 0x2007fed4 with bootloader
• Buffer1Addr: 0x20005730, Buffer2NextDescAddr: 0x20003864, DmaTxDesc: 0x2007fe54 Without bootloader

The offset with bootloader means it still falls within the SRAM region but after the part reserved for the secure engine.

The DMASR register which is 0x00680084 with bootloader and 0x00660444 without bootloader. The main thing I can deduce from this data is that the TBUS and RBUS remain unavailable when there is a bootloader. I checked if ETHMAC_CLK, ETHMACTX_CLK and ETHMACRX_CLK are on and they are.

Do you have any idea where else I can look to see what goes wrong?

Thank you.

Regards,

Arno

[Jocelyn RICARD · Accepted solution]

Hello Arno,

I asked to one of my colleague for hints :)

The issue could be related to the SRAM you are using.

In working case, without bootloader, you are using DTCM RAM that is not cacheable.

In non working case, with bootloader, you are using SRAM which is cacheable.

So, could you please check if this is working when disabling cache ?

If this is the case, you should setup MPU to disable cache only on DMA buffers.

Best regards

Jocelyn