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.

  • 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
    1. --- system_stm32f10x.c.o 2020-08-15 12:04:17.823880322 +0200
    2. +++ system_stm32f10x.c 2020-08-15 12:04:25.839452506 +0200
    3. @@ -881,7 +881,7 @@ static void SetSysClockTo72(void)
    4. /* Flash 2 wait state */
    5. FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
    6. - FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;
    7. + 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
    1. --- system_stm32f10x.c.o 2020-08-15 12:04:17.823880322 +0200
    2. +++ system_stm32f10x.c 2020-08-15 12:04:25.839452506 +0200
    3. @@ -881,7 +881,7 @@ static void SetSysClockTo72(void)
    4. /* Flash 2 wait state */
    5. FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
    6. - FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;
    7. + 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...