2020-06-26 12:52 PM
Hello: I have an stm32h753 eval2 board. I recently purchased an stlink-v3set. Connecting to board using CN9, everything works: programming, CPU information, memory dump, etc.
However, embedded instrumentation shows that uart1 is asserting a tx empty interrupt which is never serviced. With stlink-v3 unplugged and USB attached to the embedded stlink USB port on the board, uart1 runs fine; interrupts are serviced. Enabling FIFO mode does not change symptoms. I have embedded instrumentation in the uart driver and ISR.
When STLINK-V3 is attached, when stuck:
CR1 = 0x2000_80ad
CR2 = 0x0000_2000
CR3 = 0x0000_0000
ISR is 0x08e0_00d0.
tx empty flag is 0x0000_0080.
Why does connecting CN9 (or, disconnection of the USB for the embedded STE_LINK) have an effect on servicing interrupts from UART1? When in this state, the processor is getting and servicing interrupts from a timer at a 100Hz rate, and has set up FMC SDRAM, and is otherwise running fine. (Also, this serial driver runs fine on an stm327f demo card).
Any thoughts/insights are appreciated. Thanks!
More information: Under these conditions, it appears the NVIC is not presenting the interrupt. UART1 uses interrupt 37. NVIC_ISER1 reads as 0x0000_0020, indicating 37 is enabled. NVIC_ISPRO1 is 0x0000_0020, indicating the interrupt is pending. But, NVIC_IABR1 is 0x0000_0000, indicating the interrupt is NOT active. I can, through STMcube programmer, manipulate the UART registers so that no interrupt is asserted and to assert a new interrupt; the interrupt active register in NVIC does not change. Again, this only happens when the STLINK-V3 is connected to CN9.
2020-06-26 09:54 PM
What is CN9? Are you trying to use two debuggers in parallel?
Isn't the code looping in an interrupt of higher or equal priority than the USART1 interrupt?
Try a minimal program.
JW
2020-06-26 11:15 PM
Thank you for responding. CN9 is a 20 pin debug header for JTAG and SWD on the eval2 board. The goal is to use the STLINK-V3 and not the on-board STLINK. USB for the on-board STLINK is not connected in this case. The documentation describes CN9, and does not give any indication that jumpers need to be removed or solder bridges need to be installed/removed in order to use CN9. Right now, I do not care that there is nothing connected to the UART1 pins. The UART should not care; it should simply transmit the chars into the bit bucket. (Flow control is not enabled, BTW). There is no evidence that the code is looping in a higher priority interrupt. Even if it were, the question is, why does it behave normally with STLINK-V3 connected, and USB connected to the on-board STLINK instead?
2020-06-27 12:51 AM
> question is, why does it behave normally with STLINK-V3 connected, and USB connected to the on-board STLINK instead?
With both debuggers connected in parallel and active?
I have no idea how that might work at all.
JW
2020-06-27 06:04 PM
I have temporarily removed 0-ohm resistors R300, R301, R302. This means the on-card STLINK cannot drive the SWDIO. SWCLK, and SWO signals. The on-card STLINK can still be powered up and provide the virtual com port over USB, but only the STLINK-V3 attached to CN9 can drive the debug signals. Uart driver still hangs when CN9 is connected but does not hang when disconnected. I've not stepped through the code on the "when connected" case yet but symptoms are the same; I believe something in the nvic is still the culprit when CN9 is connected.
2020-06-29 09:55 AM
I'm out of ideas at this point, sorry.
Maybe try asking ST.
JW
2020-07-07 06:43 AM
Thanks, JW.
More data: I switched to using SDT14C on the eval2 board; this is a much smaller connector. This made no difference; behavior was the same.
However, I did find this, which I had not noticed before. When stm32cubeprogrammer was connected (both physically and logically), the problem is present (no UART1 interrupts are active or serviced). When I "disconnect" under stm32cubeprogrammer (so, logically disconnect the host software), the processor resets, and runs normally, including serial I/O behavior, though the stlink-v3 is still physically connected to the card.
2020-07-13 01:58 PM
Some additional data: STM32 cube programmer is v2.4.0 running under windows 10. This shows a "cpu" window, which is very useful (that is what I have been trying to use).
The features in this window (reg dump, step, halt, reset, run, etc) are very useful. The documentation (UM2237, rev 11, Feb 2020) has screen shots which do not show the CPU option, nor does it describe this window at all.
I found it shows up in an online training video, though the presenter does not try and run anything from the window.
Does anyone know if/where documentation on the CPU window exists? (Or, even if it works properly?)