Hallo Christian, hallo Oliver,
bei den älteren Projekten mit LPC922 steht nach dem Flashen 15.15.255 als "default" Adresse im Flash. Beim Probrammieren durch die ETS wird die dann entsprechend überschrieben.
Gruß
Hans
ARM-Controller zerschossen?
-
Tontechniker
- Beiträge: 277
- Registriert: 25. Mai 2013, 09:49
- Wohnort: Melsungen/Hessen
Re: ARM-Controller zerschossen?
Hallo Hans,
im Quellcode (lib_lpc922) konnte ich keine Stelle entdecken die einen Default setzt. Ich vermute das EEPROM steht einfach per default auf FF was dann der Adresse 15.15.255 entspricht.
Den Wert 15.15.1 hatte ich mir bei einem Siemens Taster abgeschaut. Ich geh mal die Doku von meinen übrigen Geräten durch (MDT und ABB). Grundsätzlich sollte der Wert wohl per #DEFINE gesetzt werden, dann kann man leicht ändern.
Grüße,
Oliver
im Quellcode (lib_lpc922) konnte ich keine Stelle entdecken die einen Default setzt. Ich vermute das EEPROM steht einfach per default auf FF was dann der Adresse 15.15.255 entspricht.
Den Wert 15.15.1 hatte ich mir bei einem Siemens Taster abgeschaut. Ich geh mal die Doku von meinen übrigen Geräten durch (MDT und ABB). Grundsätzlich sollte der Wert wohl per #DEFINE gesetzt werden, dann kann man leicht ändern.
Grüße,
Oliver
Oliver (ZwergNase)
RasPi 3 mit FT1.2 (ARM und LPC), TPUART, out8-bcu1 (ARM), out-cs-bim112, in8-bcu1 (230V, ARM), Drossel_2TE (nur für Testaufbau)
RasPi 3 mit FT1.2 (ARM und LPC), TPUART, out8-bcu1 (ARM), out-cs-bim112, in8-bcu1 (230V, ARM), Drossel_2TE (nur für Testaufbau)
Re: ARM-Controller zerschossen?
Hallo Christian,
vielen Dank! Leider hatte ich nur einen kompletten out6_cs Autor zur Hand. Zum testen mit der out8 Firmware sollte ich wohl den Controller ohne App verwenden. Dafür fehlt mir aber gerade ein Kabel um den Bus direkt anzuschließen
Aber inzwischen konnte ich die Firmware für out6_cs mit meinem Fix selber kompilieren und das Problem ist wie vermutet behoben. Adresse nach dem Flashen ist 15.15.1. Ich sehe jetzt zu, dass ich einen vernünftigen Pull Request fürs Repo erstelle.
Dockerfile / Slack -> PM
Grüße,
vielen Dank! Leider hatte ich nur einen kompletten out6_cs Autor zur Hand. Zum testen mit der out8 Firmware sollte ich wohl den Controller ohne App verwenden. Dafür fehlt mir aber gerade ein Kabel um den Bus direkt anzuschließen
Aber inzwischen konnte ich die Firmware für out6_cs mit meinem Fix selber kompilieren und das Problem ist wie vermutet behoben. Adresse nach dem Flashen ist 15.15.1. Ich sehe jetzt zu, dass ich einen vernünftigen Pull Request fürs Repo erstelle.
Dockerfile / Slack -> PM
Grüße,
Oliver (ZwergNase)
RasPi 3 mit FT1.2 (ARM und LPC), TPUART, out8-bcu1 (ARM), out-cs-bim112, in8-bcu1 (230V, ARM), Drossel_2TE (nur für Testaufbau)
RasPi 3 mit FT1.2 (ARM und LPC), TPUART, out8-bcu1 (ARM), out-cs-bim112, in8-bcu1 (230V, ARM), Drossel_2TE (nur für Testaufbau)
Re: ARM-Controller zerschossen?
Hallo Oliver,
ich habe es nicht kompilliert bekommen. Kannst du dein Projekt mal bitte zur Verfügung stellen.
LG
Martin
ich habe es nicht kompilliert bekommen. Kannst du dein Projekt mal bitte zur Verfügung stellen.
LG
Martin
-
StefanSverige
- Beiträge: 163
- Registriert: 15. Feb 2014, 13:32
Re: ARM-Controller zerschossen?
Die Sache mit der Default Adresse ist mir beim ARM auch aufgefallen. Die darf nicht 0.0.0 sein, das macht Probleme. Diese Adresse ist eh speziell da sie auch als Weltenkoppler angesehen werden kann. Das wird soweit ich weiß auch unterschiedlich in der ETS gehandlet, je nach Version.
Das leere Geräte 15.15.255 haben kommt aus Urzeiten, da steht dann 0xFF im Speicher. Das habe ich beim LPC mit dem Default Eintrag so umgesetzt. Das braucht auch keinen Speicher im Kontroller, da dies eine Anweisung ist die Adresse in der Hex Datei auf 0xFF zu setzten. Generell sollte man vorsichtig sein wenn man die PA im Kontroller zur Laufzeit verbiegt, es muss sicher gestellt sein das dies nie zufällig passieren kann (wenn mehr als ein Gerät auf dieser Adresse landet kann man diese mit der ETS nicht mehr programmieren). Des weiteren könnte man sich den Flash kaputt schreiben wenn die Routine unkontrolliert auf die PA schreibt (da hatten wir mal einen Bug im LPC Code).
Ich muss mir den Teil für die PA mal ansehen wo ich eh schon am Bootloader dran bin. Es sollte möglich sein eine Default Adresse als passenden Wert im Hex abzulegen.
Das leere Geräte 15.15.255 haben kommt aus Urzeiten, da steht dann 0xFF im Speicher. Das habe ich beim LPC mit dem Default Eintrag so umgesetzt. Das braucht auch keinen Speicher im Kontroller, da dies eine Anweisung ist die Adresse in der Hex Datei auf 0xFF zu setzten. Generell sollte man vorsichtig sein wenn man die PA im Kontroller zur Laufzeit verbiegt, es muss sicher gestellt sein das dies nie zufällig passieren kann (wenn mehr als ein Gerät auf dieser Adresse landet kann man diese mit der ETS nicht mehr programmieren). Des weiteren könnte man sich den Flash kaputt schreiben wenn die Routine unkontrolliert auf die PA schreibt (da hatten wir mal einen Bug im LPC Code).
Ich muss mir den Teil für die PA mal ansehen wo ich eh schon am Bootloader dran bin. Es sollte möglich sein eine Default Adresse als passenden Wert im Hex abzulegen.