Announcement: there is an English version of this forum on 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?
Entweder Code Zeile 42 oder das Problem in deiner Schaltung auf Seite 42. Könnte auch sein, dass R42 falsch gelötet ist.
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.
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.
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
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.
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.
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.
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.
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.
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 | }
|
Kontrolliere man, ob die Flash_Latency zur CPU Taktfrequenz passt.
Steve van de Grens schrieb: > Kontrolliere man, ob die Flash_Latency zur CPU Taktfrequenz passt. Wo finde ich das?
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
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 ....
Angehängte Dateien:
Der HCLK steht auch auf 16Mhz
Angehängte Dateien:
Also verstehe ich das richtig den SRAM1 auf wait state 0 einstellen?
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
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
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.
Muss VDD11 nicht beschaltet werden? Sieht komisch aus, wenn nicht mal Blockkondensatoren dran sind.
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)
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.