Bootloader damaged when using streaming.cpp

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?

I’ll examine it now.

/*
* 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.
*/

/* Let common.inc handle the real work. */
INCLUDE common.inc


It is possible for the sketch code to overwrite the bootloader, or erase the whole device. The bootloader updater sketch does it.

AFIK, Its not possible to protect against the code erasing its self.

I would recommend you reflash the bootloader, and comfirm it works by loading a blink sketch.

Then read back the bootloader section, and save to file ( using stlink or serial)
Then load the offending code, and run it.

Then readback the bootloader section and do a binary compare, to see if you are corrupting the bootloader and if so, is the whole section now empty.

@RickKimball could you post the exact command you used to burn the bootloader, I have access to st-link and (your) BMP. I did use generic_boot20_pc13.bin from Roger’s repo. I run STM32duino on Mac and *think* I originally burned the bootloader using Win7. I did try it a few times before posting my initial problem.

I had used an stlink to load the bootloader. The location of your stm32duino directory is different adjust for your configuration:

$ /home/kimballr/Arduino/hardware/stm32duino_maple/tools/linux/stlink/st-flash write generic_boot20_pc13.bin 0x08000000

//Test extEEPROM library.
//Writes the EEPROM full of 32-bit integers and reads them back to verify.
//Wire a button from digital pin 6 to ground, this is used as a start button
//so the sketch doesn't do unnecessary EEPROM writes every time it's reset.
//Jack Christensen 09Jul2014

void loop(void)
{
}

Deducing device DFU version from functional descriptor length
Found Runtime: [05ac:821d] ver=0154, devnum=8, cfg=1, intf=3, path="29-3", alt=0, name="UNKNOWN", serial="UNKNOWN"


Bus 020 Device 006: ID 1eaf:0003 1eaf Maple 003 Serial: LLM 003

Bus 000 Device 001: ID 1d6b:IPCI Linux Foundation USB 2.0 Bus
Bus 000 Device 001: ID 1d6b:IPCI Linux Foundation USB 2.0 Bus
Bus 000 Device 001: ID 1d6b:IPPT Linux Foundation USB 3.0 Bus

Could you load up my example code into a BP and check if you still have access to the BP while it is loaded?

Deducing device DFU version from functional descriptor length
Found Runtime: [05ac:821d] ver=0154, devnum=8, cfg=1, intf=3, path="29-3", alt=0, name="UNKNOWN", serial="UNKNOWN"
Found DFU: [1eaf:0003] ver=0201, devnum=28, cfg=1, intf=0, path="20-1", alt=2, name="STM32duino bootloader v1.0 Upload to Flash 0x8002000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=28, cfg=1, intf=0, path="20-1", alt=1, name="STM32duino bootloader v1.0 Upload to Flash 0x8005000", serial="LLM 003"
Found DFU: [1eaf:0003] ver=0201, devnum=28, cfg=1, intf=0, path="20-1", alt=0, name="STM32duino bootloader v1.0 ERROR. Upload to RAM not supported.", serial="LLM 003"


Could you load up my example code into a BP and check if you still have access to the BP while it is loaded?

@ag123 I don’t think I know enough yet to get into the debug options you have highlighted.

@RickKimball I think you have proven the streaming.h and as you say I could bypass the problem. However, I will probably keep gnawing at the issue since I don’t like leaving issues like this to roam free.

this overwrites the sketch installed using dfu-util (by arduino ide).

hence, you need to check your debug setup if you can prevent the sketch install over jtag/swd during debug.
alternatively, you need to set your *install address* for the debug to install the sketch at the correct address e.g. 0x8002000 rather than 0x8000000, if debug install the sketch at 0x8000000 it will simply overwrite the bootloader as well.