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?
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.
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.
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.
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.
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.
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 ....
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.
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
voidHardFault_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?
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ß
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.
