STM32F303xx UART not starting, why? Answer provided.

[enhering · Accepted solution]

Hi.

I used CubeMX to generate code for a STM32F303cc micro controller.

The code compiled and worked.

Then I refactored the code into a few C++ classes suited for my project.

The code compiled and worked.

But when I tried to use UART, the code compiled on both versions, but only worked on the CUbeMX generated one.

I reviewed all the code carefully, even with diff, but could not find the cause for the difference.

Many retries and days later I noted I was programming the uC with the hex file on the CubeMX version and with the bin file on the C++ version.

When I used the hex version, uart initialised correctly.

The moral of this story: when everything else fails, use a different binary format to program your micro controller.

[Imen.D]

Hello @enhering​ ,

I appreciate you posting your problem and the solution 🙂

I marked your answer as Best. This will help other users find that answer faster.

Thank you again for having reported the point.

Thanks

Imen

[enhering]

You are welcome.

Sharing knowledge is a pleasure.

[TDK]

Programming with the BIN or HEX file should not make a difference. There has to be another explanation. The memory can be compared using each programming method to determine what the issue is/was.

[enhering]

Please visit: https://community.st.com/s/question/0D53W00000Kq3CJSAZ/differences-between-using-hex-and-bin-files-to-program-an-stm32

There is, indeed, a difference. And in that difference may live a bug.

I wish I had time to find the real cause. As I miss that time, I published a possible solution for those who suffer from the same cause.

[TDK]

Yes, but publishing a solution that suggests arbitrarily changing between BIN and HEX files because one of them may have a bug does a disservice to the community. I won't harp on it. Glad your project is now working.

[enhering]

I just published a possible way out of an apparently unsolvable problem. Don't judge me so hard for that. My intentions are good. You are free to investigate further if you wish. The referred files are attached.

[Piranha]

> HEX files can be sparse, unwritten areas of flash will retain their 0xFF erased state. The BIN decribes all bytes, with 0x00 being chosen as the fill byte in this case.

Probably your firmware accesses memory, which it is not allowed to access and the difference between 0xFF and 0x00 values in that memory have different further consequences. Anyway it's a bug.