KNX Bootloader für ARM

[Darthyson]

Hi gnampf,

danke für deine Recherchen. Jetzt versteh ich zumindest was und wieso da gemacht wird. Werde die RAM/Vectortable Optimierung allerdings erstmal zurückstellen und weiter machen an der Optimierung des Flashvorgangs. Eine der letzten Änderungen am Bootloader (bevor ich den angefasst hatte) war u.a, dass der eigentliche Flashvorgang asynchron zum Bus gemacht wurde. Vermute man hat dadurch versucht die Timeouts in den Griff zu bekommen, hat bei mir aber mehr zum Problem als zur Lösung geführt, insbesondere da dadurch der Flashvorgang auf eine Zeit verschoben werden konnte, zu der sehr viel Traffic auf dem Bus ist. Wie du schon schreibst, die Datenblöcke werden notfalls wiederholt gesendet, der eigentliche Flashbefehl genau einmal. Scheitert der, scheitert der gesamte Vorgang. Da gibt es sicherlich noch Potential.

Viele Grüße
Denis

[Mirko]

Ich reaktiviere mal hier das Thema aus unserem Chat:

Gibt da aber, glaube ich, noch ein offenes Risiko in der Implementierung von noInterrupts(). Unser M0 hat eine Pipeline, d.h. auch nach Stopp aller ISR ("cpsid i") können noch Kommandos (einer ISR) ausgeführt werden, die auf den Speicher zugreifen, bis die Pipeline leer ist. Folge -> HardFault, wenn der Flash zum Schreiben geblockt ist.
Da sollten noch ein DSB und ein ISB (nach dem noInterrupts() )folgen. Erst dann kann der Flash sicher beschrieben werden.
https://dzone.com/articles/nvic-disabli ... -m-and-the