Yet another OSX Rant – Peculiar issue

I am not sure if this is the same problem, but..

Did you see the post about Sierra requiring a modified version of the bootloader?
( and possibly a change to the core)

The post was in the last 2 or 3 weeks, so should not be too hard to find.

Note. I have not implemented the change to the bootloader etc into the master copy, as it could break things for all Windows and Linux users, which account for 95% of all users.

After posting my request, I saw a pending pull request on the github repo by “jaredburkett” specifically for mac timing issues.
I downloaded the appropriate binary and ran the tests again. The same issue persists.

I have not specifically looked for any threads wrt sierra recompilation. I will go through the board again to see if I missed anything.

Thank you for the help roger!

OK.

Looking at the output from DFU Util, it looks like it is uploading.

You could try removing the Serial.begin and Serial.print and see if GPIO works on its own, as its possible that something else in Sierra is screwing up the USB Serial.

You could also try STM’s F1 core rather than the LibMaple core as its USB implementation is completely different.

https://github.com/stm32duino

(There is a posting about how you install the STM core, as you can’t do it via the boards manager at the moment as the BM install only works for the Nucleo)

BTW.
I do have a old Macbook Pro, but its slightly too old to allow me to install Sierra. I also have a Hackintosh, but its the same situation, too old for Sierra, and as both work fine on Yosemite, and El Capitan respectively, I’m in no rush to buy new hardware just for the latest version of MacOs (as every new version of MacOS seems to bring a more issues and incompatibilities with external hardware – e.g. my USB mixing desk no longer works with El Capitan)

Thanks!!
I assume you are referring to this thread roger??

http://www.stm32duino.com/viewtopic.php?f=3&t=1656

(Oh and tried by removing the Serial.begin() section too..)
Tried and same result. I ll try with the F1 core and post my findings. Maybe it might save someone else some frustration later.

PS: I am using platformio for my development and not the arduino IDE. Still, it should not really matter much.

Krish2487 wrote:Thanks!!

PS: I am using platformio for my development and not the arduino IDE. Still, it should not really matter much.

That did the trick roger!!

Auto reset works, upload works, it just works..

The serial port shows up.. serial comms are functional..
Any specific insight in what can be done to repeat the process on platformio IDE??

I think there is a thread somewhere on the forum about platformio, but I don’t use it myself

About 90% of the forum members use the normal Arduino IDE. I few people use Eclipse, and some other IDE’s (like visual studio), but its hard enough supporting the Arduino IDE (which seems to have a new version about one a month, which needs to be tested to confirm it still works OK)

Now, things are getting interesting.
I have the arduino and platformio IDE installed.

I have used a variety of permutations and combinations ( maple_upload (platformio IDE) and binary (arduino), maple_upload (platformio IDE) and binary (platformio IDE), maple_upload (arduino) and binary (arduino), maple_upload (arduino) and binary (platformio IDE) )
to understand what might be thee issue.

I was able to upload the binary with either of the maple_upload scripts. However the serial port enumerated only when I compiled from the arduino IDE.
The serial port did not enumrerate when I compiled the same code with platformio IDE. Further investigation into the size of the compiled binaries revealed a difference in size of almost 50%!!!

This is the code I compiled

#include <Arduino.h>

void setup(){
Serial.begin(115200);
pinMode(PC13, OUTPUT);
digitalWrite(PC13, HIGH);
}

void loop(){
Serial.println("Hello World");
digitalWrite(PC13, !digitalRead(PC13));
delay(1000);
}

I suspect the platformio is not compiling the USB serial into the binary.

The bootloader only provides the DFU for upload. After the upload is complete, it simply jumps to the start of the sketch code, and if the skech has USB serial compiled in, you get USB Serial.

There are a whole bunch of “defines” (in boards.txt) which switch a variety of things (based on the menu settings in the IDE), but the main one if whether there is USB serial (as some boards have built in USB to serial devices, so don’t need or want USB Serial)

It seems more and more likely that your post about the USB Serial not being compiled along with the main code is spot on.

I uploaded the binary of the above sketch (compiled using arduino IDE) using maple_upload and was able to observe the serial output in terminal monitor.

Even platformIO was able to see the serial port!!.
Next I compiled the binary using the platformio and uploaded from within the platformio IDE (using the same maple_upload and dfu upload).
But this time the board was stuck and the serial port was lost. The board as reported earlier, reverted to the six quick flashes and slow flashing and then stopped altogether.

Unfortunately platformio uses Scons for the build engine, which is beyond my immediate understanding to manipulate.
Hence I requested a complete command of compiling the binary. I wanted to compile the same binary manually using the toolchain packaged along with platformio and check the results.. then see what is the difference in the Scons script and the STM32duino compilation process.

Thank you for the help so far roger!!

Update:

Changing the board definition from a generic_STM32F103C8 board to “maple_mini” solved the issue.
I am guessing the generic_STM32F103C8 boards do not, by definition, compile the USB Serial libraries.

I am now able to upload and compile the code from within platformio using the maple_upload script.

Thank you for all the help extended roger!!

I’m glad its working, but you will still have some issues if you set the board as Maple mini, because it probably wont reset the USB correctly then you press upload from the IDE.

Take a look in boards.txt generic stm32f103c in the upload menu it what defines are setup.

I did.
The differences between maple_mini and genericstm32f103c8 seem to be pretty much in the compilation and linking of the USB Serial and the reset vector address.
Oh and the available flash and RAM.

I can live with the manual reset of the board post upload.
So far, though, I have tried about 50-70 times since yesterday night. It has always uploaded reliably.

I always have to reset the board after upload to get it to start the sketch. It is a very acceptable compromise.