IRMP auf STM32 - ein USB-HID-Keyboard IR Empfänger+Einschalter mit Wakeup-Timer

  • Im Log kann man sehen, dass nur die ersten 3 Zeilen gelöscht wurden, der Rest aber nicht.

    Jeder Vorgang wird zwar mit OK quittiert, aber die Firmware macht beim Reset keinen verify, das OK bedeutet also nicht, dass der Reset erfolgreich gewesen wäre.


    Offensichtlich funktioniert bei deinem Stick das Beschreiben des eeproms oft nicht. Das Auslesen klappt aber.


    Zeigt die gui diesen Stick als STM32 oder als CS32 an?


    Die IRMP Firmware schreibt im Normalfall nur sehr wenig ins eeprom, nämlich den Wakeup und sonst nichts.

    Die KBD Firmware schreibt das eeprom ziemlich voll, weil ja alle Tasten und Keys drin sind, und meist nach kurzer Zeit auch nicht benutzte Tasten.


    Es wurde ja lange gerätselt, ob die Sticks 64kB oder 128kB voll funktionsfähigen Flash haben. Das im Flash emulierte eeprom liegt derzeit knapp unter 128kB.

    Möglicherweise bist du ja der Erste, der einen uC mit nicht voll funktionsfähigem oberem eeprom/flash erwischt hat?

    Es ist allerdings in all den Jahren das erste Mal.


    Man könnte für diesen Stick eine Firmware bauen mit eeprom unterhalb von 64kB und gucken, ob es damit geht.

    Dazu müsste in der eeprom.h die EEPROM_START_ADDRESS von 0x0801F000 auf 0x0800F000 gesenkt werden.

  • CS32


    Deinen Vorschlag mit eeprom.h schaue ich mir mal an.



  • Alternativ wäre es einen Versuch wert, einen kompletten Erase des uC zu machen. Dann muss aber auch der Bootloader neu geflasht werden. Es gibt im STM32-Utility eine solche Option.


    CS32 und RedCrap ist doppelter Müll ;)

  • Hast du einen Link, wo du den Stick gekauft hast?

    Es wäre interessant, als was der verkauft wurde und mit wieviel angegebenem Flash.

    Nein, leider funktioniert der nicht mehr. In der Bestellhistorie von Aliexpress steht "Stlink ST-Link V2 Mini STM8 STM32". Es sind die Sticks von damals: IRMP auf STM32 - ein USB IR Empfänger/Sender/Einschalter mit Wakeup-Timer


    Kaufen werde ich nur noch die BluePill / BlackPill.



  • Eben nochmal nachgeschaut. Auf dem Chip steht:

    CKS32

    F103C8T6

    NKCM6

    1910 G

    CKS



  • Irgendwie habe ich gerade ein Déjà-vu: https://www.eevblog.com/forum/…-flashing-bluepill-clone/


    Das hatten wir vor längerem schon mal....



  • Probiere mal die angehängte Firmware.

    Die hat 3 Änderungen:

    EEPROM_START_ADDRESS von 0x0801F000 auf 0x0800F000

    3 statt 2 Flash wait states

    EraseTimeout 0X00108000 statt 0x000B0000 und ProgramTimeout 0x00003000 statt 0x00002000

  • Probiere mal die angehängte Firmware.

    Die hat 3 Änderungen:

    EEPROM_START_ADDRESS von 0x0801F000 auf 0x0800F000

    3 statt 2 Flash wait states

    EraseTimeout 0X00108000 statt 0x000B0000 und ProgramTimeout 0x00003000 statt 0x00002000

    Danke. Es hat damit funktioniert. Nach dem Flashen sind alle Einträge weg. :tup


    Ich habe mir mal versucht eine entsprechende Firmware selbst zu erstellen. Die Dateien von ST-Link habe ich aber welche gcc-arm-none-eabi Version ist denn die empfohlene?




  • Schön, dass es nun klappt.

    Das zeigt, dass der CS32 (im Gegensatz zum STM32) kaum Reserven hat, bzw. dein Exemplar sogar mit Standardtimings überfordert ist oder aber das der Flash einen Defekt hat.


    Ich nehme derzeit die 9-2020-q2-update.


    Wenn du willst und auch neugierig bist, könntest du mal gucken, welche der 3 Änderungen es war.

  • Ja, ich bin neugierig :). Ich werde aber die nächsten Tage wegen Arbeiten am Grundstück / Haus nicht dazu kommen.



  • Wenn du wieder Zeit hast, probier mal die angehängte Firmware.

    Die hat nur 1 Änderung (3 statt 2 Flash wait states):

    Diff
    --- system_stm32f10x.c.o        2020-08-15 12:04:17.823880322 +0200
    +++ system_stm32f10x.c  2020-08-15 12:04:25.839452506 +0200
    @@ -881,7 +881,7 @@ static void SetSysClockTo72(void)
    
         /* Flash 2 wait state */
         FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
    -    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;
    +    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY;

    Vielleicht reicht das schon?

  • Wenn du wieder Zeit hast, probier mal die angehängte Firmware.

    Die hat nur 1 Änderung (3 statt 2 Flash wait states):

    Diff
    --- system_stm32f10x.c.o        2020-08-15 12:04:17.823880322 +0200
    +++ system_stm32f10x.c  2020-08-15 12:04:25.839452506 +0200
    @@ -881,7 +881,7 @@ static void SetSysClockTo72(void)
    
         /* Flash 2 wait state */
         FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
    -    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;
    +    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY;

    Vielleicht reicht das schon?

    So, jetzt konnte ich mich endlich mal diesem Thema widmen. Mit dieser Version funktioniert es nicht. Dann mit der 2020-08-11_13-46_RedCrap_BL_SC_KBD_jrie.bin probiert und der Speicher ist leer.



  • Danke für's testen :)


    der Speicher ist leer

    Meinst du damit das eeprom? Nur durch das hin und her flashen kann das eigentlich nicht kommen.


    Falls du noch mehr testen magst, baue ich eine Test-Firmware mit nur geänderter EEPROM_START_ADDRESS. Aber erst in ein paar Wochen, weil jetzt ich erstmal keine Zeit mehr dafür habe.

  • Danke für's testen :)


    Meinst du damit das eeprom? Nur durch das hin und her flashen kann das eigentlich nicht kommen.


    Falls du noch mehr testen magst, baue ich eine Test-Firmware mit nur geänderter EEPROM_START_ADDRESS. Aber erst in ein paar Wochen, weil jetzt ich erstmal keine Zeit mehr dafür habe.

    Ja, das eeprom. Ich unterstützt gerne beim Testen. Die Schlechtwetterzeit kommt ja noch...



  • Nach dem Flashen sind alle Einträge weg.

    der Speicher ist leer.

    Nur zu schauen, ob das Eeprom leer ist, genügt nicht.

    Ein gründlicher Test geht so:

    reset eeprom

    open file (eine map Datei ohne Kommentare mit 61 Zeilen nehmen, wie z.B die angehängte)

    flash eeprom

    get eeprom

    save file

    save (debug messages)

    prüfen, ob reingeflashte und ausgelesene Datei identisch, z.B. mit diff -s file1 file2

    prüfen, ob irgendwelche Fehler im debug: gibt es Zeilen mit ERROR? (Die neue Firmware macht bei jeglichem eeprom Schreibvorgang ein verify.) Z.B. mit grep -e ERROR x.log


    Mach bitte nochmal den gründlichen Test mit der Firmware aus #148, und falls der OK ist, auch mit der Firmware aus #152.

  • Hi. Ich habe gerade festgestellt, dass ich hier ja auch noch eine Baustelle offen habe :saint:. Den von dir angesprochenen gründlichen Test mache ich noch. Ich bin über ein seltsames Phänomen mit dem RedCrap Stick und mit der Firmware #148 gestolpert. Der erzeugt auch Wakeup Signale beim drücken von normalem Tasten. Aufgefallen ist es mir, als ich die OK Taste drückte und mein Bastel Pi ist aufgeweckt....


    Ich habe ein Multimeter dazwischen geklemmt und festgestellt, dass ein normaler Tastendruck 0,5V erzeugt und das reicht, damit der Pi aufweckt. Die definierte Wakeup Taste erzeugt zwischen 1,2 und 1,5V.


    Sollte das ein Firmware Thema sein, oder eher der Stick ?



    Einmal editiert, zuletzt von obelix ()

  • Ein Test mit einem anderen Stick und IRMP Firmware zeigt das gleiche Verhalten. Ein normaler Tastendruck erzeugt 0,5V. Sind vermutlich die RedCrap Sticks...



  • An welcher Stelle misst du die 0,5V bzw. 1,2 bis 1,5V? Was misst du dort ohne Tastendruck?

    Welche Firmware hast du in #158 benutzt? Ist der andere Stick auch ein CKS32?

    Was ist zwischen dem Stick und dem Pi?

    Falls es beides CKS32 sind, passiert das auch auf einem STM32?

  • An welcher Stelle misst du die 0,5V bzw. 1,2 bis 1,5V? Was misst du dort ohne Tastendruck?

    Welche Firmware hast du in #158 benutzt? Ist der andere Stick auch ein CKS32?

    Was ist zwischen dem Stick und dem Pi?

    Falls es beides CKS32 sind, passiert das auch auf einem STM32?

    Sind beides CK32. An die Bezeichnung gewöhne ich mich einfach nicht. Ich messe die Spannung am Pin 6 (SWCLK) nach dem Widerstand gegen GND. Ohne Tastendruck sind es 0V. Nein die Firmware aus #158 habe ich nicht getestet, da ein Stick mit IRMP Firmware das gleiche Verhalten zeigt.


    Ein Test mit einem STM32 mache ich....



Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!