Forum: Mikrocontroller und Digitale Elektronik CAN Bootloader mit STM32F103VC oder STM32F105VC


von Bernd (Gast)


Lesenswert?

Hallo Forum,

ich möchte einen STM32 Controller einsetzen und von der Ausstattung ist 
wohl ein STM32F103RC oder VC gut geeignet. Vermutlich passt der VC 
(LQFP100) besser, da mehr Freiheitsgrade bei den mehrfachbelegten 
Pinfunktionen.
Da beide zur High-density performance line gehören, sollte ein 
selbstgeschriebener Bootloader für beide gleich sein (z.B. bezüglich 
page size).

In der Anwendung werde ich einen CAN Bootloader brauchen, der ohne 
Zugriff auf den Boot0-Pin funktioniert. Der Bootloader soll angesprungen 
werden, wenn an 4 Adresseingängen (einfache DINs) ein bestimmtes Muster 
anliegt.
Alternativ kann der Bootloader auch auf FW warten, wenn entsprechendes 
Muster erkannt wurde. Ein Sprung aus der Applikation wäre aber schöner, 
da universeller.

Der integrierte Bootloader des F103xx kann von Haus aus nur UART.
Es ist aber doch prinzipiell möglich einen Bootloader für CAN zu 
schreiben, der sich auch über obige Bedingung anspringen lässt, oder?

Alternativ passt auch der STM32F105VC, bei dem der integrierte 
Bootloader laut Datenblatt auch über CAN2 funktionieren soll. Dieser ist 
nur minimal teurer und würde mir ggf. das Problem mit dem Bootloader 
abnehmen.
Dazu habe ich 2 Fragen:
1) kennt jemand dazu schon eine fertige PC Anwendung? (der STM Flash 
Loader Demonstrator kann nur UART)
2) funktioniert es mit dem integrierten Bootloader auch mit dem 
Anspringen aus der normalen Applikation, wenn die Eingänge das richtige 
Muster haben (s.o.)?

Vielen Dank.
Bernd

von Markus A. (Firma: dSys, Ulm) (markusa)


Lesenswert?

Hallo Bernd,

wir haben einen Bootloader für die STM32-Derivate entwickelt, mit 
welchem auch über CAN kommuniziert werden kann. Es ist völlig egal über 
welche Schnittstelle (UART, CAN, Ethernet ...) kommuniziert wird. Auch 
ist es zum Beispiel möglich über einen Knoten von UART nach CAN zu 
routen (wird auch durch den Bootloader erledigt), da das zugrunde 
liegende Protokoll vom Übertragungsmedium unabhängig ist.
Ein "einfangen" des Bootloaders ist während der ersten 500ms nach einem 
Reset möglich. Auch kann der Bootloader direkt aus der Applikation 
heraus (über ein API) gestartet werden. Weitere Informationen sind unter 
http://www.dsys.de/produkte/software/bootloader zu finden.

> Dazu habe ich 2 Fragen:
> 1) kennt jemand dazu schon eine fertige PC Anwendung? (der STM Flash
> Loader Demonstrator kann nur UART)

Passend zum Bootloader gibt es eine PC-Applikation (Linux wie auch 
Windows) mit welcher der Bootloader konfiguriert (z.B. Seriennummer, 
Hardwarestand, Cryptoschlüssel etc.) und auch die Firmware hochgeladen 
werden kann. Bei Bedarf kann der Programmierablauf in der Serie durch 
ein JavaScript-Programm frei gestaltet werden (mit Anbindung an 
Barcodereader und/oder Datenbank).

> 2) funktioniert es mit dem integrierten Bootloader auch mit dem
> Anspringen aus der normalen Applikation, wenn die Eingänge das richtige
> Muster haben (s.o.)?

Mir ist keine Möglichkeit bekannt, den internen (ST-)Bootloader durch 
die Firmware zu starten.

Grüße,
Markus A.

von Pudel (Gast)


Lesenswert?

Poste doch bitte den Quellcode (µC & PC) des Bootloaders.

von tsag (Gast)


Lesenswert?

HAHA, den postet er bestimmt, den Quellcode von seiner kommerziellen 
Software.
Aaaalso Problem bei dem internen Bootloader ist: Feste Baudrate 125 kbps 
und die feste Adresse. Hast du mehrere STM32 an deinem Bus, wollen sie 
alle geflasht werden. Er kann aber soweit ich weiß aus der Software 
aufgerufen werden.
Ich habe mir damals für die Stm32 einen eigenen CAN-Bootloader 
geschrieben. Das ist echt kein Hexenwerk, wenn man einmal weiß wie man 
in dem flash zu schreiben hat. Den Bootloader habe ich denn an die 
resetadresse in den Flash gelegt und die Anwendung weiter "oben" nach 
jedem reset bleibt der µc 500ms im bootloader und wartet auf eine 
Nachricht von der PC-Anwendung. Kommt nichts, wird zur Anwendung 
gesprungen... Aus der Anwendung lässt sich der Bootloader starten indem 
ganz einfach ein softreset ausgeführt wird. Ein Paar Stichworte noch zur 
weiteren Recherche: IAP Vectortable

von Bernd (Gast)


Lesenswert?

Danke für die Antworten.

@Markus: Euer BL hört sich interessant an. Kostenpunkt?
@tsag: Ist dein BL auch ein kommerzielles Produkt?

Prinzipiell würde es mir reichen, wenn man jedes Modul zum Updaten vom 
restlichen CAN Bus separieren muss.
Wichtig ist die Startbedingung für den BL. Nur wenn die Adresseingänge 
ein bestimmtes Muster zeigen. Vorher darf der BL auch keine Bootup 
Nachricht o.ä. senden.

von Markus A. (Firma: dSys, Ulm) (markusa)


Lesenswert?

Hallo Bernd,

dass der Bootloader nur am Bus aktiv wird, wenn ein bestimmtes Bitmuster 
an den Adresseingängen anliegt, lässt sich einrichten ;-) Das Muster 
sowie die zu verwendenden Eingänge sind dann während der Fertigung 
einstellbar. Somit bleibt der Bootloader generisch. Die Programme für 
die Programmierung des Bootloaders sowie Konfiguration (Produktion), für 
die Updates (im Feld) und die Verschlüsselung der Firmware (Entwicklung) 
sind im Bootloader-Paket mit dabei.
Genaueres sowie Preise gerne unter infoATdsysDOTde

von Random .. (thorstendb) Benutzerseite


Lesenswert?

Hi,

ein eigener Bootloader auf einem Cortex-M3 ist nicht schwer, wenn man 
die Peripherals bedienen kann.

Was fehlt, ist die "Magic" (hier für armcc). Das Programm, welches 
geflasht wird, ist in meinem Beispiel auch standalone lauffähig. Es hat 
ein eigenes Startup, Vectortable etc.
Wie man das Flash schreibt, steht im Manual (oder in meinem Fall im 
Source der MDK-ARM Flash Algs).

Dieser Bootloader wird an den Flash Anfang geschrieben, und läuft immer 
vor der Firmware an. So kann auch ein fehlerhaftes Update der Firmware 
(z.B. Stromausfall) einfach erneut erfolgen. Weiterhin könnte man die 
Firmware im Flash auf Gültigkeit checken, bevor sie gestartet wird (für 
den Fall eines fehlgeschlagenen Updates).

Die kommentierten Zeilen sind nur ggf. noptwendig.
1
#define NVIC_VectTab_FLASH       0x90000     // Base Address of Firmware Binary
2
#define SP_OFFS                     0
3
#define RESET_OFFS                  4
4
5
6
void main()
7
{
8
  void (*user_code_entry)(void);
9
  register uint32_t MSP __ASM("msp");
10
11
  if(DoFirmwareUpdate()) {
12
    // Check Firmware update (SD-Card, USB, Ethernet, whatever) and decrypt / write to Flash
13
    // ...
14
  }
15
16
  //__disable_irq();
17
  //__DSB();
18
  //__ISB();
19
  SCB->VTOR       = NVIC_VectTab_FLASH;
20
  user_code_entry = (void (*)(void))(( *((unsigned int *)(NVIC_VectTab_FLASH + RESET_OFFS))) );
21
  MSP             = *((unsigned int *)(NVIC_VectTab_FLASH + SP_OFFS));
22
  //__DSB();
23
  //__ISB();
24
25
  user_code_entry();
26
27
  while(1); //never reach this...
28
}

VG,
/th.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.