Could not halt device (18) STM32F3

[Andy6]

Hey everyone, new user here!

In our project we are using:

STM32F334R8T6

STM32CubeIde Version: 1.14.1
STM32CubeProgrammer release v2.17.0
Debugger probe - Nucleo-F334R8

 

along with HAL implementation of handling communication using UART + DMA. Due to error in our architecture we have been calling
these functions in main function

HAL_HalfDuplex_EnableTransmitter
HAL_UART_Transmit_DMA
HAL_HalfDuplex_EnableReceiver

and following in an interrupt (so diffrent context which could interrupt any of those funcitons above)

HAL_UARTEx_ReceiveToIdle_DMA
HAL_UART_DMAStop
__HAL_RCC_DMA1_CLK_DISABLE();
HAL_UART_MspDeInit();
MX_DMA_Init();
MX_USART2_UART_Init();
HAL_UART_MspInit();

Obviously it caused serious issues and racing conditions, however when racing condition happen we also lose communication via st link.
Upon pausing the project we receive error (in Cube IDE):

Could not halt device (18)
Shutting down...
Exit.

Then in stm32CubeProgrammer I can connect to device and read flash (0x08000000), but not RAM (0x20000000):

15:45:11 : UPLOADING ...
15:45:11 : Size : 256 Bytes
15:45:11 : Address : 0x8000000
15:45:11 : Read progress:
15:45:11 : Data read successfully
15:45:11 : Time elapsed during the read operation is: 00:00:00.003
15:45:24 : UPLOADING ...
15:45:24 : Size : 256 Bytes
15:45:24 : Address : 0x20000000
15:45:24 : Read progress:
15:45:25 : Error: Data read failed

Only way to recover is to cycle power of the uC.

Question: can someone explain what could cause to ram being unreadable via debug interface?

I have never seen such behavior. Additionally, sometimes even connecting to the flash is not possible. If i wouldn't be able to read flash i'd expect program writing to random memory like clock control, gpio (disconencting debug pins) but that is not the case.

[Andrew Neil]

Is this on a custom board? An ST board? Other?

https://community.st.com/t5/community-guidelines/how-to-write-your-question-to-maximize-your-chances-to-find-a/ta-p/575228

 

PS

Is it a genuine ST-Link?

https://community.st.com/t5/stm32-mcus-products/blue-pill-stm32f1-board-gets-programmed-through-arduino-ide-but/m-p/668483/highlight/true#M242662

[Andy6]

Hey

It is custom board, using USART2 connected to RS485 transciver.

 

By st link i mean evalboard bought from botland.com.pl which in fact is not authorized reseller according to https://www.st.com/content/st_com/en/contact-us.html but in Poland its quite reputable shop. I will retest using evalboard received from ST at embedded world, I didnt think about that indeed.

I have updated OP with details about sw version and debugger. Thanks for suggestions

[AScha.3]

Hi,

>Additionally, sometimes even connecting to the flash is not possible.

So this looks like a hardware problem: bad connection to target. (bad ground, long wires, or other power source there, injecting spikes )

Try: make a new project , set debug (serial wire), clock tree, and if you have: a LED pin.

Make program, only LED toggle and HAL_delay...to see it running.

Then try here to connect (software reset) and look at the memories...

+

Can you show a pic of your construction (with st-link connected) ?

[Andy6]

It doesnt look like debugger connection issue. This happens only if our racing condition occurs (both task and interrupt reconfiguring dma/uart). Other than that it can go for hundreds of hours without problem to stop the device. And when issue occurs i am able to connect to flash but not the RAM.

 

I have attached pic with board-debugger connections.