Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

[frank]

das problem beim ota-update des bootloaders für den wettersensor ist wohl folgender natur:

am ende des bootbereichs wird eine page reserviert für die funktion "updateBootloaderFromRWW", die den bootloader überschreibt. die grösse dieser funktion wird wohl für die 128 byte page vom 328p zu gross sein. wenn ich im makefile 2 pages reserviere,

Code Auswählen Erweitern

HB_UW_Sen_THPL:     BOOT_PAGES       = 31
HB_UW_Sen_THPL:     BOOT1_START       = 0x7F00
HB_UW_Sen_THPL:     ADDRESS_DATA_START    = 0x7EF0

kann avrdude den bootloader über isp flashen und er meldet sich korrekt über funk.

jetzt gibt es dann aber ein problem mit dem ota update des bootloaders. der hängt sich auf.
im program und im makefile wird auf den reservierten bereich rücksicht genommen, indem die letzte page nicht beschrieben wird. da es aber beim 644 eine page ist und beim 328p nun 2 pages sind, müsste man die funktion oder das makefile entsprechend der prozessortypen unterschiedlich programmieren. da komme ich mit meinen derzeitigen kenntnissen noch nicht weiter. ich probiere mal weiter.

wie/womit kann ich denn den speicherbedarf einer funktion ermitteln?

gruss frank

[Dirk]

Ich habe am Bootloader noch mal einiges überareitet so dass ich die Codegräße noch weiter schrumpfen konnte.
Ohne Debugausgaben komme ich noch auf eine Größe von ~ 2,9 kB.

Ich hoffe so genügend Platz geschaffen zu haben um die Erweiterung von Unimatrix zum OTAU-Updatebaren Bootloaders auch im 4K Bootloaderbereich unterbringen zu können.

Änderungen:

• Codeoptimierungen: entfernen "doppelten" Codes, unnötigen Funktionsaufrufe
• Ich habe an der Stabilität der Übertragung noch etwas gefeilt. Somit hoffe ich dass es seltener zu Aussetzern bzw. Abbrücken während des Flashen kommt.
• Das Prüfen der Configtaste wenn der Bootloader durch das Hauptprogtramm gestartet wird habe ich nach der Idee von Frank wieder entfernt. Das Prüfen ob der Bootloader erst z.B. nach Drücken der Konfig-Taste gestartet werden soll, kann so besser das Hauptprogtramm entscheiden.
• Ich  habe noch eine Prüfung eingebaut, so dass es aktuell nicht mehr möglich sein sollte durch ein zu großes Updatefile den Bootloader zu überschreiben auch wenn keine Lockbits gesetzt sind.
• Ich habe das Convert-Script noch etwas erweitert. Man kann nun in einem Durchgang das Hexfile in ein eq-3-File konvertieren. hex2eq3 liegt im Contrib-Ordner
  
• Das Flash-Tool habe ich mit ins Repo gepackt. Damit kann man den Bootloader per ISP in den AVR "Brennen" und gleichzeitig seine gewünschten Adressdaten (Seriennummer, HM-ID, HM-Type) angeben. Aktuell leider nur in einer Windows-Version.
  Mit diesem Tool kann man aktuell aber noch nicht den Bootloader alleine flashen. Man muss sich zunächst ein Hex-File aus Hauptprogramm+Bootloader bauen.
  Das geht recht einfach, indem man sich zunächst z.B. mit dem hex2eq3-Tool eine HEX-Datei mit CRC-Infos ausgeben lässt, wenn man CRC nutzen möchte. Von der entstandenen HEX-Datei wird die letzte Zeile abgeschnitten und dann das Hex-File des Bootloaders dahinterkopiert.
  

Gruß
Dirk

[Tobias]

Gibt es schon etwas neues vom ProgAdapter? Haben die Chinesen mittlerweile die Prognadeln geliefert??

[frank]

Ich hoffe so genügend Platz geschaffen zu haben um die Erweiterung von Unimatrix zum OTAU-Updatebaren Bootloaders auch im 4K Bootloaderbereich unterbringen zu können.

prima. das hört sich hervorragend an. 

gruss frank

[Mr. P]

Ich habe am Bootloader noch mal einiges überareitet so dass ich die Codegräße noch weiter schrumpfen konnte.

Cool!

Aktuell leider nur in einer Windows-Version.

Das hat jetzt allerdings was von einem Showstopper. :-/
Aber vielleicht kommt da demnächst noch etwas für Linux nach?

[frank]

update:

mit diesen änderungen des minibootloaders passt er nun gerade in eine 128 byte page.

Code Auswählen Erweitern

void updateBootloaderFromRWW(){
// copy bootloader image from RWW section into NRWW section (except top page with this function)

uint32_t address;
for (uint8_t i=0;i<BOOT_PAGES-1;i++){
address=BOOTLOADER_START+(i*SPM_PAGESIZE);
//boot_page_erase (BOOTLOADER_START+(i*SPM_PAGESIZE));
for(uint16_t j=0;j<SPM_PAGESIZE;j=j+2){
//wordbuf=pgm_read_word((i*SPM_PAGESIZE)+j);
//address=BOOTLOADER_START+(i*SPM_PAGESIZE)+j;
boot_page_fill(address+j,pgm_read_word(address-BOOTLOADER_START+j));
}

boot_page_write(address);
boot_spm_busy_wait();
boot_rww_enable();
}
//address=BOOTLOADER_START-SPM_PAGESIZE;
boot_page_erase(BOOTLOADER_START-SPM_PAGESIZE);

wdt_enable(WDTO_1S);
while(1); // wait for Watchdog to generate reset
}

mit diesen einstellungen im make file:

Code Auswählen Erweitern

HB_UW_Sen_THPL:     TARGET                = HB_UW_Sen_THPL
HB_UW_Sen_THPL:     MCU                   = atmega328p
HB_UW_Sen_THPL:     CODE_LEN              = 0x6FFE
HB_UW_Sen_THPL:     BOOTLOADER_START      = 0x7000
HB_UW_Sen_THPL:     BOOT_PAGES       = 32
HB_UW_Sen_THPL:     BOOT1_START       = 0x7F80
HB_UW_Sen_THPL:     ADDRESS_DATA_START    = 0x7F70
HB_UW_Sen_THPL:     hex

und diesen änderungen für die srec aufrufe:

Code Auswählen Erweitern

    srec_cat Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex -intel \
    -offset -0x7000 \
    -fill 0xFF 0x0000 0x6ffc \
    -generate 0x6ffc 0x6ffe -repeat-data 0x11 0x47 \
    -o  payload_temp.bin -binary


    srec_cat payload_temp.bin -binary \
    -Cyclic_Redundancy_Check_16_Little_Endian 0x6FFE \
    -o  payload.bin -binary

kann ich den bootloader vom wettersensor nun ota updaten. nun gibt es leider noch ein kleines problemchen mit den devicedaten (hmid und seriennummer). beim flashen über isp mit avrdude ist alles in ordnung. aber nach dem ota-update meldet sich der neue bootloader mit seltsamen daten. da muss ich noch mal schauen.

gruss frank

[Dirk]

Du hast boot_page_erase auskommentiert?
Normalerweise muss vor dem Schreiben des Flashes dieser gelöscht werden.

Gruß
Dirk

[frank]

Du hast boot_page_erase auskommentiert?
Normalerweise muss vor dem Schreiben des Flashes dieser gelöscht werden.

ich dachte, da wir sowieso immer alles komplett kopieren, müsste man nicht mehr unbedingt löschen. das hat mir dann die letzten benötigten bytes gebracht.

also muss ein erase unbedingt gemacht werden, oder nicht? ich bin da nicht so der fachmann. 

gruss frank

[Dirk]

Ist zwar ein Beitrag aus dem Microchip Forum:
http://www.microchip.com/forums/m485168.aspx

Das sollte aber auch auf den Flash vom AVR zutreffen.

Gruß
Dirk

[frank]

merci. das würde den effekt gut erklären.

gruss frank

[frank]

so funktioniert es endlich auch mit dem wettersensor. also der minibootloader:

Code Auswählen Erweitern

void updateBootloaderFromRWW(){
// copy bootloader image from RWW section into NRWW section (except top page with this function)

uint32_t address;

#if SPM_PAGESIZE == 256
for (uint8_t i=0;i<BOOT_PAGES-1;i++){
#elif SPM_PAGESIZE == 128
for (uint8_t i=0;i<BOOT_PAGES-2;i++){
#endif
address=BOOTLOADER_START+(i*SPM_PAGESIZE);
boot_page_erase (address);
for(uint16_t j=0;j<SPM_PAGESIZE;j=j+2){
//wordbuf=pgm_read_word((i*SPM_PAGESIZE)+j);
//address=BOOTLOADER_START+(i*SPM_PAGESIZE)+j;
boot_page_fill(address+j,pgm_read_word(address-BOOTLOADER_START+j));
}

boot_page_write(address);
boot_spm_busy_wait();
boot_rww_enable();
}
//address=BOOTLOADER_START-SPM_PAGESIZE;
boot_page_erase(BOOTLOADER_START-SPM_PAGESIZE);

wdt_enable(WDTO_1S);
while(1); // wait for Watchdog to generate reset
}

makefile daten:

Code Auswählen Erweitern

HB_UW_Sen_THPL:     TARGET                = HB_UW_Sen_THPL
HB_UW_Sen_THPL:     MCU                   = atmega328p
HB_UW_Sen_THPL:     CODE_LEN              = 0x6FFE
HB_UW_Sen_THPL:     BOOTLOADER_START      = 0x7000
HB_UW_Sen_THPL:     BOOT_PAGES       = 32
HB_UW_Sen_THPL:     BOOT1_START       = 0x7F00
HB_UW_Sen_THPL:     ADDRESS_DATA_START    = 0x7EF0
HB_UW_Sen_THPL:     hex

srec aufruf:

Code Auswählen Erweitern

    srec_cat Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex -intel \
    -offset -0x7000 \
    -fill 0xFF 0x0000 0x6ffc \
    -generate 0x6ffc 0x6ffe -repeat-data 0x11 0x47 \
    -o  payload_temp.bin -binary


    srec_cat payload_temp.bin -binary \
    -Cyclic_Redundancy_Check_16_Little_Endian 0x6FFE \
    -o  payload.bin -binary

gruss frank

[Dirk]

Na cool.
Da warst du schneller als ich

Ich werde das heute Abend auch mal testen und einbauen.

Gruß
Dirk

[frank]

ota-self-updating des bootloaders (4k-version) für den schalter (mega644) ist auch erfolgreich getestet. srec und makefile wie bei unimatrix.

dabei ist mir gerade aufgefallen, dass ja die eq3-firmware files immer nur für eine bootloader-variante (4k/8k) funktionieren. das ist ja eigentlich irgendwie nicht wirklich komfortabel. da sollte man sich auf alle fälle bei seinen schaltern auf eine version festlegen. sonst wirds schnell unübersichtlich.

gruss frank

[Mr. P]

ota-self-updating des bootloaders (4k-version) für den schalter (mega644) ist auch erfolgreich getestet. srec und makefile wie bei unimatrix.

Auf die Gefahr hin, dass ich in meinem übermüdeten Zustand etwas überlesen habe... aber könntest du die funktionierenden Workflows mit der zuletzt getesteten Version für Schalter und Sensor posten?

dabei ist mir gerade aufgefallen, dass ja die eq3-firmware files immer nur für eine bootloader-variante (4k/8k) funktionieren. das ist ja eigentlich irgendwie nicht wirklich komfortabel. da sollte man sich auf alle fälle bei seinen schaltern auf eine version festlegen. sonst wirds schnell unübersichtlich.

Also solange die 4k genügen und beide Devices damit bedient werden können, gibt es wohl kaum einen Grund, die 8k-Variante nutzen zu wollen.

[Dirk]

Also solange die 4k genügen und beide Devices damit bedient werden können, gibt es wohl kaum einen Grund, die 8k-Variante nutzen zu wollen.

Es sei denn jemand möchte was größeres anstellen und braucht die zusätzlichen 4k noch 

Ich habe jetzt auch ein paar Tests gemacht und das Bootloaderupdate für gut befunden
Ich habe alles bei mir im Github eingecheckt.

Folgende Sachen sind noch hier dazu gekomen:

• Compatibilität mit dem Update durch die CCU: Die CCU folgt ja nicht dem "normalen" Hochzählen des Message-ID. In meinem Fall habe ich Steps von 8. Da hier andere "Sprünge" nicht ausgeschlossen sind, habe ich den Check der Message-ID noch etwas geändert. Der Bootloader prüft jetzt nur noch ob das folgende Packet eine höhere MessageId hat. Der abschliessende Test an der CCU steht aber noch aus.
• Der CRC-Check ist nun "Pflicht". Ich habe die vorherigen Defines wo der CRC-Check abgeschaltet werden konnte entfernt. Ich meine ein Firmwareupdate ohne CRC-Prüfung macht keinen Sinn. Vor allem wenn so auch der Bootloader upgedatet werden kann.
  Allerdings ist der aktuell implementierte CRC16 für 32k bzw. 64k Daten nicht wirklich ausreichend. Daher werde ich wohl die Tage versuchen noch den CRC-Check auf CRC32 umzustellen.
  
• Das Makefile gibt jetzt auch Auskunft über die detailierte Speicherausnutzung
• Das hex2eq3-Tool kann auch ein Update als Bootloader-Update "Flaggen". So muss man das sreg-cat Kommando nicht selber zusammenschreiben.
• Achja, und vor dem Bootloader-Update blinkt die LED jetzt auch 10mal schnell. So dass man den Start des Updates auch optisch erkennen kann.

Ich habe dem Bootloader jetzt die Version 0.7.0 gegeben.
@Unimax: 0.8.0 fand ich dann doch etwas zu viel

Viele Grüße
Dirk