Arduino for STM32

We just need to know which core do you use.
see this for your reference: viewtopic.php?f=2&t=301

If it runs on bluepill correctly, then it must be related to the new board and/or STM derivate MCU, so you should check the supply voltages / pins / core settings...

Thanks! I eliminated the lines for beginTransaction and endTransaction, and I'm getting slightly better results (12.5kHz) but I didn't get your first point; are you suggesting to use something like dest=SPI.transfer(zeros, count) instead of for (uint8_t ii = 0; ii < count; ii++) { dest[ii] = SPI.tr...

I assume that you are using the official STM core. Here are some suggestions: i) You have to look whether there is another block transfer function to transfer array of bytes instead of doing several single byte transfers. ii) you can use digitalWriteFast() to set CS. iii) you can skip SPI.beginTrans...

Don't you have some SPI pins of the F303 board shared with other on-board chips?
Which SPI interface do you use? CS pin?
Which core?

Insert some debug prints into socketSendUDP function so that you know where exactly is hanging
Also, you can add some debug prints in the yield() function.

Btw, which core do you use?

If you are using the Ethernet library form Arduino, then it should not hang at all because the function socketSendUDP() - which is called in udp.endPacket() - has an integrated timeout condition, see here: https://github.com/arduino-libraries/Ethernet/blob/75a3c37b5e513305b82e926ca6a4f8190f536c9d/sr...

To guarantee that the amount of data is less than the buffer size is not enough. You also have to make sure that the buffer will be emptied within a specified time. Basically, if the value indicated by available for write is (<buffer size>-1) then theoretically no overflow should occur. In this case...

I ran the sketch on a bluepill board and I got 1 ms processing time. This is only possible because the serial transmission is actually non-blocking . The user should check before sending the data that there is enough space in the Tx buffer, otherwise Tx data overflow will occure. If you insert this ...

This sequence if ((millis()-startL) < printDelay){ delay((printDelay - (millis() - startL))); } looks very dubious. I do not know what you wanted to achieve with that, but I se a big problem when (millis() - startL) becomes greater then printDelay. This can happen when the serial interface cannot se...