Hallo zusammen, ich lass mir mit CubeMx die Initialisierung für einen STM32L476 für USART2+3,ADC,TIM7,SPI1,DAC,RTC zusammenbauen. Bei Verwendung der SWO (ITM) Schnittstelle für Debug Funktionen, klappt das nur, wenn ich MX_SPI1_Init nicht ausführe. Nehme ich SPI2 klappt alles. Hat sonst jemand schon mal einen solchen Effekt gehabt ? Gruß Schorsch Allen Elektronikbegeisterten einen schönen Anfang für 2017 und viele schöne Projekte.
Da würde ich spontan im Datenblatt nach den Pinbelegungen schauen, ob es da eine Doppelbelegung mit den Debug oder SWO Pins gibt. In dem Fall würde das Umschalten der Pinfunktion die Debug Schnittstelle deaktivieren.
Gast
#4846479
Jim M. schrieb: > Da würde ich spontan im Datenblatt nach den Pinbelegungen schauen, ob es > da eine Doppelbelegung mit den Debug oder SWO Pins gibt. Das spuckt Cube eigentlich doch schon aus.
Gast
#4846492
@Schorsch, häng mal deine *.ioc Datei an.
Nach langem hin und her, sieht es so aus, als würde bei der Port Initialisierung für den SPI was schief laufden. Lass ich "zu Fuß geändert" den SPI zuerst initialisieren, dann erst die anderen Teile, dann klappt es. Sehr seltsam. Anbei die .ioc Datei.
Gast
#4847919
Moin, wohin hast Du den SPI1_CS gelegt? CubeMX kennt den erst mal nicht. Wird der später richtig definiert?
Im Moment hab ich dafür noch keinen Port. Den wollte ich später festlegen, wenn die anderen Schnittstellen alle definiert sind. Ist das ein Problem ?
Gast
#4847922
Das weiß ich leider nicht, habe immer alles komplett erstellt. Leg doch einfach temporär ein Pin fest und probier es aus.
Gast
#4847937
PB3 = SPI1_SCK = SWO könnte das Problem sein.
hp-freund schrieb: > PB3 = SPI1_SCK = SWO > > könnte das Problem sein. Hallo hp-freund, vielen herzlichen Dank für die Idee. Das war es wohl. Ich hab den PA5 (ist auf dem Nucleo Board die LED) freigegeben für SCK1 und jetzt tut das Ganze. Ist wohl manchmal die Sache mit den Bäumen und dem Wald. nochmals vielen, vielen Dank für die tolle Hilfe. Ein (oder auch mehrere) Schoppen stehen hier bereit für Dich. :-) Schorsch
Gast
#4848103
Hallo Schorsch, Die CubeMx libs initialisieren die spi bei Erstverwendung. Also nicht bei xxx_init sondern erst bei xxx_write. Da kann es passieren, dass die Polarität des clock Signals genau noch falsch ist. Ich finde das Init-VerhLten von der CubeMx falsch. Mein workaround ist gleich nach der Initialisierung ein Dummy Write zu machen, damit sich das clock Signal wie erwartet einstellt. Grüße, Adib.
Hi Adib, vielen Dank für den Tip. Ich werd wohl die SPI erst komplett in Betrieb nehmen, wenn mein Board fertig ist. Da hängen DAC7750 dran. Das ist mir für´s Basteln zu fummelig. Man ist ja nicht mehr der Jüngste und da wollen die Augen nicht mehr so gut. Die CubeMX Geschicht ist i.a. recht einfach und komfortabel, aber eben immer mal wieder irgendwelche "Besonderheiten". Hast du die USB MX Software mal am laufen gehabt ? Alle Gute Schorsch
Gast
#4848852
Schorsch X. schrieb: > Die CubeMX Geschicht ist i.a. recht einfach und komfortabel, aber eben > immer mal wieder irgendwelche "Besonderheiten". Na ja, eigentlich ist das schon in Ordnung, wenn man dann auch die gesamte Verwaltung CubeMX überlässt. Wichtig finde ich auch das man später noch mal CubeMX aufrufen kann um Änderungen vorzunehmen. Hast zwar nicht mich gefragt, aber USB CDC erfordert nach Einrichtung durch CubeMX nur noch das Einfügen von 4 Zeilen in die main.c und schon sendet der STM32 über CDC. Zum Empfang muss eigentlich auch nur eine Funktion angepasst werden. Windows braucht allerdings noch den CDC Treiber, Linux nicht.
Hallo hp-Freund , ich hab selbstredenend einen jeden gemeint, der meine Zeilen wohlwollend zu sich nimmt :-). Ich werde mir das mal anschauen. Bisher hab ich zumeist USB über FTDI Bausteine gemacht, weil das den geringsten Aufwand bedeutete. Sowas wie FT230X oder FT232R sind bei meinen kleinen Stückzahlen meist die preiswertere Lösung als tagelang in unbekannten USB Treibern zu wühlen. Bisher hat mir die CUBEMX Software schon recht gut geholfen. noch frohes Schaffen Schorsch