Skip to main content
timl
timl
Associate
June 13, 2019
Question

Why is Arduino / Nucleo F103RB Losing Code Space?

  • June 13, 2019
  • 3 replies
  • 1210 views

I have been using the Arduino 1.8.9 app for several months programming the Nucleo-F103RB development board with my application. I have several boards and some are self powered and others USB powered. Yesterday, on a self-powered board, I received a message "No space left on device" below.

cp: /Volumes/NODE_F103RB/Project.ino.bin: No space left on device

copying /var/folders/44/m8hjkbb500g80c81hqx5tqlc0000gp/T/arduino_build_48675/Project.ino.bin to /Volumes/NODE_F103RB

In Mac OS, it is showing the "disk" size is only 33kB instead of the normal 160kB. I tried power cycling, moving back to USB powered, removing all files (with only added up to 32kB reported in OS) and even erasing the chip with ST-Link Utility. The same message appeared. I finally programmed a 'somewhat' blank project with System Workbench which worked fine. Power cycling the device showed the full disk size back to 160kB. I switched from the onboard ST-Link (with jumpers) and back to self-powered. I programmed the device several times today and now again, I get the same out of space message.

Any idea why this happening and what is causing this behavior? Is there a way to prevent from losing disk size for the copy? Where is the space going? Is how the device powered impacting it? What would make it start happening now? I have been optimizing my program the last week to be smaller so it shouldn't be some code size limit. Though the version of Arduino hasn't changed in my development time, could there be something it is breaking related to size?

For those wondering, I am using the Arduino toolset because after a week of troubleshooting, I still couldn't get I2C working in System Workbench. It just worked in Arduino.

This topic has been closed for replies.

3 replies

turboscrew
turboscrew
Senior III
June 13, 2019

I think STM32duino-forum is better place for Arduino-questions.

https://mcu.selfip.com/

waclawek.jan
waclawek.jan
Super User
June 13, 2019

Are you talking about the "disk" which is related to the on-board STLinkV2-1? I.e. the one, onto which you "copy" the binary to upload it into the target mcu?

> In Mac OS

This may be the problem. Or, more precisely, the problem is in the implementation of that "disk" by STLink - a file written onto a "disk" should not disappear into thin air - but it appears that Win is happy with that.

Replugging won't help?

JW

timl
timlAuthor
Associate
June 13, 2019

When building with Arduino app it reports how much code space is used by the program out of the total available like below. It shows the correct total number of bytes and how big my program is.

Sketch uses 33032 bytes (25%) of program storage space. Maximum is 131072 bytes.

Global variables use 1684 bytes (8%) of dynamic memory, leaving 18796 bytes for local variables. Maximum is 20480 bytes.

When everything is working correctly, there is plenty of code space available and in the OS, it shows Capacity: 160KB.

0690X000008icldQAA.png

When it stops working, the message shows up in the original post. When I view the OS info, it shows Capacity: 33KB. I have powered down the device, unplugged USB and the other items listed. So far only System Workbench "restores" the correct capacity.

0690X000008icmvQAA.png

In trying to repeat the steps that caused the problem, I think I have it figured out. The jumpers on the ST-Link don't seem to matter. If I am only using USB power, I can't get it to happen. I have to have the jumper on the E5V setting. The USB connected before external power enumerates badly and reports wrong disk size. I did try completely powering down and back up again in the correct sequence before posting but it didn't work. This condition is even noted in the Nucleo User Guide. Perhaps there is a state where the computer kept the bad information since, like you said, Mac's don't like disk drive disappearing. Either way, I can repeat the issue now and recover in one of the two methods.

Thanks for the help!

Terms & ConditionsAccessibility statement