Skip to content

Serial print hangs - discovery stm32f4 #317

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
MauroMombelli opened this issue Sep 7, 2018 · 12 comments
Closed

Serial print hangs - discovery stm32f4 #317

MauroMombelli opened this issue Sep 7, 2018 · 12 comments

Comments

@MauroMombelli
Copy link

The following code (a modified version of ascii table to include a blink to a led) will 100% hang without any output to serial at the first Serial.print().
Works fine on 1.2.0

/*
  ASCII table

  Prints out byte values in all possible formats:
  - as raw binary values
  - as ASCII-encoded decimal, hex, octal, and binary values

  For more on ASCII, see http://www.asciitable.com and http://en.wikipedia.org/wiki/ASCII

  The circuit: No external hardware needed.

  created 2006
  by Nicholas Zambetti <http://www.zambetti.com>
  modified 9 Apr 2012
  by Tom Igoe

  This example code is in the public domain.

  http://www.arduino.cc/en/Tutorial/ASCIITable
*/

void setup() {
  pinMode(PD12, OUTPUT);
  digitalWrite(PD12, HIGH);
  //Initialize serial and wait for port to open:
  Serial.begin(9600);

digitalWrite(PD12, LOW);
  // prints title with ending line break
  //Serial.println("ASCII Table ~ Character Map");
  //digitalWrite(PD12, LOW);
}

// first visible ASCIIcharacter '!' is number 33:
int thisByte = 33;
// you can also write ASCII characters in single quotes.
// for example, '!' is the same as 33, so you could also use this:
// int thisByte = '!';

void loop() {
  static long last = millis();
  if (millis() - last > 1000){
    digitalWrite(PD12, LOW);
    if (millis() - last > 2000){
      digitalWrite(PD12, HIGH);
      last = millis();
    }
  }
  // prints value unaltered, i.e. the raw binary version of the byte.
  // The Serial Monitor interprets all bytes as ASCII, so 33, the first number,
  // will show up as '!'
  Serial.write(thisByte);

  Serial.print(", dec: ");
  // prints value as string as an ASCII-encoded decimal (base 10).
  // Decimal is the default format for Serial.print() and Serial.println(),
  // so no modifier is needed:
  Serial.print(thisByte);
  // But you can declare the modifier for decimal if you want to.
  // this also works if you uncomment it:

  // Serial.print(thisByte, DEC);


  Serial.print(", hex: ");
  // prints value as string in hexadecimal (base 16):
  Serial.print(thisByte, HEX);

  Serial.print(", oct: ");
  // prints value as string in octal (base 8);
  Serial.print(thisByte, OCT);

  Serial.print(", bin: ");
  // prints value as string in binary (base 2) also prints ending line break:
  Serial.println(thisByte, BIN);

  // if printed last visible character '~' or 126, stop:
  if (thisByte == 126) {    // you could also use if (thisByte == '~') {
    // This loop loops forever and does nothing
    thisByte = 33;
  }
  // go on to the next character
  thisByte++;
}
@fivdi
Copy link

fivdi commented Sep 7, 2018

The code posted above works for me on an STM32F407G-DISC1 board. Here's the first few lines of output:

!, dec: 33, hex: 21, oct: 41, bin: 100001
", dec: 34, hex: 22, oct: 42, bin: 100010
#, dec: 35, hex: 23, oct: 43, bin: 100011
$, dec: 36, hex: 24, oct: 44, bin: 100100
%, dec: 37, hex: 25, oct: 45, bin: 100101
&, dec: 38, hex: 26, oct: 46, bin: 100110
', dec: 39, hex: 27, oct: 47, bin: 100111
(, dec: 40, hex: 28, oct: 50, bin: 101000
), dec: 41, hex: 29, oct: 51, bin: 101001
*, dec: 42, hex: 2A, oct: 52, bin: 101010

That being said, after an upload the board does appear to hang sometimes and it's necessary to hit the reset button in order to get it to work.

@fpistm
Copy link
Member

fpistm commented Sep 8, 2018

Hi @MauroMombelli
I've just tested and get the same status than @fivdi . It's ok.
Could you tell us more about your config?
Which Host OS?
Arduino IDE version?
I assume you have connected a FTDI to PA3/PA2 as the STLink is not connected by default to USART3 (PA3/PA2).
It requires connections for ST-LINK VCP on U2 pin 12 and 13. See UM1472 §6.1.3 ST-LINK/V2-A VCP configuration:
https://www.st.com/content/ccc/resource/technical/document/user_manual/70/fe/4a/3f/e7/e1/4f/7d/DM00039084.pdf/files/DM00039084.pdf/jcr:content/translations/en.DM00039084.pdf

For my test I've connected another STLink form a Nucleo 64 to get the VCP.
Maybe if you use the STLink from the F407 board you can try to update its Firmware

@MauroMombelli
Copy link
Author

MauroMombelli commented Sep 8, 2018

@fivdi ill try again the reset but pretty sure i did it.

arduino ide 1.8.5, using default STM32F407G-DISC1 over stlink, serial set to "Generic"
linux, but using the integrated arm-none-gcc
Using an external uart to usb converter. The change of library version + reupload for test has been executed without touching the hardware, and was working properly.

after an upload the board does appear to hang sometimes and it's necessary to hit the reset button in order to get it to work.

uhmm interesting, could i have hit some case where this could be reproducible? would be helpful to upload the binary?

Maybe if you use the STLink from the F407 board you can try to update its Firmware

that is something i did not think of

@fpistm
Copy link
Member

fpistm commented Sep 8, 2018

but using the integrated arm-none-gcc

What do you mean by that? the default arduino arm gcc 4.8.3 ?

The change of library version + reupload for test has been executed without touching the hardware, and was working properly.

And by this? you mean core version?

@MauroMombelli
Copy link
Author

What do you mean by that? the default arduino arm gcc 4.8.3 ?

yes

And by this? you mean core version?

yes, core 1.2.0 works, 1.3.0 don't. i only updatetd the core and reuploaded the script.

but now im facing another issue, any code uploaded with arduino "break" the chip, i need to reboot it with boot0 HIGH and unlock the flash (not sure the unlock step is necessary), so probably something broke in the ide while switching cores (i did all that switching from board manager)

@fpistm
Copy link
Member

fpistm commented Sep 8, 2018

This core is no more compatible with 4.8.3 since a while. So I do not understand how you could use it...

The platform.txt specifies the arm gcc toolchain version to use to avoid issue with another core using also arm gcc toolchain:
compiler.path={runtime.tools.arm-none-eabi-gcc-6-2017-q2-update.path}/bin/
The standard gnu++ version to use as per default it is: -std=gnu++14 which is not supported by the 4.8.3...
And finally there is a guard in Arduino.h related to arm gcc version:
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/cores/arduino/Arduino.h#L29

#if GCC_VERSION < 60300
#error "GCC version 6.3 or higher is required"
#endif

This looks really strange you used the 4.8.3 version

Switching from the board managers should work fine, basically it remove all related stuff and extract the new one. When user met issue, it is often because he made some manual actions. (ex: using git repo,...).

What I can advise is to start from a clean Arduino installation.

@fpistm fpistm added waiting feedback Further information is required not reproduced labels Sep 13, 2018
@fpistm
Copy link
Member

fpistm commented Sep 19, 2018

Hi @MauroMombelli,
any update on this?

@BNNorman
Copy link

Might not be related but I was recently fiddling with my blue pills and found that I needed a delay(X); after the Serial.begin(...); As best I could determine the value of X lies between 200 and 300 millisec. Since 300 works everytime that's what I use in my STM32F103C8 sketches.
I am using the Roger Clark Arduino_STM32-Master but I'm wondering if a delay is also needed here as I'm looking at trying the HAL based core to get the STM32 RTC working.
Regards.

@fpistm
Copy link
Member

fpistm commented Oct 17, 2018

Hi @BNNorman
By default the 'Serial' of Roger's core is the Serial over USB, so I guess that's why you have a small delay to let it up and running. Using a hardware serial will allow to get it after the Begin().

@BNNorman
Copy link

Interesting - I'm not using the USB connector on the Blue Pill - I use an FTDI cable with RX/TX connected to PA9 and PA10 and Serial.begin() works fine apart from a delay needed. After trying to get the Arduino IDE to use the USB for sketch uploading and the Serial Monitor I gave up because it was such a faff on a Windows PC with DFU device not being recognised. To use the Serial Monitor with the USB port, in the past, I had to instantiate a USBSerial object. I'm no expert on this so I welcome any input.

@fpistm
Copy link
Member

fpistm commented Oct 17, 2018

Have you look on stm32duino.com which is the primary place for support. Here this is the place for issue with Arduino_Core_STM32 not Arduino_STM32.
Anyway with BP and this core using the Serial it do not request any delay. Just a tips using the Arduino Serial monitor the message after upload is not catch but using another serial term you see it. Maybe the same issue with Roger's core.

@fpistm
Copy link
Member

fpistm commented Nov 2, 2018

Close it as no user feedback.

@fpistm fpistm closed this as completed Nov 2, 2018
@fpistm fpistm removed the waiting feedback Further information is required label Nov 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants