Frederic Pillon

> if this code is called from inside an ISR (or another context where interrupts are disabled) and Serial has TX ongoing, I think this will result in an infinite...

> I also think this might affect STM32LoRaWAN, since I _think_ STM32CubeWL does some printing from inside ISRs too... Bad news. Will check what I can do.

Hi @Captainslarty Thanks to report this. You're right, this mcu got up to 756Kb. To define boards we generate several files automatically using the [STM32_open_pin_data](https://github.com/STMicroelectronics/STM32_open_pin_data) database. This is the same...

here is the ram size entry: `Nucleo_144.menu.pnum.NUCLEO_U575ZI_Q.upload.maximum_data_size=786432` --> (192 + 64 + 512) * 1024 Anyway, I didn't check if you can use all the RAM. There is 4 SRAM...

This would be fine to see if all RAM are contiguous else there will be an issue. 😉 In a general way this core simply manage maximum contiguous RAM without...

I think it is OK anyway I would prefer warn you :wink: About the Nucleo H7 it is already in the request variant list: https://github.com/stm32duino/Arduino_Core_STM32/issues/722 I've reference your comment too.

Hi @Captainslarty issue confirmed internally and xml files will be corrected. I made a patch to fix them in the core. About the size, We only set 768K as the...

> Sorry about that, I wasnt aware of the best practice. https://github.com/stm32duino/Arduino_Core_STM32/blob/main/CONTRIBUTING.md#4-commit-messages > Your commits need to be [atomic](https://www.freshconsulting.com/atomic-commits/) which allows the repository to remain flexible after merging.

> > Your commits need to be [atomic](https://www.freshconsulting.com/atomic-commits/) > > Got it, only 1 board or generic MCU Per PR Per commit not PR😉

So to sum up you should have a PR with 2 commits: 1 to add generic and one to add the nucleo. Anyway, you should wait as you PR including...