New batch of STM32F401RET6U on Nucleo-64 boards is not working with the same firmware

[scozzolino_97]

Hello guys,

recently in my lab a new batch of STM32F401RET6U MCUs on Nucleo-64 boards is arrived (MB1136-F401RE-C04 SN K252502xxx). After I set these in the same hardware way of my old ones (i switch UART2 PINs PA2 (TX) and PA3 (RX) from the ST-LINK to the ST Morpho connectors desoldering SB13 and SB14 and soldering a 0Ohm on SB62 and SB63), and uploading a version of my firmware which today is still working properly on my old boards (MB1136-F401RE-C04 SN A204505xxx), it doesn’t run correctly for  the new ones. The main problem i notice in debug mode is that UART1 and UART2 sometimes work correctly and sometimes not (confirming also my hardware modifications when the lines are ok), while SPI2 which I use to communicate with the ethernet chip W5500 on my carrier board never works (even drastically lowering its frequency, and with the old boards it works at 21MHz), I2C1 line always seems to work properly. Being more precise, in order to mount all Nucleo-64 boards on my carrier board I’m forced to phisically separate the ST-LINK from the MCU, allowing me to use only the HSI (Internal RC High Speed Oscillator) because I don’t mount a crystal oscillator on X3 footprint. 
What am I doing wrong in the porting from old boards to new boards of the same MCU?

[Andrew Neil]

The main problem i notice in debug mode is that UART1 and UART2 sometimes work correctly and sometimes not

:

:

 I’m forced to phisically separate the ST-LINK from the MCU, allowing me to use only the HSI (Internal RC High Speed Oscillator) 

 

Using an internal RC oscillator is never a great idea with UART comms.

What baud rate are you using?

 

Have you used a scope and/or logic analyser to see what’s happening on the wires?
And compare & contrast with the “working” boards.

 

Do you have any boards with the ST-Link still attached?

If not, try linking the MCO from a broken-off ST-Link to one of the failing boards, and see if it works when clocked from that...

[mfgkw]

When UART sometimes works and sometimes doesn’t then I assume the HSI oscillator is different from your old boards - which is nothing you can complain about, since there is no exact frequency guranteed.

Probably you need use a more stable frequency (crystal or clock input from external source). When you have more than one board connected together maybe one can use its HSI and deliver the clock to the others. Then a drift hits all of them in the same way.

[scozzolino_97]

I tried both with a new board with ST-Link still attached and a new one with the programmer separated but the behavior is always the same. I’ve used a logic analyser (linked directly to Nucleo-64 ST Morphos) and i’ve seen that “there is life” on all the serial lines (SPI2 included). About USARTs, UART1 is set to 4800bps to communicate with a rs-485 half-duplex temperature sensor and when it doesn’t work properly there aren’t sensor’s replies on RX line (the times when it works I can see both TX and RX lines), while UART2 is set to 115200bps to communicate with a GEN4-ULCD touchscreen display (VisiGenie protocol) and when it works i can see both TX and RX lines, when is not working I only see strange bytes on TX. Another strange strange thing I noticed is that the output pin I set to have display reset (PB2 set as simple GPIO OUT) the signal doesn’t arrive to the HMI through my carrier board (never happened with old cut boards on my PCB). With a scope I’ve seen SPI2 SCK signal, but it is too fast to be correctly sampled by the probes I have... I’ve also tried to enable MCO1 on PA8 to see the 16MHz HSI real frequency with the logic analyser, it allowed me to calibrate it just adding in the code the software adjustment via the command __HAL_RCC_HSI_CALIBRATIONVALUE_ADJUST(12), but still nothing workS properly. 
I repeat, the fact that, after all these checks, with the same code the behavior changes drastically from one old STM32F401RE Nucleo-64 board to another one new (but nominally equal) is making me lose ideas on how to solve it…

​@Andrew Neil ​@mfgkw