Re: debugging
Holger Mai <[email protected]> Thu, 14 Apr 2016 14:22:27 +0200 (CEST)
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <784434789.433567.5f70218f-0490-498e-bfad-d6a4d2270265.open-xchange@email.1und1.de> |
Hallo Uwe ich verwende OpenSTM32 (Stm32 System Workbench), allerdings als compiler den GCC 5 (wegen Cortex M7), und zum debuggen openOCD wie es von der Workbench mitgebracht wird. Als Interface STLink V2, die V2-1, die ich dahabe, sind alle langsamer, weil auf F0 oder Lxx Nucleos. Das olimex-Board mit dem F7 hat keinen Debugger drauf. Das beschriebene Problem beim single stepping habe ich auch, das geht mir total auf den Senkel, ich habe aber auch noch keine Lösung gefunden. Bis zum F7 habe ich CooCox benutzt, das hatte das Problem nicht. Evtl werde ich mal mit dem Sniffer die Kommunikation zwischen Workbench und Coocox vergleichen, ob sich daraus was ergibt. Kann aber noch dauern, bis ich dazu komme. als kleinen provisorischen Fix zum debuggen nach printf vorübergehend ein NutDelay (100-200ms) einbauen, das wartet, bis alles über die UART raus ist. Die Debug-Ausgabe sollte sowieso mal überarbeitet werden, bei schnellen controllern überholt sich die Ausgabe tw. selbst, d. h. es fehlen Teile oder sind ineinandergewürfelt. Am besten wäre wohl ein kleiner Ringbuffer und eine DMA für die USART (für 32bitter, 8bit kann wohl so bleiben). PS zum DCache: ich arbeite noch mit dem alten Trunk, der 6420 war nicht compilierbar wg. vermutlich noch nicht abgeschlossener Arbeiten im Clock-Management/Initialisierung (jede Menge Fehler dort, fehlende Defines etc.) Ich habe aber an beliebigen Stellen gestoppt und im SCB->CCR nachgesehen, der DCache ist immer aus. Meiner Meinung nach sollte der Cache per Default aus bleiben, und nur in der Applikation und evtl im OS bei Bedarf ganz gezielt eingeschaltet werden, zumindest, bis der OS Code in Bezug auf Caching vollständig überarbeitet und alle möglichen Konfliktstellen entschärft wurden. Wenn man sich die Funktionen zum Steuern der Caches ansieht, benötigen die schon etwas Zeit zur Ausführung, und dann stellt sich die Frage, ob die Risiken bei Cache-Nutzung den Zeitvorteil wettmachen (wenn denn ein solcher überhaupt vorhanden ist) mit freundlichen Grüßen /Best Regards Holger Mai [email protected] GEMAC - Gesellschaft für Mikroelektronik- anwendung Chemnitz mbH Zwickauer Straße 227 D-09116 Chemnitz Tel. +49 371 3377 - 0 Fax +49 371 3377 272 UST-ID: DE140851265 HRB 6443 Chemnitz/Stadt Geschäftsführer: Dirk Hübner / Karsten Grönwoldt http://www.gemac-chemnitz.de _______________________________________________ http://lists.egnite.de/mailman/listinfo/en-nut-discussion