Bootloader damaged when using streaming.cpp

Development environment specific, Arduino, Eclipse, VS2013,Em::Blocks etc
JohnO
Posts: 37
Joined: Wed Feb 17, 2016 8:56 pm

Bootloader damaged when using streaming.cpp

Post by JohnO » Sun May 07, 2017 4:19 pm

I tried to run some example code from [here](https://github.com/JChristensen/extEEPR ... eepromTest) . The example includes some Serial code from [here](http://arduiniana.org/libraries/streaming/). Loading the example into a STM32F103C8T6 went fine but the bootloader didn't enumerate after the USB reset. Power cycle and still no joy. Attempting to reload the bootloader failed as the device wasn't recognised using STLink and BMP. Boot0 was the route to get the bootloader reloaded and a repeat of above when the sketch was loaded. After removing the *streaming <<* references the example loaded and operated fine.

I haven't seen stream before and it appears quite useful except for its impact on the bootloader. Does anyone have any pointers I might look into to get to the bottom of the issue?

stevestrong
Posts: 1743
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Bootloader damaged when using streaming.cpp

Post by stevestrong » Sun May 07, 2017 4:25 pm

You can generate a map file and examine it.

JohnO
Posts: 37
Joined: Wed Feb 17, 2016 8:56 pm

Re: Bootloader damaged when using streaming.cpp

Post by JohnO » Sun May 07, 2017 5:37 pm

https://pastebin.com/r0JaupQi

I'll examine it now.

ag123
Posts: 767
Joined: Thu Jul 21, 2016 4:24 pm

Re: Bootloader damaged when using streaming.cpp

Post by ag123 » Sun May 07, 2017 6:01 pm

there is (only) 20k of ram on the stm32f103, hence when trying out perhaps some fancy c++ stuff, it's possibly good to keep it in mind, i.e. ram is scarce, but nevertheless, it could be something else that cause it to fail rather than simply running out of memory :lol:

stevestrong
Posts: 1743
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Bootloader damaged when using streaming.cpp

Post by stevestrong » Sun May 07, 2017 6:08 pm

To analyze map file you can use this link from Daniel: http://danieleff.com/stm32/map_analizer/
or download AMap.

JohnO
Posts: 37
Joined: Wed Feb 17, 2016 8:56 pm

Re: Bootloader damaged when using streaming.cpp

Post by JohnO » Sun May 07, 2017 8:10 pm

2937 used / 20480 total RAM
16137 used / 122880 total FLASH

JohnO
Posts: 37
Joined: Wed Feb 17, 2016 8:56 pm

Re: Bootloader damaged when using streaming.cpp

Post by JohnO » Sat May 20, 2017 3:26 pm

I wonder if I came make the bootloader area read only.

ag123
Posts: 767
Joined: Thu Jul 21, 2016 4:24 pm

Re: Bootloader damaged when using streaming.cpp

Post by ag123 » Sat May 20, 2017 6:57 pm

just some thoughts, check your ld scripts, look inside the file e.g. did you use bootloader_20.ld? in arduino ide, this probably relates to selecting the 'bootloader version'
and for uart / jtag / swd (st-link) installs, check the *install address* or perhaps the correct ld script used. i think some installers probably use the elf addresses which basically originate in the ld scripts itself. i.e. the ld scripts is used to build the elf file (hence would have the ld script addresses), then when you install the file specifying the elf file, that address (which is the same as that in the ld script used) is where the sketch / binary gets installed.

Code: Select all

/*
 * libmaple linker script for "Flash" builds.
 *
 * A Flash build puts .text (and .rodata) in Flash, and
 * .data/.bss/heap (of course) in SRAM, but offsets the sections by
 * enough space to store the Maple bootloader, which lives in low
 * Flash and uses low memory.
 */

/*
 * This pulls in the appropriate MEMORY declaration from the right
 * subdirectory of stm32/mem/ (the environment must call ld with the
 * right include directory flags to make this happen). Boards can also
 * use this file to use any of libmaple's memory-related hooks (like
 * where the heap should live).
 */
MEMORY
{
  ram (rwx) : ORIGIN = 0x20000000, LENGTH = 20K
  rom (rx)  : ORIGIN = 0x08002000, LENGTH = 120K
}

/* Provide memory region aliases for common.inc */
REGION_ALIAS("REGION_TEXT", rom);
REGION_ALIAS("REGION_DATA", ram);
REGION_ALIAS("REGION_BSS", ram);
REGION_ALIAS("REGION_RODATA", rom);

/* Let common.inc handle the real work. */
INCLUDE common.inc
i'd think installing via *dfu* with the stm32duino boot loader 0x8002000 or maple boot loader 0x8005000 probably is 'quite safe'. those boot loaders probably install the sketch at the specific addresses given
but if things like jtag/swd (st-link dongles), uart boot loader is used, my thoughts are that it may just be possible to write the sketch at 0x8000000 overwriting the bootloader itself. do note that some of the st 'discovery' and 'nucleo' boards has an on-board st-link and use that to install the sketches, those has 'all the power' same as those of 'jtag/swd' programmers

accordingly writing to internal flash starting from 0x8000000 isn't as simple as setting a pointer there and set its value, working with the flash controller using some special purpose registers is needed. hence, it would seem unlikely that a 'normal' program can do that
http://www.st.com/resource/en/programmi ... 283419.pdf
http://micromouseusa.com/?p=606

User avatar
Rick Kimball
Posts: 1038
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Bootloader damaged when using streaming.cpp

Post by Rick Kimball » Sat May 20, 2017 9:11 pm

ag123 wrote:there is (only) 20k of ram on the stm32f103, hence when trying out perhaps some fancy c++ stuff, it's possibly good to keep it in mind, i.e. ram is scarce, but nevertheless, it could be something else that cause it to fail rather than simply running out of memory :lol:
The Streaming.h file is a bunch of c++ templates that don't take up any more code space than using discrete print statements.

I compiled the code below to test this out. Using Streaming.h, it produces a smaller .elf file 15192 bytes vs 15232 using Print statements. I loaded up the generic_boot20_pc13.bin file onto my stm32f103c8t6 blue pill to check out the problem with the bootloader. I ran a test with normal print statements and then a try with the Streaming operator overload version. Both work fine, neither affected the boot loader.

I'm on linux, so one thing I had to add was a udev statement for the 1eaf:003 device. Without it, the dfu failed. Might be something to look at if you are using linux. Also, after I loaded a new sketch it didn't seem to re-enumerate the USB device, so I just pushed the physical reset button and it then created the maple serial device.

Code: Select all

#include "Streaming/Streaming.h"

static const bool USE_STREAMING = true;

void setup() {
  //Initialize USBSerial and wait for port to open:
  Serial.begin();
  
  while (!Serial) { ; }
  while (!Serial.isConnected() ) { ; }

  if ( USE_STREAMING ) {
    Serial << "ASCII Table ~ Character Map" << endl;
  }
  else {
    // prints title with ending line break
    Serial.println("ASCII Table ~ Character Map");
  }
}

// first visible ASCIIcharacter '!' is number 33:
int thisByte = 33;

void loop() {
  if ( USE_STREAMING ) {
    Serial << (char)thisByte
           << ", dec: " << _DEC(thisByte)
           << ", hex: " << _HEX(thisByte)
           << ", oct: " << _OCT(thisByte)
           << ", bin: " << _BIN(thisByte)
           << endl;
  }
  else {
    Serial.write((char)thisByte);
    Serial.print(", dec: ");
    Serial.print(thisByte, DEC);
    Serial.print(", hex: ");
    Serial.print(thisByte, HEX);
    Serial.print(", oct: ");
    Serial.print(thisByte, OCT);
    Serial.print(", bin: ");
    Serial.println(thisByte, BIN);
  }

  if (thisByte == 126) {    // you could also use if (thisByte == '~') {
    // This loop loops forever and does nothing
    while (true) {
      continue;
    }
  }
  // go on to the next character
  thisByte++;
}
Last edited by Rick Kimball on Sun May 21, 2017 11:09 am, edited 1 time in total.
-rick

zmemw16
Posts: 1449
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: Bootloader damaged when using streaming.cpp

Post by zmemw16 » Sat May 20, 2017 9:22 pm

if this is programming from the ide with a st-link ?
could you try this ?
connect another serial device, serial-usb block, another micro, even a nano :)
select it in the port monitor
program the maple mini via st-link, does it now re-enumerate?
stephen

Post Reply