Skip to content

Latest commit

 

History

History
109 lines (81 loc) · 4.38 KB

FAQ.md

File metadata and controls

109 lines (81 loc) · 4.38 KB
Raw

When using "Mass Storage" upload method, following error is displayed:

NODE_xxxxxx not found. Please ensure the device is correctly connected.

Checklist:

  • Verify this is the right board selected in Arduino IDE: "Tools -> Boards Manager"
  • Verify if you board is correctly connected
  • Verify if a mount point exists and check the mount point name. It should be the same than the one searched by the upload tool.

If not, then probably you have an older board with a different label used for the mount point.
Update the board.txt file to add <your_node_label> to the targeted board.
Example:
Nucleo_64.menu.pnum.NUCLEO_xxxxxx.node=NODE_xxxxxx
becomes
Nucleo_64.menu.pnum.NUCLEO_xxxxxx.node="NODE_xxxxxx,<your_node_label>"

Node names list has to be separated by ',' and double quoted (for Windows).

When using "STLink" upload method on Windows, nothing is happening:

Warning

deprecated since core version higher than 1.5.0

This is probably due to the missing MSVCR100.dll.

You can easily check that by trying to launch manually ST-LINK_CLI.exe which is in your Arduino install packages folder:

STM32Tools\<x.y.z>\tools\win\stlink\

To solve this, install Microsoft Visual C++ 2010 Redistributable to get MSVCR100.dll

How do I know which (stm32duino/libmaple) core am I running on?

try this code

void setup() {
	Serial.begin();
}

void loop() {
#ifdef ARDUINO_ARCH_STM32
	Serial.println("stm32duino core");
#elif defined(ARDUINO_ARCH_STM32F1)
	Serial.println("libmaple core");
#elif defined(ARDUINO_ARCH_STM32F4)
	Serial.println("libmaple f4 core");
#else
	Serial.println("unknown core");
#endif
	delay(1000);
}

Debug

Debug can not be functional using generic when some features are enabled. Example, with Generic L486 with USB enabled. When USB is initialized, it configures all the pins available in the PinMap_USB_OTG_FS: https://github.com/stm32duino/Arduino_Core_STM32/blob/c6bc5b23761c30ff5ef08baa22af1519b0a76d5a/variants/STM32L4xx/L475V(C-E-G)T_L476V(C-E-G)T_L486VGT/PeripheralPins.c#L403-L411

In this case PA_13 is JTMS-SWDIO preventing debug to be functional. To avoid this, it is required to redefine the PinMap_USB_OTG_FS array to remove useless pins as explained here, like this:

const PinMap PinMap_USB_OTG_FS[] = {
  // {PA_8,  USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_SOF
  // {PA_9,  USB_OTG_FS, STM_PIN_DATA(STM_MODE_INPUT, GPIO_NOPULL, GPIO_AF_NONE)}, // USB_OTG_FS_VBUS
  // {PA_10, USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_OD, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_ID
  {PA_11, USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_DM
  {PA_12, USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_DP
  // {PA_13, USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_NOE
  // {PC_9,  USB_OTG_FS, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF10_OTG_FS)}, // USB_OTG_FS_NOE
  {NC,    NP,         0}
};

Issue discussed here: stm32duino/Arduino_Core_STM32#2047

OS specific

Linux

USB serial (CDC) stalls initially and connecting using a serial monitor fails

problem:

after a sketch is compiled and and firmware installed. on resetting the board. In some Linux distributions. usb serial (cdc) initially stalls could be into the 10s of seconds after a reset. There is no response in the serial monitor (e.g. putty), in fact the serial monitor (e.g. putty) simply won't connect. running dmesg command did show a /dev/ttyACMx device.

discussion and solution:

create a udev rules file e.g. /etc/udev/rules.d/45-stm32duino.rules add a line like

ATTRS{idProduct}=="5740", ATTRS{idVendor}=="0483", MODE="664", GROUP="plugdev" SYMLINK+="stm32duino" ENV{ID_MM_DEVICE_IGNORE}="1"

make sure that the product id and vendor id matches that used in your sketch.

the main thing is that ENV{ID_MM_DEVICE_IGNORE}="1" which tells udev not to treat it as a modem that issue is explored in this thread https://www.stm32duino.com/viewtopic.php?f=62&t=1000

Windows:

When using "BMP (Black Magic Probe)" upload method, error occurs it can't connect to the COM port.

Refers to this [[warning|Upload-methods#bmp-black-magic-probe]]