NUCLEO STM32F767ZI: ich bekomme den OTG_FS_IRQHandler() nicht zum Laufen

[Frank B. (fbergemann)]

Anhand von 
http://evenlund.blogspot.com/2016/10/usb-storage-with-stm32f4-discovery-and_58.html 
und https://www.youtube.com/watch?v=uIOb5sSFyUY habe ich versucht, dass 
USB OTG FS (Host) zum Laufen zu bekommen.
Aber es kommen keine Aufrufe von OTG_FS_IRQHandler(). Die scheinen mir 
aber die treibende Kraft für die USB HOST MSD State Machine zu sein(?)

Die Settings im *.ioc file sehen ok aus. Allerdings ist bei den NVIC 
settings der "USB On The GO FS global interrupts" zwar angewählt, aber 
in grau und nicht in blau angezeigt(?!)

siehe:
https://github.com/FBergemann/STM32-FreeRTOS-Framework/tree/dev-usb-host-msd.

Ich wollte am Anfang erst mal nur die State-Changes weiter propagieren 
nach 
https://github.com/FBergemann/STM32-FreeRTOS-Framework/blob/dev-usb-host-msd/User/UserSrc/Tasks/TaskUSB/TaskUSB.c 
und entsprechend auf der Console loggen. Aber das geht wg. o.g. 
fehlenden Aufruf von OTG_FS_IRQHandler() nicht.

???

[Frank B. (fbergemann)]

VBUS läuft bei mir nicht.

Bei einem Referenz-Projekt funktioniert es - mit denselben Jumper 
Settings auf dem Board (daran kann es also nicht liegen). Leider 
verwendet das Referenz-Projekt kein *.ioc - so dass ich auf der Ebene 
nicht vergleichen kann.

Ist folgender code in 
https://github.com/FBergemann/STM32-FreeRTOS-Framework/blob/dev-usb-host-msd/USB_HOST/Target/usbh_conf.c 
nicht falsch?

 #79   GPIO_InitStruct.Pin = USB_VBUS_Pin;
 #80   GPIO_InitStruct.Mode = GPIO_MODE_INPUT;
 #81   GPIO_InitStruct.Pull = GPIO_NOPULL;
 #82   HAL_GPIO_Init(USB_VBUS_GPIO_Port, &GPIO_InitStruct);

Das muss doch GPIO_MODE_OUTPUT sein - oder?

Mir ist auch das Zusammenspiel (Abhängigkeiten) zwischen PA9 und PG6 & 
PG7 nicht klar. Da werde ich aus dem Datenblatt nicht schlau.

Und der im Kapitel "6.10 USB OTG FS or device" 
(https://www.st.com/resource/en/user_manual/dm00244518-stm32-nucleo144-boards-mb1137-stmicroelectronics.pdf) 
referenzierte JP4 taucht in "Figure 4. Top Layout" gar nicht auf(?)

[Frank B. (fbergemann)]

Ich verstehe das nicht.

Ich habe im "Device Configuration Tool" für USB_HOST unter "Platform 
Settings" gesetzt "Drive_VBUS_FS | GIO:Ouput | PG6".

Dennoch wird der PG6 nicht in usbh_conf.c initialisiert.

Im Referenzprojekt FatFs_USBDisk gibt's dafür in usbh_conf.c

  /* Configure POWER_SWITCH IO pin */
  GPIO_InitStruct.Pin = GPIO_PIN_6;
  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
  GPIO_InitStruct.Pull = GPIO_NOPULL;
  HAL_GPIO_Init(GPIOG, &GPIO_InitStruct);

Warum fehlt das im generierten Code von 
https://github.com/FBergemann/STM32-FreeRTOS-Framework/tree/dev-usb-host-msd 
?

[Frank B. (fbergemann)]

Da war ein Fehler im generierten Code:

/**
  * @brief  Drive VBUS.
  * @param  state : VBUS state
  *          This parameter can be one of the these values:
  *           - 1 : VBUS Active
  *           - 0 : VBUS Inactive
  */
void MX_DriverVbusFS(uint8_t state)
{
  uint8_t data = state;
  /* USER CODE BEGIN PREPARE_GPIO_DATA_VBUS_FS */
  if(state == 0) /* invertiert - falsch! */
  {
    /* Drive high Charge pump */
    data = GPIO_PIN_SET;
  }
  else
  {
    /* Drive low Charge pump */
    data = GPIO_PIN_RESET;
  }
  /* USER CODE END PREPARE_GPIO_DATA_VBUS_FS */
  HAL_GPIO_WritePin(GPIOG,GPIO_PIN_6,(GPIO_PinState)data);
}

Das ist auch hier schon falsch:
plugins/com.st.stm32cube.common.mx_6.2.1.202103241236/db/templates/usbh_ 
platform_c.ftl

-> https://github.com/STMicroelectronics/STM32CubeF7/issues/46

[m.n. (Gast)]

Und, bleibt Dir ein mulmiges Gefühl im Bauch?
Glücklicherweise ist Dir die Fehlfunktion ja aufgefallen, da die 
erwartete Reaktion vom Programm nicht stattfand.
Der Cube-Code ist wohl nie richtig getestet worden.

[Frank B. (fbergemann)]

> Und, bleibt Dir ein mulmiges Gefühl im Bauch?

So ganz wohl ist mir dabei nicht, weil ich nicht weiss, was da noch 
alles für Fehler drin schlummern.

Der User USB port wird jetzt mit Spannung versorgt (ok).

Wenn ich einen USB Stick einstecke, dann lande ich auch in dem von

USBH_StatusTypeDef  USBH_Init(USBH_HandleTypeDef *phost,
                              void (*pUsrFunc)(USBH_HandleTypeDef *phost,
                              uint8_t id), uint8_t id)

erzeugtem thread USBH_Process_OS (ok).

#143  phost->thread = osThreadNew(USBH_Process_OS, phost, &USBH_Thread_Atrr);

Und zwar in USBH_Process_OS() sogar bis zu USBH_Process() hier:

static void USBH_Process_OS(void *argument)
{
  osStatus_t status;

  for (;;)
  {
    status = osMessageQueueGet(((USBH_HandleTypeDef *)argument)->os_event,
                               &((USBH_HandleTypeDef *)argument)->os_msg,
                               NULL, osWaitForever);
    if (status == osOK)
    {
      USBH_Process((USBH_HandleTypeDef *)argument);
    }
  }
}

D.h. auch der vorangegange osMessageQueueGet(..) funktioniert.

Aber in USBH_Process(..) steigt er hier aus

#479        USBH_LL_ResetPort(phost);

Bzw konkret etwas tiefer dann hier (LOC #1579):

HAL_StatusTypeDef USB_ResetPort(USB_OTG_GlobalTypeDef *USBx)
{
       uint32_t USBx_BASE = (uint32_t)USBx;

       __IO uint32_t hprt0 = 0U;

       hprt0 = USBx_HPRT0;

       hprt0 &= ~(USB_OTG_HPRT_PENA | USB_OTG_HPRT_PCDET |
                  USB_OTG_HPRT_PENCHNG | USB_OTG_HPRT_POCCHNG);

       USBx_HPRT0 = (USB_OTG_HPRT_PRST | hprt0);
       HAL_Delay(100U);                                 /* See Note #1 */
       USBx_HPRT0 = ((~USB_OTG_HPRT_PRST) & hprt0);
#1579  HAL_Delay(10U);     

       return HAL_OK;
}

Zu einem breakpoint NACH dem HAL_Delay(10U) komme ich nicht mehr.

Stattdessen lande ich dann als nächstes wieder in meinem breakpoint auf 
Zeile #232 hier:

/**
  * @brief This function handles USB On The Go FS global interrupt.
  */
void OTG_FS_IRQHandler(void)
{
      /* USER CODE BEGIN OTG_FS_IRQn 0 */

      /* USER CODE END OTG_FS_IRQn 0 */
#232  HAL_HCD_IRQHandler(&hhcd_USB_OTG_FS);
      /* USER CODE BEGIN OTG_FS_IRQn 1 */

      /* USER CODE END OTG_FS_IRQn 1 */
}

Und der backtrace sagt:

Thread #1 [main] 1 [core: 0] (Suspended : Breakpoint)  
  OTG_FS_IRQHandler() at stm32f7xx_it.c:232 0x8000e00  
  <signal handler called>() at 0xfffffffd  
  prvPortStartFirstTask() at port.c:261 0x800dbf8  
  xPortStartScheduler() at port.c:367 0x800dcd0

Das liegt vermutlich am FreeRTOS scheduling wegen des 
'HAL_Delay(10U)'(?)

Wenn ich nun im Debugger auf "play" drücke lande ich bei einem 
HardFault_Handler():

Thread #1 [main] 1 [core: 0] (Suspended : Signal : SIGTRAP:Trace/breakpoint trap)  
  HardFault_Handler() at stm32f7xx_it.c:92 0x8000d82  
  <signal handler called>() at 0xfffffff1  
  HAL_TIM_IRQHandler() at stm32f7xx_hal_tim.c:3,744 0x8005088  
  TIM1_UP_TIM10_IRQHandler() at stm32f7xx_it.c:190 0x8000dc6  
  <signal handler called>() at 0xfffffff1  
  memcpy() at 0x800efae  
  prvCopyDataToQueue() at queue.c:2,098 0x800c0fe  
  xQueueGenericSendFromISR() at queue.c:1,001 0x800b9a8  
  osMessageQueuePut() at cmsis_os2.c:1,667 0x800b008  
  USBH_LL_PortEnabled() at usbh_core.c:1,204 0x80099da  
  HAL_HCD_PortEnabled_Callback() at usbh_conf.c:181 0x800e520  
  HCD_Port_IRQHandler() at stm32f7xx_hal_hcd.c:1,695 0x80037c6  
  HAL_HCD_IRQHandler() at stm32f7xx_hal_hcd.c:554 0x8002310  
  OTG_FS_IRQHandler() at stm32f7xx_it.c:232 0x8000e06  
  <signal handler called>() at 0xfffffffd  
  prvPortStartFirstTask() at port.c:261 0x800dbf8  
  xPortStartScheduler() at port.c:367 0x800dcd0

Spass geht anders :-)

[Frank B. (fbergemann)]

Könnte das ein stacksize Problem sein?
Ich habe entsprechend der Anleitung 
http://evenlund.blogspot.com/2016/10/usb-storage-with-stm32f4-discovery-and_58.html 
im "Project Manager" gesetzt:

Minimum Heap Size = 0x400
Minimum Stack Size = 0x800

Aber ich verwende FreeRTOS. Da muss ich vielleicht dafür auch noch mal 
den Stack Size hochschrauben(?)

Denn hier habe ich nur (usbh_conf.h):

#if (USBH_USE_OS == 1)
  #include "cmsis_os.h"
  #define USBH_PROCESS_PRIO          osPriorityNormal
  #define USBH_PROCESS_STACK_SIZE    ((uint16_t)128)
#endif /* (USBH_USE_OS == 1) */

[Frank B. (fbergemann)]

> Und, bleibt Dir ein mulmiges Gefühl im Bauch?

Also dafür, dass ich gerade erst mit dem STM32 angefangen habe, komme 
ich gar nicht mal so schlecht damit zurecht - trotz der ganzen 
Widrigkeiten :-)

Es **war** der stacksize für den USB_HOST.

Das nächste issue: 
https://github.com/STMicroelectronics/STM32CubeF7/issues/47

[Frank B. (fbergemann)]

Das ist echt hartes Brot :-)

Jetzt hänge ich in einer Schleife hier:

Thread #1 [main] 1 [core: 0] (Suspended : Step)  
  USBH_MSC_Read() at usbh_msc.c:780 0x8008114  
  USBH_read() at usbh_diskio.c:116 0x800735e  
  disk_read() at diskio.c:82 0x800a974  
  move_window() at ff.c:925 0x800b002  
  check_fs() at ff.c:2,971 0x800be18  
  find_volume() at ff.c:3,050 0x800bf8a  
  f_open() at ff.c:3,328 0x800c4d4  
  Ready() at TaskUSB.c:106 0x80117aa  
  TaskUSB_Run() at TaskUSB.c:69 0x8011734  
  pxPortInitialiseStack() at port.c:208 0x8010370

in der loop auf Zeile #25

USBH_StatusTypeDef USBH_MSC_Read(USBH_HandleTypeDef *phost,
                                 uint8_t lun,
                                 uint32_t address,
                                 uint8_t *pbuf,
                                 uint32_t length)
{
  uint32_t timeout;
  MSC_HandleTypeDef *MSC_Handle = (MSC_HandleTypeDef *) phost->pActiveClass->pData;

  if ((phost->device.is_connected == 0U) ||
      (phost->gState != HOST_CLASS) ||
      (MSC_Handle->unit[lun].state != MSC_IDLE))
  {
    return  USBH_FAIL;
  }

  MSC_Handle->state = MSC_READ;
  MSC_Handle->unit[lun].state = MSC_READ;
  MSC_Handle->rw_lun = lun;

  USBH_MSC_SCSI_Read(phost, lun, address, pbuf, length);

  timeout = phost->Timer;

  while (USBH_MSC_RdWrProcess(phost, lun) == USBH_BUSY)  
  {
    if (((phost->Timer - timeout) > (10000U * length)) || (phost->device.is_connected == 0U))
    {
      MSC_Handle->state = MSC_IDLE;
      return USBH_FAIL;
    }
  }
  MSC_Handle->state = MSC_IDLE;

  return USBH_OK;
}

Dasselbe Problem, das jmd. anderes hier hat: 
https://community.st.com/s/question/0D50X00009Xkeg0/stm32l476-usbotg-fatfs-freertos

Ich komme nicht aus dem Zustand USBH_BUSY heraus.

OMG:
https://community.st.com/s/question/0D50X0000CErb5RSQR/usb-host-library-is-not-thread-safe
https://www.freertos.org/FreeRTOS_Support_Forum_Archive/September_2015/freertos_STM32F429Discovery_with_STM32Cube_USB_fatfs_and_FreeRTOS_14fb7b28j.html

[m.n. (Gast)]

Frank B. schrieb:
> Das ist echt hartes Brot :-)
>
> Jetzt hänge ich in einer Schleife hier:

Das ist der Preis, den man für's Zusammenklicken bezahlen muß.
Aber solange Du nicht am Baum hängst ... ;-)

[Frank B. (fbergemann)]

Was meinst Du mit "Zusammenklicken"?
Würde es Deiner Meinung nach funktionieren, wenn man manuell FreeRTOS, 
USB Host MSD und FatFS integriert? - auf Basis der vorhandenen 
BiBliotheken?
Oder sind die Libraries einfach (noch) nicht aufeinander abgestimmt. Und 
muss man dann alle Libraries knicken und komplett low-level alles 
selber machen?

Der link hier: 
https://community.st.com/s/question/0D50X0000CErb5RSQR/usb-host-library-is-not-thread-safe

Verweist weiter auf: 
https://community.st.com/s/question/0D50X0000C5Tns8SQC/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe

Und das klingt so, als ob FreeRTOS noch nicht sauber von HAL unterstützt 
wird.

Oder irre ich mich hier?

[Frank B. (fbergemann)]

Äh, ... wie sind denn die Aussichten für Korrekturen und Pflege der 
Integration mit FreeRTOS in Anbetracht von: 
Beitrag "STMicroelectronics: Azure RTOS im Fokus"

[m.n. (Gast)]

Frank B. schrieb:
> Was meinst Du mit "Zusammenklicken"?

Das bezog sich primär auf die Verwendung von CubeMX. Man klickt die 
Funktionen wie gewünscht an und erwartet, daß ein funktionierendes 
Programm geliefert wird: kann sein - muß aber nicht, wie man auch in 
diesem Forum an verschiedenen Stellen nachlesen kann.

Frank B. schrieb:
> Oder sind die Libraries einfach (noch) nicht aufeinander abgestimmt.

Wer soll das "Abstimmen" der LIBs denn leisten? Gut ist, wenn man 
passenden Code findet. Wenn es nicht passt, ist es Deine Aufgabe.

> Und
> muss man dann alle Libraries knicken und komplett low-level alles
> selber machen?

Bei komplexeren Funktionen wie USB kann das sehr aufwendig werden, 
entweder eigenen Code zu schreiben oder die Fehler im Fremdcode zu 
finden und beseitigen.
Persönlich brauche ich für meine Anwendungen kein USB, obwohl hier im 
Forum einige Beispiele dafür zu finden wären. Aber was ich brauche, ist 
low-level Programmierung, die die Hardware so verwendet, wie es benötigt 
wird. Daher lese ich das Datenblatt, das Reference-Manual und 
programmiere auf Registerebene. Das dauert anfangs sicherlich länger als 
CubeMX und HAL zu verwenden. Dafür weiß ich aber, wo was und warum 
passiert.

Frank B. schrieb:
> Also dafür, dass ich gerade erst mit dem STM32 angefangen habe, komme
> ich gar nicht mal so schlecht damit zurecht - trotz der ganzen
> Widrigkeiten :-)

Für ein Fazit ist es wohl noch zu früh.

[Frank B. (fbergemann)]

>> Also dafür, dass ich gerade erst mit dem STM32 angefangen habe, komme ich
>> gar nicht mal so schlecht damit zurecht - trotz der ganzen Widrigkeiten :-)

> Für ein Fazit ist es wohl noch zu früh

Lass mich raten: Du bist hauptberuflich Motivationstrainer ;-)

[Johannes S. (Gast)]

ich finde es auch eher erstaunlich wieviel mittlerweile auch an 
Middleware integriert ist. Und für komplexere Schnittstellen wie 
Ethernet oder USB reicht es auch nicht ein paar Seiten Datenblatt zu 
lesen, das war bisher sehr teuer oder es war ein deutlich höherer 
Eigenanteil nötig.
Wie man sieht bearbeitet STM die issues auf Github auch, aber es dauert.
Dazu kommt das der F7/H7 mit seinem Cache und verschieden angebundenen 
Speicher auch sehr komplex ist. Ein Stück Software das heute noch lief 
kann morgen schon crashen wenn durch ein gewachsenes Programm ein Buffer 
von einem Speicher in den anderen rutscht.
Auch ein RTOS mal eben optional einbauen ist gefährlich wenn nicht alle 
Libs dafür entwickelt wurden. Beim Cube generierten Code sehe ich nicht 
das da mit Tests gearbeitet wird, wie z.B. bei einem (RT)OS wie Mbed. Da 
ist es schwer neue Features rein zu bekommen weil alles aufwändig durch 
automatisierte Tests laufen muss.
Die Strategie mit MS ist schon interessant, aber einiges ist ja durch 
den CMSIS Layer für das RTOS abgefangen. Das FreeRTOS wird ja nicht 
einfach verschwinden und auch weiterhin integrierbar sein. Nur eventuell 
durch mehr eigene Handarbeit...

[m.n. (Gast)]

Ich verstehe, Du möchtest meine Kontonummer ;-)

Kleine Geschichte:
Bei einem STM32H723 möchte ich RNG anwerfen, um "saubere" Zufallswerte 
zu erhalten. Beim H750 waren drei Anweisungen notwenig: RCC freigeben, 
Takt auf HSI48 stellen und Enable. Simpel.
Beim H723 versuche ich Gleiches, erhalte ein paar hundert Werte und dann 
bleibt RNG mit Taktfehler hängen.

Testweise CubeMX angeworfen und RNG per HAL starten lassen.
Nach MX_RND_Init() läuft RNG für kurze Zeit und bleibt dann stehen. In 
den Registern steht der gleiche Inhalt wie nach meiner manuellen 
Initialisierung.
Ganz schnell erledigt und wirkungslos ;-)

Auf der HAL-Ebene passiert einiges, was schlecht zu durchschauen ist. 
Dort finde ich keinen richtigen Ansatzpunkt.
Auf Registerebene habe ich zumindest herausgefunden, daß eine Senkung 
der Taktfrequenz RNG weiterlaufen läßt. Fertig bin ich noch nicht. Auf 
der Suche nach "fertigen" Lösungen stoße ich wieder auf dieses 
HAL-Gedöns.

Was ich sagen will: Im Zweifelsfall kommt man nicht umhin, sich im 
Detail mit der Hardware auseinanderzusetzen. Sich hoffnungsvoll auf 
CubeMX+HAL zu verlassen, kann schwer daneben gehen. Wenn noch andere 
Quellen dazukommen, die in einer speziellen Umgebung durchaus stabil 
laufen, kann Debugging schwer bis unmöglich werden.
Glückstreffer Stack vergrößern klappt nicht immer.

@Johannes S.
Hast Du vielleicht eine Lösung für RNG beim H723/H730?
Könnte ja sein, daß Du selbiges Problem schon mal hattest.

[Johannes S. (Gast)]

m.n. schrieb:
> Könnte ja sein, daß Du selbiges Problem schon mal hattest.

nein, habe den TRNG bisher nicht (bewusst) genutzt.
Vielleicht hilft die init Sequenz aus dem Mbed weiter:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/trng_api.c
Auch als Beispiel wie HAL Benutzung für verschiedene Serien sehr 
unterschiedlich ist. Da sollte das funktionieren weil RNG afaik für TLS 
gebraucht wird.

[m.n. (Gast)]

Vielen Dank!
Copyright ist 2006 - 2016 angegeben, wo es schon den H74x/H75x gab aber 
noch nicht die H72x/H73x Version, die deutlich differenzierter 
einstellbar ist. Aber ich werde mich weiter durchhangeln, auch in den 
Bereichen, in denen RNG benötigt wird.

[Frank B. (fbergemann)]

> Sich hoffnungsvoll auf CubeMX+HAL zu verlassen, kann schwer daneben gehen.

Warum verwende ich das framework?

Weil es da ist und dafür gedacht ist, dass man Basis-Funktionalität 
einfach einbindet, verwendet, und sich auf seine eigentliche Applikation 
konzentrieren kann. Und sei es, dass man diesen Weg erst mal nur geht um 
eine sub-optimale Vorab-Lösung zu haben, die funktioniert und mit der 
man die eigentliche Funktionalität erarbeiten kann.
Konkret geht es hier um Logging. Ich will Meßwerte aufnehmen, ggf. 
"Aktoren" ansteuern" und das protokollieren. Dann kann nämlich jemand 
anderes sich diese Messwerte schon mal ansehen und damit arbeiten, 
während ich dann prüfe, ob das Logging vom framework ok ist, oder ob ich 
das noch mal überarbeiten will (tunen, verschlanken, vereinfachen).

Warum verwende ich FreeRTOS?

Weil es eine Möglichkeit ist, Funktionsblöcke gedanklich voneinander zu 
isolieren, getrennt anzugehen, ggf. sogar auf mehrere Leute verteilt 
entwickeln zu lassen. Auch hier: vielleicht nur als Prototyp, um z.B. 
erst mal Messwerte zu erhalten und auswerten zu können. Später mag man 
entscheiden, dass der overhead von FreeRTOS nicht tragbar ist und auf 
eine monolithische Lösung wechseln.

Mit dem Ansatz, FreeRTOS zu wählen kann ich nicht prinzipiell falsch 
liegen, denn sonst gäbe es dieses Produkt nicht.

Der Anspruch Meßwerte sowohl auf die Console als auch - mit höherer 
möglicher Bandbreite - in eine Log-Datei per USB aufzeichnen zu wollen, 
ist auch nicht unsinnig.

Eigentlich würde ich erwarten, dass ST da eine Referenz-Implementierung 
(Beispiele) für Logging mit und ohne FreeRTOS anbietet. Denn es ist 
essential für irgendwelche konkreten Anwendungen, die dem Nutzer da 
vorschweben.

ST verwendet ein Haufen Energie auf sein "Service Creation Tool". Warum 
wird das dann nicht mit einem wirklich bauchbarem Beispiel validiert?

[Frank B. (fbergemann)]

Ich war lange weg vom Thema STM32, will jetzt aber doch noch mal einen 
Anlauf machen. Ich habe damals die STM32CubeIDE v1.6.1 verwendet. Jetzt 
habe ich mir  die aktuelle v1.16.0 installiert. Ich verwende immer noch 
das Board STM32F767ZI.
Damit bin ich jetzt den umgekehrten Weg gegangen und habe das 
funktionierende Demo "FatFs_USBDisk" genommen und die Funktionalität der 
seriellen Console aus einem anderen Projekt da hinein integriert.

Damit bekomme ich auch eine logging Zeile auf der seriellen Console 
angezeigt.
Aber die main() Routine des "FatFs_USBDisk" Demos ruft in einer 
"while(1)" Schleife USBH_Process(...) auf. Und dieser Aufruf kehrt bei 
aktiviertem logging auf der Console nicht mehr zurück.
Ich nehme an, dass da ein Konflikt bei der Verwendung der Resourcen 
vorhanden ist.

In den Sourcen des "FatFs_USBDisk" Demos finde ich in 
Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_rcc.c:

#define MCO1_PIN              GPIO_PIN_8

Und das wird in derselben Datei hier verwendet

void HAL_RCC_MCOConfig(uint32_t RCC_MCOx, uint32_t RCC_MCOSource, uint32_t RCC_MCODiv)
{
  GPIO_InitTypeDef GPIO_InitStruct;
  /* Check the parameters */
  assert_param(IS_RCC_MCO(RCC_MCOx));
  assert_param(IS_RCC_MCODIV(RCC_MCODiv));
  /* RCC_MCO1 */
  if (RCC_MCOx == RCC_MCO1)
  {
    assert_param(IS_RCC_MCO1SOURCE(RCC_MCOSource));

    /* MCO1 Clock Enable */
    MCO1_CLK_ENABLE();

    /* Configure the MCO1 pin in alternate function mode */
    GPIO_InitStruct.Pin = MCO1_PIN;               /* HIER! */
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Alternate = GPIO_AF0_MCO;
    HAL_GPIO_Init(MCO1_GPIO_PORT, &GPIO_InitStruct);

    /* Mask MCO1 and MCO1PRE[2:0] bits then Select MCO1 clock source and prescaler */
    MODIFY_REG(RCC->CFGR, (RCC_CFGR_MCO1 | RCC_CFGR_MCO1PRE), (RCC_MCOSource | RCC_MCODiv));
  }

Der Code, den ich für die serielle Console da mit hinein integriert habe 
verwendet ebenfalls GPIO_PIN_8:

#define STLK_RX_Pin GPIO_PIN_8

hier:

void HAL_UART_MspInit(UART_HandleTypeDef* huart)
{
  GPIO_InitTypeDef GPIO_InitStruct = {0};
  if(huart->Instance==USART3)
  {
  /* USER CODE BEGIN USART3_MspInit 0 */

  /* USER CODE END USART3_MspInit 0 */
    /* Peripheral clock enable */
    __HAL_RCC_USART3_CLK_ENABLE();

    __HAL_RCC_GPIOD_CLK_ENABLE();
    /**USART3 GPIO Configuration
    PD8     ------> USART3_TX
    PD9     ------> USART3_RX
    */
    GPIO_InitStruct.Pin = STLK_RX_Pin|STLK_TX_Pin;      /* HIER! */
    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH;
    GPIO_InitStruct.Alternate = GPIO_AF7_USART3;
    HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

    /* USART3 DMA Init */
    /* USART3_TX Init */
    hdma_usart3_tx.Instance = DMA1_Stream3;
    hdma_usart3_tx.Init.Channel = DMA_CHANNEL_4;
    hdma_usart3_tx.Init.Direction = DMA_MEMORY_TO_PERIPH;
    hdma_usart3_tx.Init.PeriphInc = DMA_PINC_DISABLE;
    hdma_usart3_tx.Init.MemInc = DMA_MINC_ENABLE;
    hdma_usart3_tx.Init.PeriphDataAlignment = DMA_PDATAALIGN_BYTE;
    hdma_usart3_tx.Init.MemDataAlignment = DMA_MDATAALIGN_BYTE;
    hdma_usart3_tx.Init.Mode = DMA_NORMAL;
    hdma_usart3_tx.Init.Priority = DMA_PRIORITY_LOW;
    hdma_usart3_tx.Init.FIFOMode = DMA_FIFOMODE_DISABLE;
    if (HAL_DMA_Init(&hdma_usart3_tx) != HAL_OK)
    {
      Error_Handler();
    }

    __HAL_LINKDMA(huart,hdmatx,hdma_usart3_tx);

    /* USART3 interrupt Init */
    HAL_NVIC_SetPriority(USART3_IRQn, 5, 0);
    HAL_NVIC_EnableIRQ(USART3_IRQn);
  /* USER CODE BEGIN USART3_MspInit 1 */

  /* USER CODE END USART3_MspInit 1 */
  }
}

Das wird vermutlich der Konflikt sein (oder EINER der Konflikte).
Kann man da für die USB Funktionalität oder für die serielle Console auf 
einen anderen PIN zurückgreifen? Oder gibt das Layout des STM32F767ZI 
das nicht her?
Kann man also nur entweder a) auf die Console loggen oder b) auf einen 
USB Stick loggen? Ich hätte gerne die Kombination von beidem.

Das Beispiel-Projekt ist hier:
https://github.com/FBergemann/STM32-USBDiskAndConsole
Bitte wundert euch nicht über die Implementierung für die serielle 
Console. Die ist aus einem anderen Projekt übernommen, das RTOS 
verwendet: https://github.com/FBergemann/STM32-FreeRTOS-Framework

[Frank B. (fbergemann)]

ggf. kann man die RCC für das USB Interface wechseln.
In einer Diskussion im STM32 Forum sieht's so aus als ob es eine 
Alternative gibt: 
https://community.st.com/t5/stm32-mcus-products/setting-mco2-output-on-stm32g0/td-p/119270