<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Bootloader+Flash uVision program for Keil STM32F400 kits</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/30457/bootloader-flash-uvision-program-for-keil-stm32f400-kits</link><description> 
Hi, 
I&amp;#39;m trying to learn more about bootloading and flashing the boot code
for a MCBSTM32F400 kit (Board Eval for STM32F400) and I see that in
the example code there are several uVision projects for other eval
board (such as LPC31xx where as an example</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Bootloader+Flash uVision program for Keil STM32F400 kits</title><link>https://community.arm.com/thread/149487?ContentTypeID=1</link><pubDate>Wed, 09 Oct 2013 08:09:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:276da7bc-c9ff-424d-a9a2-c71c52d09045</guid><dc:creator>Westonsupermare Pier</dc:creator><description>&lt;p&gt;&lt;p&gt;
The System Loader plays no part in picking FLASH/RAM images, there
is no invisible hand, the BOOT0/BOOT1 pins control the device mapped
at address zero, and consequently what takes control of the processor
at reset.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Bootloader+Flash uVision program for Keil STM32F400 kits</title><link>https://community.arm.com/thread/131320?ContentTypeID=1</link><pubDate>Wed, 09 Oct 2013 07:54:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:43652556-301e-4e26-a92b-4325914643de</guid><dc:creator>Dean Hoskins</dc:creator><description>&lt;p&gt;&lt;p&gt;
Westonsupermare Pier,&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m trying to make sense out of the scatter file (.sct) with
regard to the built-in (system) bootloader and how it knows to run
the image from internal flash or internal ram.&lt;/p&gt;

&lt;p&gt;
In the case of internal flash it seems straightforward. The image
is written to 0x08000000 (begin flash area) by the flash code (does
it use the scatter file to know where to write the image?). The
interrupt is set to run on reset at 0x08000000.&lt;/p&gt;

&lt;p&gt;
But in the case of internal RAM, how does the image get to the
correct location. Again I could see the sacatter file being used but
what actually writes the image to RAM, is it some sort of internal
system program that I cant see (is it part of the system bootloader)?
If it is and you want to have your own bootloader boot up, it would
then have to be part of that application. Would it have to use system
calls to write to the internal ram for the STM32F4xxx?&lt;/p&gt;

&lt;p&gt;
With these questoins I&amp;#39;m just trying to tie the bootloader
together with the location of the code (image) and how the image gets
written to the klocation where it is written to.&lt;/p&gt;

&lt;p&gt;
Thanks, Dean&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Bootloader+Flash uVision program for Keil STM32F400 kits</title><link>https://community.arm.com/thread/128328?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2013 19:30:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:231b7e79-0e56-44d9-8878-7bd0e98e9054</guid><dc:creator>Dean Hoskins</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks Westonsupermare Pier,&lt;/p&gt;

&lt;p&gt;
Its making a lot more sense now. As you said if you need to code
your own bootloader it needs to live 0x08000000 so it boots directly
(no system bootloader is used).&lt;/p&gt;

&lt;p&gt;
Thanks, Dean&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Bootloader+Flash uVision program for Keil STM32F400 kits</title><link>https://community.arm.com/thread/120168?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2013 18:36:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:df02b58f-d91b-4d47-bc6b-08a271892cbf</guid><dc:creator>Westonsupermare Pier</dc:creator><description>&lt;p&gt;&lt;p&gt;
You have most of the basic concepts there.&lt;/p&gt;

&lt;p&gt;
The BOOTx pins control if ROM (0x1FFFxxxx), FLASH (0x08000000), or
RAM (0x20000000) get mapped at zero and represent the memory booted
by the processor.&lt;/p&gt;

&lt;p&gt;
The &amp;quot;In System&amp;quot; mode where BOOT0 is High provides a USART(Flash
Demonstrator) and USB(DFU) mechanism to program raw/blank devices.
This is also referred to as the System Loader, and can be used to
unbrick devices&lt;/p&gt;

&lt;p&gt;
To code your own loader you need it to live at 0x08000000, the
first blocks are 16KB, so you could place the app at
0x08004000,0x08008000,.. These small blocks are quicker to erase and
easier to manage, consider placing configuration/calibration data
here if you need that or EEPROM emulation, and pushing out the app to
0x08010000. There is a lot of flexibility here, you just have to
floor-plan the space to meet your needs.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Bootloader+Flash uVision program for Keil STM32F400 kits</title><link>https://community.arm.com/thread/107324?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2013 16:55:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:60c9d531-63f3-4ba8-ba6c-9b2122592087</guid><dc:creator>Dean Hoskins</dc:creator><description>&lt;p&gt;&lt;p&gt;
Hi again Westonsupermare Pier,&lt;/p&gt;

&lt;p&gt;
I looked over the application notes and maybe you could answer a
question for me and see if I understand the idea here. I&amp;#39;ve looked at
the note that covers the usage of the USART for flashing.&lt;/p&gt;

&lt;p&gt;
It looks like there is a built in boot loader at 0x1FFF77DE which
is at the very end of the flash memory. I assume that the chip must
be hard wired to boot from this location which either flashes the
user app (from the KEIL MDK-ARM dev environment) or boots to
0x8000000. So would I be correct the reason the USART application
note you pointed me to puts the flash program at 0x08000000 is that
in actuality the chip boots to 0x1FFF77DE and since nothing is being
flashed it just boots to 0x08000000 where the IAP flash app is
located? Thats why the IAP flash app puts the users code at
0x08004000, because it has to put the flash app someplace and it
would have to be 0x8000000 in order to run the IAP flash app.&lt;/p&gt;

&lt;p&gt;
So in actualy the embedded bootloader runs first, then the IAP
flash app (to allow the user to flash their program). When the
flashing is done and the board is reset the embedded bootload runs
again, passes control to 0x08000000 (IAP) and then on to 0x08004000
(since the user has already done the flashing the users program can
be run).&lt;/p&gt;

&lt;p&gt;
Seems like this works but then our always running 2 bootloaders,
is this true? Is there anyway to flash something directly to
0x08000000 instead of 0x0800400? That would seem cleaner.&lt;/p&gt;

&lt;p&gt;
Not sure if I&amp;#39;m making any sense or not but thats how I&amp;#39;m reading
things in the application notes (and trying to learn).&lt;/p&gt;

&lt;p&gt;
Thanks, Dean&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Bootloader+Flash uVision program for Keil STM32F400 kits</title><link>https://community.arm.com/thread/81477?ContentTypeID=1</link><pubDate>Mon, 07 Oct 2013 15:04:40 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:949ca6ce-0bda-49b0-b0bf-be2cf77fa18c</guid><dc:creator>Dean Hoskins</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks Westonsupermare Pier,&lt;/p&gt;

&lt;p&gt;
I appreciate the response. I&amp;#39;ll look these over and see if I can
use them to write an application program to flash.&lt;br /&gt;
Do you know if there is a risk of &amp;#39;bricking&amp;#39; the eval board or is it
the case that you can always recover (if you follows these
application notes)? In the case of loading the program that does the
flashing, do you have a choice as to where the application (that
flashes) resides in memory, not sure if it resides in RAM or another
section of flash (or is configurable).&lt;/p&gt;

&lt;p&gt;
Thanks, Dean&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>