stm32: fix logging macros

[pguyot]

The bundled newlib doesn't print 64 bits integers so logging macros displayed garbage.

These changes are made under both the "Apache 2.0" and the "GNU Lesser General
Public License 2.1 or later" license terms (dual license).

SPDX-License-Identifier: Apache-2.0 OR LGPL-2.1-or-later

[UncleGrumpy]

The bundled newlib doesn't print 64 bits integers so logging macros displayed garbage.

I am confused, are you using the nano version of newlib? We do not use -specs=nano.specs (we use -specs=nosys.specs) so printing 64 bit integers should be possible as long as the build isn't configured with -DAVM_NEWLIB_NANO=on (which disables logging).

[pguyot]

I am confused, are you using the nano version of newlib? We do not use -specs=nano.specs (we use -specs=nosys.specs) so printing 64 bit integers should be possible as long as the build isn't configured with -DAVM_NEWLIB_NANO=on (which disables logging).

Sorry for the confusion. I'm not sure it's coming from newlib.

What I noticed is that if I used macros, the first argument ended up into the INFO brackets (where the timestamp should be), as if register passing with a 64bits value was broken.

[UncleGrumpy]

What I noticed is that if I used macros, the first argument ended up into the INFO brackets (where the timestamp should be), as if register passing with a 64bits value was broken.

Is this with additional changes you made or just the current logging macros in general? Do you have an example that I can replicate this with to investigate?

[pguyot]

Is this with additional changes you made or just the current logging macros in general? Do you have an example that I can replicate this with to investigate?

It was just current logging macros, but in the emulator.
I was printing the AVM_APP_ADDRESS value. I can try on a physical STM32.

[UncleGrumpy]

Oh, it sounds like the emulator may have been built with newlib-nano. The emulator looks like it was built with 3d-printer firmware in mind which typically wouldn’t need to printf 64-bit integers.

[bettio]

So, if it is not a newlib releated issue or we are not sure, I suggest updating the commit message so we don't leave misleading information.

[UncleGrumpy]

I am still not convinced these changes are necessary, it sounds more like an issue with the simulator that was being tested. I have never seen the problem it addresses on real hardware.

[UncleGrumpy]

It might make more sense to change the log format based on if AVM_NEWLIB_NANO=on is defined, rather than disable logging completely when newlib nano is enabled, then the sim (or any other nano enabled build) could have working logs, without crashing non nano builds later when the milliseconds overflow an unsigned long. I realize this could take a couple months, but I would like to think that a well written application could continue to run for this long without crashing.

[pguyot]

I changed this to draft. I need to run the test on real hardware and investigate further. This was a default build of stm32 code.