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

Re: Bootloader damaged when using streaming.cpp

Post by JohnO » Sun May 21, 2017 5:16 pm

Umh, so when I use the example code you supplied it works as I expect and when I run my example code it doesn't. It also screws the BP to prevent the bootloader and also prevents normal, non BOOT0 SWD access.

Could you load up my example code into a BP and check if you still have access to the BP while it is loaded?
Last edited by JohnO on Sun May 21, 2017 5:24 pm, edited 1 time in total.

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

Re: Bootloader damaged when using streaming.cpp

Post by ag123 » Sun May 21, 2017 5:19 pm

if you need debug in your sketch, call enableDebugPorts();
http://www.stm32duino.com/viewtopic.php ... 084#p27916

Code: Select all

enableDebugPorts();
as rick mentioned there is also the define

Code: Select all

 -DCONFIG_MAPLE_MINI_NO_DISABLE_DEBUG 
that you can set during compile to allow debug. e.g. in platforms.txt

1 important thing to take note about debug, i think some ide would *install the sketch* over jtag/swd when you launch debug.
if you are not careful, e.g. an incorrect ld script is used, or that the install address is incorrect, once you launch debug it would *install the sketch at 0x8000000 - start of flash* - overwriting the boot loader

this is not the same sketch that you install over dfu-util say using the arduino ide, if the ide re-install the sketch prior to debug it overwrites that which has been installed using dfu-util (by the arduino ide)
Last edited by ag123 on Sun May 21, 2017 5:41 pm, edited 2 times in total.

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

Re: Bootloader damaged when using streaming.cpp

Post by JohnO » Sun May 21, 2017 5:30 pm

With a clean erase and flash "dfu-util -l" looks like this:

Code: Select all

Johns-MacBook-Pro:~ john$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

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"


when things are flashed with the problem code then "dfu-util -l" looks like this:

Code: Select all

Johns-MacBook-Pro:~ john$ dfu-util -l
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

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"

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

Re: Bootloader damaged when using streaming.cpp

Post by ag123 » Sun May 21, 2017 5:33 pm

you can install a sketch using

Code: Select all

dfu-util -a 2 -R -D sketch.bin
where the -a n corresponds to that alt=n selection from dfu-util -l

take note of my comments on debug sketch install in the prior post, the ide can *overwrite* that install using jtag/swd that you have done using dfu-util
you would either have to select options to avoid installing the sketch during debug or that you would need to make sure that the correct ld script is used to compile the sketch so that the binary offsets away from 0x8000000 start of flash, normally the offset should be 0x8002000 for stm32duino boot loader and 0x8005000 for a stock maple boot loader, you may even need to specify this offset in the IDE so that it install it at the correct install address
Last edited by ag123 on Sun May 21, 2017 5:39 pm, edited 3 times in total.

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 » Sun May 21, 2017 5:35 pm

JohnO wrote:Umh, so when I use the example code you supplied it works as I expect and when I run my example code it doesn't. It also screws the BP to prevent the bootloader and also prevent SWD access.

Could you load up my example code into a BP and check if you still have access to the BP while it is loaded?
I'm guessing it will just fail as I don't have any of those eeprom devices. But in the meantime, I had booted into OS X (I run linux on my iMac) and I don't have a development setup here. FWIW: the bluepill with the ASCIItable code works. I'm running Yosemite. I don't have the lsusb port on OS X I did use the ioreg command to see the Maple device.

If you think the streaming.h is the problem and it works if you change all the << to print() .. why not just go with that? We seem to have proven there doesn't appear to be a problem with the Streaming.h or your MacOS X. The problem child seems to be your code.
Last edited by Rick Kimball on Mon May 22, 2017 2:16 am, edited 1 time in total.
-rick

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

Re: Bootloader damaged when using streaming.cpp

Post by JohnO » Sun May 21, 2017 7:54 pm

Thank you @ag123 and @RickKimball for your help and insight.

@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.

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

Re: Bootloader damaged when using streaming.cpp

Post by ag123 » Mon May 22, 2017 3:11 am

@JohnO
as i do not know about your setup for debug, i'm only guessing that you may be doing debug using a different IDE (e.g. eclipse) or perhaps some scripts or another program. however, do be aware that some of the debug implementations upload the program over jtag/swd just prior to starting debug.

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.

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

Re: Bootloader damaged when using streaming.cpp

Post by JohnO » Mon May 22, 2017 6:59 am

Thanks for sticking with me @ag123. I am not currently using any debug/JTAG equipment. I am quite new to STM32duino and am using Arduino 1.6.12 linked via USB to a BP running the STM32duino bootloader. The bootloader is burned using a clone st-link. I have other equipment including BMP but as yet these have not been brought into play.

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

Re: Bootloader damaged when using streaming.cpp

Post by ag123 » Mon May 22, 2017 12:04 pm

note that st-link is a fully capable jtag/swd debug device, you can setup openocd and gdb and do a full blown jtag/swd debug, including things like flashing any binaries (boot loader or any sketches) at any locations, set breakpoints, examine codes, registers etc
hence be sure u know what you are doing when using st-link ;)

Post Reply