Threads dont work again after NVIC_SystemReset

[ismail fatih iltar]

Posted on June 05, 2018 at 13:35

Hi, My system is stm32f746 + lwip + ethernet(phy=lan8742A).

and i have 3 threads in my program. 1 for gpio control(blinky led etc.), 1 for httpd webserver and 1 for catching udp packages.

sys_thread_new('HTTPD', httpd_server_thread, NULL, 128, osPriorityRealtime)

sys_thread_new('DATASERVER', data_server_thread, NULL, 1024, osPriorityRealtime );

sys_thread_new('GPIOCONTROL', gpio_control_thread, NULL, 128, osPriorityIdle );

The system works well on STM32F7 Disco board. On my pcb When i powered up, it works well too. But when i call

NVIC_SystemReset

after reset just gpio thread works. ethernet threads blocked (same program isnt locked after reset at disco board). If I reenergized my pcb, it starts to work again. I know the explanation is too generic but i need any idea about it. Because it's ridiculous error. and i have not logical idea about the reason.

#lwip #threads #webserver #freertos+tcp #ethernet-stm32f7

[David Littell]

Posted on June 05, 2018 at 15:00

Just a wild guess that the first two threads are blocked waiting on something that's not being initialized properly (or maybe just completely).  Possibly something near the Ethernet PHY?

[ismail fatih iltar]

Posted on June 08, 2018 at 16:30

I guess problem is in

void ethernetif_input( void const * argument )

{ struct pbuf *p; struct netif *netif = (struct netif *) argument; for( ;; ) { if (osSemaphoreWait( s_xSemaphore, TIME_WAITING_FOR_INPUT)==osOK) { do { p = low_level_input( netif ); if (p != NULL) { if (netif->input( p, netif) != ERR_OK ) { pbuf_free(p); } } } while(p!=NULL); } }}

Because it has 

if (osSemaphoreWait( s_xSemaphore, TIME_WAITING_FOR_INPUT)==osOK)

line and it waits the semaphore release. Semaphore releases in 

void HAL_ETH_RxCpltCallback(ETH_HandleTypeDef *heth)

{ osSemaphoreRelease(s_xSemaphore);}

but theese lines are never called. So this thread blocks. But i couldnt understand why this doesnt happen in discovery board. My schematics are same with disco board.

[David Littell]

Posted on June 08, 2018 at 18:01

What happens on your board if you call NVIC_SystemReset(), see that it's hung, and then unplug/replug Ethernet a short time later?

[T J]

Posted on June 11, 2018 at 08:12

Surely with a systemReset, everything should be disabled.

Nothing should work. IMHO

can you trap the issue in the systemReset code ?

you can set a flag to reflect the current state of the Semaphore, and within the systemReset code, you could satisfy the issue.

[ismail fatih iltar]

Posted on June 11, 2018 at 07:12

Nothing to change. It never comes back again. continues to hanging status and waiting to release semaphore(myguess)

[ismail fatih iltar]

Posted on June 11, 2018 at 11:16

Everything seems like normal and right.

HAL_Eth Start return OK which is in low_level_init()

/* create the task that handles the ETH_MAC */

osThreadDef(EthIf, ethernetif_input, osPriorityRealtime, 0, INTERFACE_THREAD_STACK_SIZE); osThreadCreate (osThread(EthIf), netif); /* Enable MAC and DMA transmission and reception */ HAL_ETH_Start(&heth);

Netif link is up  and it is full configured which is in MX_LWIP_Init()

if (netif_is_link_up(&gnetif))

{ /* When the netif is fully configured this function must be called */ netif_set_up(&gnetif); }

But ETH interput never called.

void ETH_IRQHandler(void)

{ /* USER CODE BEGIN ETH_IRQn 0 */

/* USER CODE END ETH_IRQn 0 */

HAL_ETH_IRQHandler(&heth); /* USER CODE BEGIN ETH_IRQn 1 */

/* USER CODE END ETH_IRQn 1 */

}

[T J]

Posted on June 11, 2018 at 11:45

After a systemReset,

You would expect some clocks would be stopped

Surely, it pulls the Reset line down and the system resets the AHB/APB/ATB buses into a startup state.

in the ARM help page,

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Cihehdge.html

 

SYSRESETREQWO

System reset request bit is implementation defined:

0 = no system reset request

1 = asserts a signal to the outer system that requests a reset.

This is intended to force a large system reset of all major components except for debug.

This bit reads as 0.

See you vendor documentation for more information about the use of this signal in your implementation.

in the reference manual: RM0385

5.1 Reset

There are three types of reset, defined as system Reset, power Reset and backup domainReset.5.1.1 System resetA system reset sets all registers to their reset values except the reset flags in the clockcontroller CSR register and the registers in the Backup domain (see Figure 11).A system reset is generated when one of the following events occurs:1. A low level on the NRST pin (external reset)2. Window watchdog end of count condition (WWDG reset)3. Independent watchdog end of count condition (IWDG reset)4. A software reset (SW reset) (see Software reset)5. Low-power management reset (see Low-power management reset)

[David Littell]

Posted on June 11, 2018 at 16:05

It may be that the HAL is enabling interrupts before the FreeRTOS-based stuff is ready to handle them.  Try checking the return code of osSemaphoreRelease().  You may need to move the HAL's Ethernet-specific interrupt enable(s) to a point after the task is really ready to deal.

[ismail fatih iltar]

Posted on June 12, 2018 at 08:08

Reset operation is so normal and it works.