Forum: Mikrocontroller und Digitale Elektronik STM32U599 reagiert nicht: Keine Funktion auf dem Custom Board


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Anatol G. (tola511)


Lesenswert?

Hallo Leute,

ich besitze ein Custom Board mit dem neuen U599ZJT6Q LQFP144 und habe 
testweise einen GPIO auf den Startpegel HIGH gesetzt. In einer 
while-Schleife toggelt dieser Pin jede Sekunde. Das Programm wird 
erfolgreich auf den Chip geladen, was im CubeProgrammer ersichtlich ist. 
Allerdings bleibt der Pin auf LOW und es findet keine Schaltung statt. 
Ich habe ebenfalls den Boot0 auf den Flashspeicher eingestellt. 
Zusätzlich habe ich sowohl den internen Oszillator als auch einen 
externen Oszillator ausprobiert, jedoch ohne Erfolg. Hat jemand eine 
Idee, woran es liegen könnte, dass der Chip überhaupt nicht reagiert?

von Sebastian R. (sebastian_r569)


Lesenswert?

Entweder Code Zeile 42 oder das Problem in deiner Schaltung auf Seite 
42.
Könnte auch sein, dass R42 falsch gelötet ist.

von Wastl (hartundweichware)


Lesenswert?

Anatol G. schrieb:
> Hat jemand eine
> Idee, woran es liegen könnte, dass der Chip überhaupt nicht reagiert?

Da wirst du uns etwas mehr zeigen müssen als nur blumige Worte
zu deiner Software. Schaltplan und Minimal-Programm zum Nach-
vollziehen deines Problem wäre das Mindeste. Auch das
"Custom Board" macht den unwissenden Beobachter erst mal
nachdenklich und mistrauisch .... das ist bis jetzt nur
Herumstochern im Nebel.

von Anatol G. (tola511)


Angehängte Dateien:

Lesenswert?

stimmt

von Wastl (hartundweichware)


Lesenswert?

Deine Test Pins kann ich im Schaltplan nicht finden. Vielleicht
ist es noch zu früh am Morgen.
1
  while (1)
2
  {
3
    printf("Hello world");
4
    HAL_GPIO_WritePin(test2_GPIO_Port, test_Pin, GPIO_PIN_SET);
5
    HAL_Delay(1000);
6
    HAL_GPIO_WritePin(test2_GPIO_Port, test_Pin, GPIO_PIN_RESET);
7
    HAL_Delay(1000);
8
    /* USER CODE END WHILE */
9
  }

Hier beschreibst du <test2_GPIO_Port> aber benutzt <test_Pin>.
Soll das so sein? Also 2 vs. "nicht 2"?

Es fehlt die *.h Datei (Definition der Ports und Pins, üblicher-
weise main.h) die das klären könnte.

von Anatol G. (tola511)


Angehängte Dateien:

Lesenswert?

Ach ja stimmt, weil ich erst einen anderen GPIO genutzt habe und dann 
einfach eine 2 hintendran gehängt habe. Ich habe es eben geändert, aber 
das war natürlich nicht das Problem. Wie gesagt, der Pin müsste schon 
beim Starten auf HIGH sein, aber so ist es nicht.


Test2 = PA3 (CS-SPI2)

: Bearbeitet durch User
von Wastl (hartundweichware)


Lesenswert?

Anatol G. schrieb:
> Wie gesagt der Pin müsste
> schon beim Starten auf HIGH sein, aber so ist es nicht.

Dann bräuchten wir noch dein *.ioc File.

von Anatol G. (tola511)


Angehängte Dateien:

Lesenswert?

Kein problem

von Andreas B. (abm)


Lesenswert?

Nun ja, über SWD/JTAG kann man ja auch Single-Stepping machen. Man 
könnte ja mal vom Reset ab schauen, was passiert ...
Es soll sogar so etwas wie Breakpoints geben.

von Wastl (hartundweichware)


Lesenswert?

Anatol G. schrieb:
> Only_GPIO_2.ioc

Sorry kann leider nicht weiter mitreden. Meine CubeMX Version
ist zu alt und ich kann momentan aus verschiedenen Gründen
nicht updaten.

Vermutet hätte ich noch einen Fehler in der Clock-Konfiguration,
kann das aber wie gesagt nicht überprüfen.

Beitrag #7428197 wurde vom Autor gelöscht.
von Wastl (hartundweichware)


Lesenswert?

Anatol G. schrieb im Beitrag #7428197:
> mit step into komme ich bis zu diesem code und bei timeout-- hänge ich
> fest.

Dann liegt dein Problem ja ganz woanders, nicht bei den I/O
Funktionen die du Eingangs erwähnt hast.

von Wastl (hartundweichware)


Lesenswert?

.... und schon wieder gelöscht?

von Monk (roehrmond)


Lesenswert?

Wastl schrieb:
> mit step into komme ich bis zu diesem code und bei timeout-- hänge ich
> fest.

Das ist schwer nachvollziehbar, denn "timeout" kommt in deinem Quelltext 
nicht vor.

Führe das Programm schrittweise aus, eine Funktion nach der anderen 
(Step over), um zu sehen, welche hängt oder abbricht.

Dann machst du das nochmal, gehst aber in die problematische Funktion 
rein (Step into). Bis du die Zeile(n) gefunden hast, die das Problem 
auslöst. Berichte, was du gefunden hast.

von Anatol G. (tola511)


Angehängte Dateien:

Lesenswert?

Hier bin ich über step-into stehen geblieben und habe die while schleife 
ausgeblendet. dann schaltet er zumindest auf HIGH
1
void Error_Handler(void)
2
{
3
  /* USER CODE BEGIN Error_Handler_Debug */
4
  /* User can add his own implementation to report the HAL error return state */
5
  __disable_irq();
6
//  while (1)
7
//  {
8
//  }
9
  /* USER CODE END Error_Handler_Debug */
10
}

dann bleibe ich aber im HAL_GetTick stecken beim aufrufen vom Delay
1
__weak uint32_t HAL_GetTick(void)
2
{
3
  return uwTick;
4
}

von Monk (roehrmond)


Lesenswert?

Kontrolliere man, ob die Flash_Latency zur CPU Taktfrequenz passt.

von Anatol G. (tola511)


Lesenswert?

Steve van de Grens schrieb:
> Kontrolliere man, ob die Flash_Latency zur CPU Taktfrequenz passt.

Wo finde ich das?

von Monk (roehrmond)


Lesenswert?

Anatol G. schrieb:
> Wo finde ich das?

In deinem Quelltext und im Reference manual.

> HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_1)

https://www.st.com/resource/en/reference_manual/rm0456-stm32u5-series-armbased-32bit-mcus-stmicroelectronics.pdf 
(Kapitel 7.3.3)

Oh, ich sehe gerade dass bei diesem Modell auch eine "latency" für das 
RAM eingestellt werden muss (Kapitel 6.3.4). Das scheint in deinem 
Quelltext zu fehlen.

: Bearbeitet durch User
von Wastl (hartundweichware)


Lesenswert?

Steve van de Grens schrieb:
> Oh, ich sehe gerade dass bei diesem Modell auch eine "latency" für das
> RAM eingestellt werden muss (Kapitel 6.3.4). Das scheint in deinem
> Quelltext zu fehlen.

Deswegen sollte man sich ja mal das *.ioc mit CubeMX anschauen ....

von Anatol G. (tola511)


Angehängte Dateien:

Lesenswert?

Der HCLK steht auch auf 16Mhz

von Anatol G. (tola511)


Angehängte Dateien:

Lesenswert?

Also verstehe ich das richtig den SRAM1 auf wait state 0 einstellen?

von Monk (roehrmond)


Lesenswert?

Für "wait state 0" hat CubeMX wohl keinen Code generiert, weil das die 
Standardvorgabe ist.

Und FLASH_LATENCY_1 passt wohl denn du nutzt "Vcore range 4" mit 16 MHz.

Die Latencies sind dann wohl nicht deine Problemursache. Ich hatte 
darauf getippt, weil das bei meinen ersten Versuchen (mit anderen STM32 
Modellen) oft der Knackpunkt war, wenn das Programm ein Stück weit 
erfolgreich lief und dann plötzlich abbrach oder andere Fehlfunktionen 
zeigte.

: Bearbeitet durch User
von Anatol G. (tola511)


Angehängte Dateien:

Lesenswert?

Also Ziel, mit dem Chip ist es primär einen 800x480px Display zu 
betreiben (ohne touch). Habe nun den Code neu gemacht, nur mit dem LTDC 
und Touchgfx.
Ich habe wieder die eine while-schleife herausgenommen und der Display 
leuchtet weiß. Also die zugehörigen IOs werden geschaltet (im touchgfx 
habe ich einen roten Hintergrund mit einem blauen Button in der Mitte).

inzwischnen bleibe ich im code hier hängen:
1
/**
2
  * @brief This function handles Hard fault interrupt.
3
  */
4
void HardFault_Handler(void)
5
{
6
  /* USER CODE BEGIN HardFault_IRQn 0 */
7
8
  /* USER CODE END HardFault_IRQn 0 */
9
  while (1)
10
  {
11
    /* USER CODE BEGIN W1_HardFault_IRQn 0 */
12
    /* USER CODE END W1_HardFault_IRQn 0 */
13
  }
14
}
Also ich hatte mal das F746 board mit touchgfx hinbekommen(youtube: How 
to integrate TouchGFX in a custom board (The long way round)), aber da 
war der Code noch so das man den Task Manuel einfügen musste. Beim neun 
Chip habe ich das so verstanden, dass das automatisch geht, aber leider 
zeigt dieser nicht an. Muss ich den Task doch irgendwie starten?

: Bearbeitet durch User
von Anatol G. (tola511)


Lesenswert?

Update!

Ich habe jetzt den PIN PA3 eine LED angeschlossen und im Model.cpp diese 
jede Sekunde toggeln lassen. Das funktioniert also der TouchGFX Task 
läuft.
Aber das Display bleibt weiß

Display: https://cdn-shop.adafruit.com/product-files/2354/Datasheet+.pdf

außerdem habe ich die NVIC Prioritäten, Timings und co wie beim U5A9J 
Board eingestellt.

von Florian L. (muut) Benutzerseite


Lesenswert?

Muss VDD11 nicht beschaltet werden? Sieht komisch aus, wenn nicht mal 
Blockkondensatoren dran sind.

von Anatol G. (tola511)


Lesenswert?

VDD11 ist nur für USB und DSI zuständig.

Ich hatte aber noch einen Fehler der Display on/off mus auf HIGH. Jetzt 
ist es richtig, dass die Hintergrundbeleuchtung an ist und das Display 
schwarz ist. Leider zeigt das Display immer noch nicht an, was ich im 
touchgfx eingestellt habe (roter Hintergrund)

von Florian L. (muut) Benutzerseite


Lesenswert?

Bist du dir da sicher? Laut Power supply sheme im Datenblatt auf Seite 
178 ist VDD11 auch die corespannung. Diese kann entweder über einen smps 
oder einen ldo generiert werden. Blockkondensatoren werden bei beiden 
Varianten empfohlen.

von Anatol G. (tola511)


Lesenswert?

Also, ich hatte Kontakt mit ST, und sie sagten mir, dass es kein Problem 
sein sollte, wenn ich den LDO nutze. Letztendlich lag das Problem 
sowieso an etwas anderem. Es ist frustrierend, dass die 
Display-Hersteller so zurückhaltend sind, wenn es um ihre Datenblätter 
geht. Ich habe das falsche Display erhalten, da es zwei verschiedene 
Bezeichnungen auf dem Display gibt. Vielen Dank für eure Hilfe. 
Übrigens, ich konnte die While-Schleife wieder einfügen, da sie keine 
Auswirkungen hatte.

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.