Subversion Repositories svn.mios

Rev

Rev 897 | Rev 988 | Go to most recent revision | Details | Compare with Previous | Last modification | View Log | RSS feed

Rev Author Line No. Line
585 tk 1
HEADER 3 MIOS32 Bootloader for Newbies
2
 
3
<H1>MIOS32 Bootloader for Newbies</H1>
4
 
5
<P CLASS=INFO>The MIOS32 Bootloader allows you to upload a MIOS32 application into the internal flash memory of STM32 via USB or UART based MIDI interface.</P>
6
 
7
<P CLASS=DESC>The big advantage of the so called bootstrap method is, that you don't need a programming device like JTAG or a COM port to install or update the software on your MIDIbox. Instead you can buy a preprogrammed STM32F103RE from <A HREF="http://mbhp.avishowtech.com/buy.html" TARGET="_blank">SmashTV</A> (already presoldered on a <A HREF="mbhp_core_stm32.html">MBHP_CORE_STM32 PCB</A>) for a reasonable price, or you can ask a friend or a member of the <A HREF="http://forum.midibox.org" TARGET="_blank">MIDIbox Forum</A> who already owns the equipment for flashing the firmware into the STM32. Details are explained in the <A HREF="mios32_bootstrap_experts.html">Experts Section</A>.</P>
8
 
9
<P CLASS=DESC>The bootloader brings benefit even for people who own this equipment, because the usage is faster and more comfortable; it's possible to upload new code on-the-fly without opening the MIDIbox case or plugging cables within a few number of seconds! Speaking about upload performance: an upload via USB MIDI is usually faster than via JTAG (ca. 13..17 kb/s)!</P>
10
 
11
<P CLASS=DESC>In distance to MIOS8, the bootloader, MIOS32 and the application itself are provided as a single binary. This means: once any application has been flashed into the STM32 chip, the bootloader will be available for future code uploads via MIDI as well.</P>
12
 
13
<H2>Starting the Bootloader</H2>
14
 
15
<P CLASS=DESC>The bootloader is started on each STM32 power-on reset, or during runtime if a special SysEx command is received. It sends an upload request, waits 2 seconds for a response, and thereafter starts the actual application. The temporary activation after power-on is provided as a fallback solution; it allows you to replace a faulty application which hangs up or blocks the MIDI interface.</P>
16
 
17
<P CLASS=DESC>For MBHP_CORE_STM32, upload via common MIDI cables (UART based MIDI interface) plugged into MIDI IN1/OUT1 sockets (UART0 pins A9/A10) is always possible.</P>
18
 
19
<P CLASS=DESC>Upload via USB (the fastest method) requires some special measures, as the USB MIDI device won't be enumerated fast enough by the host operating system (e.g. Windows) after power-on:
20
<UL CLASS=CL>
21
  <LI>upload via USB interface can be started during runtime if the application configured it for MIDI (this is mostly the case) and doesn't crash on incoming MIDI streams (should be mostly the case for released applications)
22
  <LI>if the application uses the USB interface for other purposes (e.g. Virtual COM), or the upload doesn't work for any reason (e.g. due to a bug during program development), jumper J27 (Boot1) can be stuffed on the MBHP_CORE_STM32 module to select Bootloader Hold mode (J23 aka. Boot0 should *not* be stuffed!).<BR>
23
  Thereafter power-cycle the core.<BR>
931 tk 24
  Once in hold mode, a special USB MIDI device will be available (called "MIOS32 Bootloader") to upload code. The application will be started once the jumper has been removed again. It is recommended to power-cycle the core thereafter to get a proper USB connection (under Windows), and to restart MIOS Studio, so that it sees the new USB MIDI port ("MIOS32" instead of "MIOS32 Bootloader").
585 tk 25
  <LI>If the bootloader is running on a STM32 Primer, the Hold mode can be activated by soldering a small cable between the boot1 signal on R48 and Ground as shown <A HREF="">in this picture</A>. However, the Primer contains an integrated debug interface which makes it easy to recover the MIOS32 installation w/o this measure.</UL>
26
</P>
27
 
28
<H2>Code Upload</H2>
29
 
30
<TABLE ALIGN=CENTER CELLSPACING=20 CELLPADDING=0>
31
 
32
  <TR>
897 tk 33
    <TD><A HREF="mios_download.html" TARGET="_blank"><IMG SRC="mios_studio/mios_studio_icon.png" WIDTH=128 HEIGHT=128 ALT="Link to MIOS Studio"></A></TD>
585 tk 34
    <TD><IMG SRC="images/1x1dot.gif" width=10 ALT=""></TD>
897 tk 35
    <TD><SPAN CLASS=NORM> <A HREF="mios_studio.html" TARGET="_blank">Download MIOS Studio</A> - this is a Juce based environment with MIOS specific tools which runs on PCs and Macs.</SPAN></TD>
585 tk 36
  </TR>
37
 
38
</TABLE>
39
 
40
<P CLASS=DESC>If no error has been reported by the upload tool (to ensure this, scroll up the log window and check all status messages), it can be assumed that the application has been installed successfully. Note that it is not possible to run multiple applications in parallel - a new application will always overwrite the old one.</P>
41
 
42
<P CLASS=DESC>Note: if you are using the USB interface under Windows, it is required to restart MIOS Studio whenever the core has been power-cycled, resp. the USB MIDI Device has been enumerated again. You probably know this issue from your other USB MIDI interfaces as well. This measure isn't required when you are using MacOS or Linux.<BR>
588 tk 43
Another typical Windows issue: instead of "MIOS32", the USB device is probably called "Audio Device" or in german "Audioger&auml;t", and you have to close all MIDI applications which could access the same port, as the legacy Microsoft MIDI USB driver isn't multi-client capable (no issue under MacOS/Linux).</P>
585 tk 44
 
45
 
46
<H2>Changing the Device ID</H2>
47
 
48
<P CLASS=DESC>If multiple cores are connected to a single UART based MIDI port in parallel or in a chain, each core should get it's unique device ID, so that MIOS Studio can address the code to the right receiver. In distance to MIOS8, the Device ID is stored in internal flash and doesn't require a special application to change it. Instead, the bootloader provides a special SysEx request:
49
<UL CLASS=CL>
50
  <LI><TT>F0 00 00 7E 32 &lt;current ID&gt; 0C &lt;new ID&gt; F7</TT>
51
</UL>
52
Once received, the core will response with two acknowledge messages - one with the previous, the other with the new ID:
53
<UL CLASS=CL>
54
  <LI><TT>F0 00 00 7E 32 &lt;previous ID&gt; 0F &lt;new ID&gt; F7</TT>
55
  <LI><TT>F0 00 00 7E 32 &lt;new ID&gt; 0F &lt;new ID&gt; F7</TT>
56
</UL>
57
If MIOS32 returns an acknowledge reply with error code 0E (=invalid command):
58
<UL CLASS=CL>
59
  <LI><TT>F0 00 00 7E 32 &lt;current ID&gt; 0E 0E F7</TT>
60
</UL>
61
it means, that the bootloader isn't actively running. Retry to send the SysEx request after power-cycling the core.
62
</P>
63
 
787 tk 64
<P>The bootloader must be in HALT mode (stuff J27 jumper (Boot1) and reboot the core), otherwise the SysEx request will be ignored.</P>
65
 
66
<P>Since STM32 doesn't contain an internal EEPROM, the device ID can only be changed once. Additional attempts will get an error reply. The only way to change it again is to upload the bootloader update package. It will install the bootloader again and reset the device ID to 0x00.</P>
67
 
585 tk 68
<P>Please note that the device ID selected in the MIOS Studio upload window must match with the device ID of the core which should response to the transfer. This means in other words: after the MIOS device ID has been modified, the ID in the upload window has to be changed as well, so that it matches with the new ID value.</P>
69
 
591 tk 70
<P CLASS=DESC>So long you are using an USB interface, or only a single MIDIbox is connected to a UART based MIDI port, it's safe to use device ID 00.</P>
585 tk 71
 
72
 
73
FOOTER