Migrating from STM32H755 to STM32H733, UART breaks

[AJone.5]

I'm migrating source that has run for quite a while successfully on H755 to a new project so we can swap to the H733 micro for the increased memory security features.

The project is not currently using the external OCTOSPI, building a reduced version that will fit in the onboard memory

I am having a run time hang with the UART8 at the very beginning of our app code after the FRTOS and main.c initialization.

The situation is that the interrupt for the TX fifo watermark fires once correctly, I send the contents of the fifo, but then never fires again.  If I set a breakpoint in the ISR, then hitting that breakpoint changes the behavior and we hit the interrupt repeatedly as expected when I manually run each time.

The break changing the behavior made me think of interrupt contention or tasking, no sign we ever leave our main task and I have tried setting the uart8 interrupt priority from 5 to 0 and 16, no change in behavior.

Obviously there are a lot of things that could be going on, but I am surprised there is any change in operation as it was supposed to be a 'drop in replacement' and the uart driver has been heavily used and reviewed in the past.  I have tried building with both the 1.11 and 1.12.1 versions of the SDK.  I have looked at the SFR and the state of the interrupt enable bits is what I would expect.

I did have to change some clock registers as part of the migration, but the output clock for the UART is unchanged and the baud rate is correct for the bytes that are transmitted.

Any tips on what to look at next?  I don't see anything that seems different about the uarts on these platforms, but maybe I am missing something.

[Tesla DeLorean]

Well completely differ die, so perhaps some functional differences of "improvements" in the design.

UART8 characteristics look to be similar in features/function.

Might be some changes in the IRQ table, and AF pin associations.

Show the HAL code initializing each.

Show IRQ Handler code.

IRQ Handlers should continually re-enter until the source is clear. If the NVIC context is not popped properly it can block further entry to this handler and those with same or less premption level (larger#)

FreeRTOS might impact things if you keep changing context in/during interrupt handlers/callbacks. That all bit/flags are in right states, and debug break-points alter behaviour would suggest it's RTOS related.

What's level 16? The NVIC here has 4-bits, doesn't it? And those can be split by priority and premption. Check Group settings.

What's the timebase source? A TIM or SysTick?

Perhaps illustrate failure outside of the RTOS, or don't context switch in handlers.