I’m posting this because I just KNOW someone else is being driven nuts by this.
I’m migrating away from the Atmega chips and Arduino, but doing it in stages. For now I’m using STM32F devices with the Arduino IDE. I have a mesh system that works OK wiht the Atmega but it really needs a bit more CPU horsepower and memory. I’m going to write the new mesh from scratch so I thought I’d at least get the off the shelf stuff working first.

After some false starts I got it all running, talking to the old Atmega based nodes and all was good. Popped it into a case, powered it up…nada…zip…nothing. It seemed to boot as best as I could tell but the slave nodes never connect.

Switching back to the PC to power it, all works just fine. Ahh, must be power. So I go on and add way more filtering than needed, check the +5v and +3v rails with a scope, they seem quieter than the PC by a wide margin, way less switching noise. I’ve put bypass caps everywhere at this stage and lost two days to this, I’m about ready to quit. I’ve even used a USB power bank on the basis that should be as close to a perfect supply as possible. Every time the moment I plug the PC in, everything syncs up and all is good.

So I decide to plug a USB to TTL onto A9 and A10 and power it that way… nothing, no boot messages at all. But on reset I CAN use the bootloader, uh? At this point I’ve reached out to people for a few ideas and not had anything back. On the way back from I job I decide I have way too much else to do so it can all go back in it’s project box for now.

Then sat down blasting aliens on my phone I had a thought… Am I barking up the wrong tree here, it can’t be power. Does the STM32 bootloader evaluate available serial ports at boot? Are the UARTs getting messed up somehow. If the PC isn’t connected is port 0 ( Serial.begin() ) getting messed up? And then it hit me. Like many coders I use a line like this:

  Serial.begin(9600);
    while (!Serial) {}

Some of the ARM based Arduinos need this, I was also seeing some loss of console logs so I left it there, and this is where it falls over. We get stuck here, the mesh never starts, the other serial port never gets initialised hence the no output on the other port. I wouldn’t say it’s a bug, in fact the contrary I can see it being handy to jam the STM32 into a debug mode. What happened is if there is no USB connection the serial port presented by the bootloader/HAL presented UART simply never becomes ready. The code above hangs and nothing ever works. For now, I’ve removed that line and added a delay (5 seconds) as a fix for having no delay to wait for the port to become ready.

Sometimes a break is all you need!