STM32G0 Bootloader antwortet nicht

[Moot S. (mootseeker)]

Hallo Zusammen,

ich versuche aktuell bei einem STM32G031 über den internen Bootloader 
von ST eine Firmware hochzuladen. Das Problem ist, dass wenn ich in 
meiner Applikation zum Bootloader springe erhalte ich auf meine Anfrage 
(0x7F) keine Antwort.

Bevor ich euch meinen Code zeige und wir an der falschen stelle suchen, 
ist meine Frage: In der AN2606 steht, dass der interne Bootloader USART1 
& USART2 verwenden kann, werden dann auch beide Schnittstellen 
initialisiert und warten auf die Anfrage der Software?

Wenn nicht kann man das einstellen?

Ich kommuniziere über die Schnittstelle USART1 und sende den Befehl 0x7F 
damit sollte der STM die Baudrate automatisch einstellen und eine 
Antwort senden. Wenn ich das mit dem Logic Analyzer anschaue (Bild im 
Anhang), dann sehe ich meinen Befehl erhalte vom STM aber keine Antwort.

[Monk (roehrmond)]

Moot S. schrieb:
> werden dann auch beide Schnittstellen
> initialisiert und warten auf die Anfrage der Software?

Ja werden sie. Damit das funktioniert, muss du an der nicht genutzen 
Schnittstelle für einen sauberen Ruhepegel sorgen, z.B. mit Pull-Up 
Widerständen, falls sich das nicht schon von selbst durch die Schaltung 
ergibt.

[Moot S. (mootseeker)]

Steve van de Grens schrieb:
> Damit das funktioniert, muss du an der nicht genutzen
> Schnittstelle für einen sauberen Ruhepegel sorgen, z.B. mit Pull-Up
> Widerständen, falls sich das nicht schon von selbst durch die Schaltung
> ergibt.

Die USART2 Schnittstelle ist am ST-Link V3 als Debug-Schnittstelle 
angeschlossen (ohne Pull-up). Ich werde mal versuchen diese einzubauen 
und melde mich dann wieder!

[Gerd E. (robberknight)]

Moot S. schrieb:
> Das Problem ist, dass wenn ich in
> meiner Applikation zum Bootloader springe erhalte ich auf meine Anfrage
> (0x7F) keine Antwort.

Du lässt also den STM32 in Deine Applikation starten, entscheidest dort 
daß Du zum Bootloader willst und springst dann explizit dort hin?

Das geht definitiv, man muss dabei aber sehr vorsichtig sein in welchem 
Zustand man den Controller an den Bootloader übergibt. Ich mache das bei 
einem STM32F072 erfolgreich so, aber es hat mich ein paar Anläufe 
gekostet bis ich die Initialisierung richtig hinbekommen hab.

Ich würde daher erst mal probieren den Controller von sich aus direkt in 
den Bootloader starten zu lassen und zu sehen ob dann die Kommunikation 
funktioniert. Dann kannst Du das Problem besser eingrenzen. Ich glaube 
beim STM32G031 muss man erst spezielle Config-Flags setzen damit er ein 
BOOT-Pin auswertet, bei den F0 war das extern BOOT-Pin immer aktiv.

[Moot S. (mootseeker)]

Gerd E. schrieb:
> Du lässt also den STM32 in Deine Applikation starten, entscheidest dort
> daß Du zum Bootloader willst und springst dann explizit dort hin?

Genau ich Starte in meine Applikation. In der Applikation wartet der 
Kontroller auf einen Befehl den ich über die USART-Schnittstelle sende 
(Der Befehl ist z.B. "Firmware Update"). Empfange ich diesen Befehl 
Schalte ich alle Peripherien des Kontrollers aus und Springe in den 
Bootloader.

Gerd E. schrieb:
> Ich glaube
> beim STM32G031 muss man erst spezielle Config-Flags setzen damit er ein
> BOOT-Pin auswertet, bei den F0 war das extern BOOT-Pin immer aktiv.

Wenn ich das richtig verstanden habe ist der Boot0 Pin beim G0 auf dem 
gleichen Pin wie der SWCLK Pin. Ich habe an diesem Pin mit einer 
Lötbrücke und einem Pull-down Widerstand schon mal vorgesehen, dass man 
den Pin manuell runterziehen könnte (Siehe Anhang).

Wenn ich aus der Applikation in den Bootloader springe ist dann der 
Zustand des Boot0 Pins nicht egal? Ich dachte das ist nur relevant beim 
Aufstarten?

[Malte _. (malte)]

Moot S. schrieb:
> Wenn ich aus der Applikation in den Bootloader springe ist dann der
> Zustand des Boot0 Pins nicht egal? Ich dachte das ist nur relevant beim
> Aufstarten?
Ich würde erwarten, dass der Pin per Software im Bootloader augewertet 
wird. Im Zweifelsfall also nicht.

Was mir noch bei diversen Beispielen wie man aus einer Applikation in 
den Bootloader spring (zb:
https://stm32f4-discovery.net/2017/04/tutorial-jump-system-memory-software-stm32/
)
aufgefallen ist: Sie funktionieren nicht mit der Optimierung Os! Warum? 
Weil der Compiler dann zwischen __set_msp und Bootloader Anspringen den 
Stack nochmal bearbeitet (Ja das darf er) und dass dann schief geht.

System Takt richtig eingestellt? Meine Routine für einen STM32L452 sieht 
wie folgt aus:

void McuStartOtherProgram(void * startAddress, bool ledSignalling) {
  volatile uint32_t * pStackTop = (uint32_t *)(startAddress);
  volatile uint32_t * pProgramStart = (uint32_t *)(startAddress + 0x4);
  if (ledSignalling) {
    Led2Green();
  }
  __HAL_FLASH_INSTRUCTION_CACHE_DISABLE();
  __HAL_FLASH_DATA_CACHE_DISABLE();
  __HAL_FLASH_PREFETCH_BUFFER_DISABLE();
  McuClockToMsi(4000000, RCC_HCLK_DIV1);
  HAL_RCC_DeInit();
  SysTick->CTRL = 0;
  SysTick->LOAD = 0;
  SysTick->VAL = 0;
  __disable_irq();
  __DSB();
  __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();
  __DSB();
  __ISB();
  __HAL_RCC_SPI1_FORCE_RESET();
  __HAL_RCC_SPI2_FORCE_RESET();
  __HAL_RCC_SPI3_FORCE_RESET();
  __HAL_RCC_USART1_FORCE_RESET();
  __HAL_RCC_USART2_FORCE_RESET();
  __HAL_RCC_USART3_FORCE_RESET();
  __HAL_RCC_USB_FORCE_RESET();
  __HAL_RCC_SPI1_RELEASE_RESET();
  __HAL_RCC_SPI2_RELEASE_RESET();
  __HAL_RCC_SPI3_RELEASE_RESET();
  __HAL_RCC_USART1_RELEASE_RESET();
  __HAL_RCC_USART2_RELEASE_RESET();
  __HAL_RCC_USART3_RELEASE_RESET();
  __HAL_RCC_USB_RELEASE_RESET();
  //Is there a generic maximum interrupt number defined somewhere?
  for (uint32_t i = 0; i <= I2C4_ER_IRQn; i++) {
    NVIC_DisableIRQ(i);
    NVIC_ClearPendingIRQ(i);
  }
  __enable_irq(); //actually, the system seems to start with enabled interrupts
  if (ledSignalling) {
    Led1Off();
  }
  /* Writing the stack change as C code is a bad idea, because the compiler
     can insert stack changeing code before the function call. And in fact, it
     does with some optimization. So
         __set_MSP(*pStackTop);
         ptrFunction_t * pDfu = (ptrFunction_t *)(*pProgramStart);
         pDfu();
     would work with -Og optimization, but not with -Os optimization.
     Instead we use two commands of assembly, where the compiler can't add code
     inbetween.
*/
  asm("msr msp, %[newStack]\n bx %[newProg]"
       : : [newStack]"r"(*pStackTop), [newProg]"r"(*pProgramStart));
}

[Moot S. (mootseeker)]

Malte _. schrieb:
> Sie funktionieren nicht mit der Optimierung Os! Warum?
> Weil der Compiler dann zwischen __set_msp und Bootloader Anspringen den
> Stack nochmal bearbeitet (Ja das darf er) und dass dann schief geht.

Optimierung habe ich auf -O0 eingestellt. Liegt somit nicht am Kompiler.

Malte _. schrieb:
> System Takt richtig eingestellt?

Wo finde ich den wie ich den einstellen muss? Ich habe in meiner 
applikation nur die RCC ausgeschalten bzw. deinitialisiert.

Da ich mit der LL-Library arbeite sieht meine Funktion wie folgt aus:

#define STM32G031_SYSTEM_MEM_ADDR ( 0x1FFF0000 )

typedef void (*pFunction)(void);

//..................................................................
/**
 * @brief  Firmware Update
 * @note   Update myself :)
 * @param  none
 * @retval none
 */
void fw_update( void )
{
  // Local variables
  uint32_t JumpAddress;

  pFunction Jump_To_Application;

// ---------- Start Firmware Update ----------
  // Deinit peripherals
  usart_deinit(USART1);
  usart_deinit(USART2);
  spi_deinit( SPI1 );
  LL_CRC_DeInit(CRC);
  
    // Fully reset RCC to power-up state
    LL_RCC_DeInit();

  // Disable interrupt requests from periperals
  NVIC_DisableIRQ(SysTick_IRQn);
  NVIC_DisableIRQ(USART1_IRQn);
  NVIC_DisableIRQ(USART2_IRQn);
  NVIC_DisableIRQ(SPI1_IRQn);

    // Zero out SysTick
    SysTick->CTRL = 0;
    SysTick->LOAD = 0;
    SysTick->VAL = 0;

  // Disable global interrupts
  __disable_irq();

    // Remap memory to system flash
    SYSCFG->CFGR1 = SYSCFG_CFGR1_MEM_MODE_0;

    jumpAddress = *(__IO uint32_t *) (STM32G031_SYSTEM_MEM_ADDR + 4);
    JumpToApplication = (pFunction) jumpAddress;

  // Prepare MCU to jump
  __set_MSP(*(__IO uint32_t*) STM32G031_SYSTEM_MEM_ADDR);

  //Jump to application
  JumpToApplication();

  //Never reach this
  __builtin_unreachable( );
}

[Μαtthias W. (matthias)]

Hi

Ich mach das auch. Das einfachste ist du setzt dir einen Marker der den 
Reset übersteht (z.B. an einer reservierten Adresse im RAM oder in einem 
RTC Register). Dann löst du einen Reset aus (z.B. per Watchdog) und 
schaust direkt nach dem Start (vor jeder Initialisierung) nach ob der 
Reset vom Watchdog kommt und ob dein Marker entsprechend gesetzt ist und 
springst dann den internen Bootloader an. Dann kannst du nichts 
vergessen was für den Bootloader rückgängig gemacht werden muss. Wenn du 
generierten Code verwendest musst du halt aufpassen das da nicht vorher 
schon was läuft wie z.B. ein clock init.

Matthias

[Moot S. (mootseeker)]

Μαtthias W. schrieb:
> direkt nach dem Start (vor jeder Initialisierung)

Ich hab zum Testen den Sprung direkt nach dem Aufstarten gemacht, aber 
ich erhalte keine Antwort vom Bootloader.

Was ich auch noch gemacht habe, ist den Jumper zwischen dem Boot0 
Widerstand den dem SWCLK zu schliessen, das hat aber auch keinen 
einfluss auf die Antwort.

[Μαtthias W. (matthias)]

Welche Baudrate verwendest du denn? Beim L431 hatte ich die Erfahrung 
gemacht das mehr als 19200 nicht stabil funktioniert hat.

Siehe auch meine Supportanfrage
https://community.st.com/s/question/0D53W00000bdFpMSAU/serial-bootloader-baudrate-mismatch

Auf den Supportcase denn ich zusätzlich eröffnet hatte kam leider nichts 
brauchbares zurück.

[Malte _. (malte)]

Bei deinem Code fallen mir zwei Dinge auf:

NVIC_DisableIRQ(SysTick_IRQn);

Entfernen, da:
https://community.arm.com/support-forums/f/armds-forum/2367/nvic_xxx-function-is-not-doing-the-inteded-job
Deaktivieren tust du den danach ja schon mit Systick->CTRL = 0.
Ich bin da auch drauf reingefallen.

__disable_irq();

Ich musste die IRQs aktivieren, bevor ich zum Bootloader gesprungen 
bin, damit es klappt.

Zu den Takt: Das müsste irgendwo im Datenblatt stehen, mit welchem 
Standardtakt der hochstartet. Bei meinem halt der MSI, ich vermute bei 
allen ohne MSI ist es der HSI ohne PLL.

[Moot S. (mootseeker)]

Μαtthias W. schrieb:
> Welche Baudrate verwendest du denn?

Ich verwende 115200 Baud, sollte ja Grundsätzlich kein Problem sein, 
nach AN2602 geht auch noch schneller.

Malte _. schrieb:
> Ich musste die IRQs aktivieren, bevor ich zum Bootloader gesprungen
> bin, damit es klappt.

Ja kann ich auch mal versuchen, aber warum ist das so? Man sollte sie ja 
eigentlich ausschalten damit man fokussiert and den richtigen Punkt 
springen kann?

[Uwe B. (Firma: TU Darmstadt) (uwebonnes)]

Vergesst die ganze De/Re-Initialisierung, setzt einen Merker, macht eine 
Reset und schaut beim Start auf den Merker. Einen Reset koennt Ihr auch 
direkt ausloesen NVIC_SystemReset(), es braucht nicht den Watchdog oder 
aehnliches.

[Μαtthias W. (matthias)]

NVIC_SystemReset() ist nicht bei jeder CortexM Implementierung 
gleichwertig mit einem Watchdog Reset. Z.T. wird Peripherie durch den 
nvic reset nicht zurückgesetzt. Deswegen hab ich mir den Weg über den 
Watchdog angewöhnt. Kann aber nicht mehr sagen ob da die stm32 auch dazu 
gehören.

Moot S. schrieb:
> Ich verwende 115200 Baud, sollte ja Grundsätzlich kein Problem sein,
> nach AN2602 geht auch noch schneller.

Ich kann aus Erfahrung mit ein paar tausend l431 sagen daß es nicht so 
ist :-). Der scheint die Baudrate nicht exakt genug auszumessen. Evtl. 
ist das auch Chargenabhängig da die Prototypen das Verhalten nicht 
zeigten. Ein f091 auf dem gleichen Board ist auch nicht betroffen. Mann 
musste das ROM Mal durch den disassambler jagen. Allein die Zeit mir 
fehlt. AN5067 ist auch ganz spannend da der interne bootloader mit dem 
HSI/MSI läuft.

Matthias

[Moot S. (mootseeker)]

Uwe B. schrieb:
> setzt einen Merker, macht eine
> Reset und schaut beim Start auf den Merker. Einen Reset koennt Ihr auch
> direkt ausloesen NVIC_SystemReset(), es braucht nicht den Watchdog oder
> aehnliches.

Wie schon geschrieben, habe ich das auch schon versucht:

Moot S. schrieb:
> Ich hab zum Testen den Sprung direkt nach dem Aufstarten gemacht, aber
> ich erhalte keine Antwort vom Bootloader.

funktioniert nicht.

Μαtthias W. schrieb:
> AN5067 ist auch ganz spannend da der interne bootloader mit dem
> HSI/MSI läuft.

Ja sieht spannend aus, aber meine Applikation funktioniert ja auch mit 
der HSI Clock und 115200 Baud, warum sollte dann der Bootloader nicht 
funktionieren?


Könnte es sein, dass die Sprungadresse falsch ist, ich verwende für den 
G031 0x1FFF0000?

[Μαtthias W. (matthias)]

Kommst du denn per Bootpin in den Bootloader? Pattern 11 (AN2606) 
erfüllt? Adresse sollte stimmen.

Matthias

[Malte _. (malte)]

Du müsstest doch herausfinden

Moot S. schrieb:
> Ja kann ich auch mal versuchen, aber warum ist das so? Man sollte sie ja
> eigentlich ausschalten damit man fokussiert and den richtigen Punkt
> springen kann?
Das Warum muss dir ST beantworten :)

Was du noch überprüfen kannst ist, ob du ihn überhaupt richtig 
anspringst. Ich hab die Erfahrung gemacht, dass der manche der SPI 
Schnittstellen auf Slave schaltet und dann den MISO Pin auf High zieht. 
(Recht lästig wenn man das in der Schaltung nicht beachtet). Aber hier 
solltest du das messen können.

[Bauform B. (bauformb)]

Ältere Versionen des Bootloaders hatten ein kleines Problem, AN2606 
schreibt:

Known limitations:
Issue is seen for all packages (except SO8, no PA3 pin),
if PA3 stays to low level, system is stuck in the USART2
detection sequence and no other interface is detected.

Μαtthias W. schrieb:
> Welche Baudrate verwendest du denn? Beim L431 hatte ich die Erfahrung
> gemacht das mehr als 19200 nicht stabil funktioniert hat.

Moot S. schrieb:
> Ich verwende 115200 Baud, sollte ja Grundsätzlich kein Problem sein,
> nach AN2602 geht auch noch schneller.

Μαtthias W. schrieb:
> Der scheint die Baudrate nicht exakt genug auszumessen.

Der G031 läuft mit 24MHz und benutzt den SYSTICK für die Autobaud-Mimik. 
Bei höheren Baudraten und/oder niedrigerem Takt wird die Auflösung der 
Messung immer schlechter. Du solltest es auf jeden Fall mit 9600 
probieren.

[Uwe Bonnes (Gast)]

Mαtthias W. schrieb:
> NVIC_SystemReset() ist nicht bei jeder CortexM Implementierung
> gleichwertig mit einem Watchdog Reset.

Dann ist die Implemetierung krank. Es gibt teilweise auch einen Core 
Reset mittels des SCS_DEMCR_VC_CORERESET Bits. Aber NVIC_SystemReset() 
macht laut Definition einen vollstaendigen Reset und bei STM32 ist es 
auch so.