3 days ago i updated to Mbed Studio V1.4. Today i noticed something quite unexpected:
On my Artemis Thing Plus board (can be found as a custom target) most part of my code works just like before, however BufferedSerial and UnbufferedSerial APIs stopped to write() anything in the serial monitor. Other parts if the code still seem to work OK.
While on the MAX32630FTHR also BufferedSerial and UnbufferedSerial work just like before the upgrade.
The only change i made in the last 2 weeks was to upgrade Mbed Studio V1.3.1 to V1.4, so there is nothing else i can imagine causing this unexpected behaviour. Can please someone else confirm this?
Would be happy to downgrade to Studio V1.3.1 but i can not find a link anywhere, would highly appreciate a link to older versions.
Hi Peter,
Using the BufferedSerial with Mbed Studio V1.4 and a STM32H743VIT6 board. It works. Can you give your code? Before to use the “pc.write()” function I am testing if allowed (“if ( pc.writable() == true )”).
I have a project that i am keep updating for 2 years now. Actually the code base i wrote checks both for Mbed OS versions (5.x vs. 6.x) and determines which board is currently used (Artemis Thing Plus or MAX32630FTHR). For the Artemis i always use UnbuferredSerial for printing text on the console, with the MAX32630FTHR i prefer USBSerial since that has been reimplemented for that board, but need to fallback to printf for 5.x release on that board. So that code is somewhat complex.
However even this basic example fails on the Artemis board since upgrading to Mbed Studio V1.4. Tried several Mbed OS releases, that does not make any difference (however once i update to OS 6.9 i can not downgrade OS release anymore, this is new in Studio V1.4):
It actually returns a single ⸮ character that never changes. While if i build the same example for the MAX32630FTHR, it works as expected on the MAX32630FTHR even with Mbed Studio V1.4.
The same applies for BufferedSerial and even for good old printf. With Studio V1.3.1 and prior releases all these worked even on my Artemis board. I have only 1 such board but if the board was broken then most probably also other parts of my 1500+ lines of code would also fail.
My major problem is that i can not find a link for Studio V1.3.1 anywhere on the internet so i can not even downgrade until it gets fixed (or to rule out failure of my Artemis completely).
EDIT: forgot to mention i found this one before posting, so that is why i guess Studio V1.4 might be cuasing yet another issue on custom boards like the Artemis currently is.
Ok about the regression. Just tested your code on my board detected by a st-link but I have replaced USBTX,USBRX by PC9,PC10.
Mbed Studio 1.4 and Mbed OS 6.9.0: it works. It seems I am lucky!
I hope the issue will be fixed soon.
@JojoS
Thanks for the suggestion, modified the above example like that:
#include "mbed.h"
#include <cstdio>
#include <cstring>
#define SERIALBAUD 115200
UnbufferedSerial pc(USBTX, USBRX, SERIALBAUD);
char myBuffer[20] = {0};
int main() {
strcpy(myBuffer, "Hello World!\n");
if ( pc.writable() == true )
pc.write(myBuffer, sizeof(myBuffer));
while (1) {
strcpy(myBuffer, "Wishing you ");
if ( pc.writable() == true )
pc.write(&myBuffer, sizeof(myBuffer));
ThisThread::sleep_for(1000ms);
strcpy(myBuffer, "a nice day!\n\n");
if ( pc.writable() == true )
pc.write(&myBuffer[0], sizeof(myBuffer));
ThisThread::sleep_for(1000ms);
}
return 0;
}
It makes no difference.
On the Artemis i still get a single ⸮ character as output, while on my MAX32630FTHR all the variations work without any glitches. I get no warnings or whatsoever during compilation even on the Artemis board. And it really puzzles me why basically the same code has been working for even on the Artemis board ever since Mbed began to support that target since V6.3 and through all the Mbed Studio releases until now.
Checked my Artemis board with Arduino IDE using the proper Arduino core (which is built on top of a Mbed OS 5.x release) and printf, println, etc still work in Arduino, so most probably it is not caused by a recent board failure on my side.
If i use Mbed CLI 2 for compilation&building then printf and (Un)BufferedSerial work again on the Artemis board. For me it counts as a proven regression in Mbed Studio V1.4. Hope it will get fixed soon.
Tried yet another thing. When using GCC_ARM compiler in Mbed Studio V1.4 printf and (Un)BufferedSerial work on the Artemis. So it seems ARMC6.15 might be causing the issue on this target.
(ARMC6.14 was ok on this target)
I was having the same problem.
The target board is GR-MANGO (renesus RZ-A2M).
The program will not go beyond printf().
ARM Compiler V6.14 was OK and V6.15 was NG.
It seems that this problem is relative to Arm Compiler 6.15. A toolchain version changed in Mbed Studio 1.4.0. Mbed Studio 1.3.1 was shipped with Arm Compiler 6.14. I’ll reach out to Arm Compiler team and ask about this problem. In the meantime the only thing I can recommend is switching to GCC_ARM: Switching to GCC - Installing | Mbed Studio Documentation
I found this right now, which tells me ARMC 6.16 will be the default in Mbed Studio (or Keil Studio Cloud). Would love to revert to ARMC compiler as that is much faster than GCC_ARM.
Is there any info if this issue is resolved when using ARMC 6.16?
Based on my knowledge, Arm Compiler 6.15 had a few defects with bit-field accesses, and the specification for how bit-fields are accessed has also changed over time.
I think this is related to printf or BufferedSerial issues. The workaround is to add -fno-fine-grained-bitfield-accesses option to profile (“ARMC6” - “common”) which you are now using.
e.g. For Debug profile, edit mbed-os/tools/profiles/debug.json
@MACRUM
Upgraded to Mbed Studio 1.4.2 (ARMC6.16) and to Mbed OS 6.15.
(Un)BufferedSerial works again with my Artemis board again out of the box.
In case of MAX32630FTHR i have to roll back changes of this PR, but after that also this board seems to function again as expected. This was not the case earlier.
