Problem with LwIP_TCP_Echo_Server on Nucleo-H7S3L8 Eval Board

[JimEno]

Firstly, the installation process is pretty ugly and the documentation is very sparse.

From the README.md file:

This application runs from the external Flash memory (LwIP_TCP_Echo_Server Appli).

It boots from internal Flash (Template_XIP_Boot) then jumps to the application code in external Flash.

To configure STM32CubeIDE Debug Configuration, you must do the following :

 

1. Upload the template XIP

2. Add the adequate external loader (MX25UW25645G_STM32H7S3L8-NUCLEO.stldr file) in Project->Debugger Configuration

3. Add in the startup the template_XIP_Boot in Project->Debugger Configuration

4. Move up the application in the startup

 

Step 1, real helpful, what an ordeal.

Step 2, could not find MX25UW25645G_STM32H7S3L8-NUCLEO.stldr used MX25UW25645G_NUCLEO-H7S3L8.stldr instead

Environment:

STMCubeIDE V1.19.0

STMCubeMX V6.15

STMProgrammer V2.20.0

ST-Link F/W V3J16M9

 

My problem:

When I run the code in debugger mode, execution never gets out of Template_XIP_Boot.

Ends up in error handler.

void Error_Handler(void)

{

/* USER CODE BEGIN Error_Handler_Debug */

/* User can add his own implementation to report the HAL error return state */

__disable_irq();

while(1)

{

}

/* USER CODE END Error_Handler_Debug */

}

Call stack:

HAL_XSPI_Command returns with status=HAL_BUSY

I'm sure I'm missing something but can't afford weeks to find it. Any help or insight would be appreciated.

[Mahmoud Ben Romdhane]

Hello @JimEno ,

 

Let me thank you for posting.

For more investigation, I suggest please that you provide the Debugger and the Startup configuration.

 

Thanks.

Mahmoud

 

[JimEno]

 

Recommended info added. Tried to follow README.md file as best as I could.

 

 

 

 

 

 

 

 

[JimEno]

Additional observations:

I added a hack 'while' delay. Code snippet below.

File: stm32h7rsxx_hal_xspi   Function: HAL_XSPI_Command    Line: 875

...

/* Wait till busy flag is reset */

status = XSPI_WaitFlagStateUntilTimeout(hxspi, HAL_XSPI_FLAG_BUSY, RESET, tickstart, Timeout);

uint32_t i = 0x00050000;

while(i--);

 

if (status == HAL_OK)

...

 

This seemed to 'fix' the problem. Code did not end up in Error_Handler.

Please continue with real fault cause and fix.

New problem surfaced:

The Application code was all 0xFFFFFFFF and jump from Boot to Application crashed (of course).

I will open a new forum post on this.

[Mahmoud Ben Romdhane]

Hello @JimEno ,

 

It is mentioned on the Readme file to enable high-speed option byte with STM32CubeProgrammer Tool.

XSPI2_HSLV=1

 

Thanks.

Mahmoud

 

 

[JimEno]

I was using the IDE to build and program the sample project. I assumed the IDE or MX would handle any settings or options. I did not assume I HAD to use the Programmer to set any options. I will try this and report back.

Thanks for your response Mahmoud.

[JimEno]

Mahmoud,

I enabled that option byte as you suggested. It worked.

- User Option Bytes requirement (with STM32CubeProgrammer tool)

- XSPI2_HSLV=1 I/O XSPIM_P2 High speed option enabled

 

It seems like setting this option could have been done in the sample project

firmware. I shouldn't need the Programmer. Am I wrong?

I will consider this issue resolved. Thanks for your response.

[Mahmoud Ben Romdhane]

Hello @JimEno 

 

Further to your comment, the XSPI2_HSLV can be done by user code as described in RM0477 section 5.4.3 Option byte words modification / Changing option byte words. VDDIO_HSLV option bit is also required with XSPI2_HSLV.

The flash driver provides the following HAL API that can be used. 

 

/**
 * @brief Program Option bytes.
 * @param pOBInit pointer to an FLASH_OBInitStruct structure that
 * contains the configuration information for the programming.
 *
 * @note To configure any option bytes, the option lock bit OPTLOCK must be
 * cleared with the call of HAL_FLASH_OB_Unlock() function.
 * @note New option bytes configuration will be taken into account in two cases:
 * - after an option bytes launch through the call of HAL_FLASH_OB_Launch()
 * - after a power reset (BOR reset or exit from Standby/Shutdown modes)
 *
 * @retval HAL Status
 */
HAL_StatusTypeDef HAL_FLASHEx_OBProgram(const FLASH_OBProgramInitTypeDef *pOBInit)

 

• Note 1: This API will reset the device at the end to ensure the programming of the Option byte. To avoid a recall to the API after reset, you may need to test that the value of the option bit is not set before calling this API
• Note2: Using CubeMx you need to insert this in the code for modifying HSLV option bit into the boot project, before any configuration of XSPI2. 

 

Thanks.

Mahmoud