Forum: Mikrocontroller und Digitale Elektronik Nucleo-H743ZI in Linux und mit stlink 1.5.0


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
Hallo STM32H Experten,

hat jemand eine Ahnung wie man das o.g. Board via
stlink SW (Ver. 1.5.0, aus dem github) anspricht.

Mein Versuch scheitert leider.

st-flash 1.5.0
2018-04-25T13:20:52 DEBUG common.c: stlink current mode: debug (jtag or 
swd)
2018-04-25T13:20:52 DEBUG common.c: stlink current mode: debug (jtag or 
swd)
2018-04-25T13:20:52 DEBUG common.c: *** looking up stlink version
2018-04-25T13:20:52 DEBUG common.c: st vid         = 0x0483 (expect 
0x0483)
2018-04-25T13:20:52 DEBUG common.c: stlink pid     = 0x374b
2018-04-25T13:20:52 DEBUG common.c: stlink version = 0x2
2018-04-25T13:20:52 DEBUG common.c: jtag version   = 0x1d
2018-04-25T13:20:52 DEBUG common.c: swim version   = 0x12
2018-04-25T13:20:52 DEBUG common.c: *** stlink_jtag_reset ***
2018-04-25T13:20:52 DEBUG common.c: *** stlink_reset ***
2018-04-25T13:20:52 INFO common.c: Loading device parameters....
2018-04-25T13:20:52 DEBUG common.c: *** stlink_core_id ***
2018-04-25T13:20:52 DEBUG common.c: core_id = 0x6ba02477
2018-04-25T13:20:52 DEBUG common.c: *** stlink_read_debug32 0 is 
0xe0042000
2018-04-25T13:20:52 DEBUG common.c: *** stlink_read_debug32 0 is 
0x40015800
2018-04-25T13:20:52 WARN common.c: Invalid flash type, please check 
device declaration
2018-04-25T13:20:52 DEBUG common.c: *** set_swdclk ***
2018-04-25T13:20:52 DEBUG common.c: stlink current mode: debug (jtag or 
swd)
2018-04-25T13:20:52 DEBUG common.c: stlink current mode: debug (jtag or 
swd)
2018-04-25T13:20:52 DEBUG common.c: *** stlink_force_debug_mode ***
2018-04-25T13:20:52 DEBUG common.c: *** stlink_status ***
2018-04-25T13:20:52 DEBUG common.c:   core status: halted
2018-04-25T13:20:52 DEBUG common.c: *** stlink_exit_debug_mode ***
2018-04-25T13:20:52 DEBUG common.c: *** stlink_write_debug32 a05f0000 to 
0xe000edf0
2018-04-25T13:20:52 DEBUG common.c: *** stlink_close ***

>./st-info --version
v1.5.0

./st-info --serial
303636444646333533383330353233

st-info --chipid
<Keine Ausgabe>

>st-info --probe
Found 1 stlink programmers



Für sachdienliche Hinweise danke ich schon mal in Voraus.

Markus
DL8MBY


Nachtrag,

wahrscheinlich müsste man den entsprechenden Eintrag in

src/chipid.c

static const struct stlink_chipid_params devices[] = {
        {
            //RM0410 document was used to find these paramaters
            .chip_id = STLINK_CHIPID_STM32_F7XXXX,
            .description = "F76xxx device",
            .flash_type = STLINK_FLASH_TYPE_F4,
            .flash_size_reg = 0x1ff0f442,      // section 45.2
            .flash_pagesize = 0x800,           // No flash pages
            .sram_size = 0x80000,              // "SRAM" byte size in 
hex from
            .bootrom_base = 0x00200000,        //! "System memory" 
starting address from
            .bootrom_size = 0xEDC0             //! @todo "System memory" 
byte size in hex from
        },
...


./include/stlink/chipid.h

enum stlink_stm32_chipids {
        STLINK_CHIPID_UNKNOWN                = 0x000,

        STLINK_CHIPID_STM32_F1_MEDIUM        = 0x410,
        STLINK_CHIPID_STM32_F2               = 0x411,
        STLINK_CHIPID_STM32_F1_LOW           = 0x412,

...


machen.

Hat jemand dazu bereits die nötigen Werte?

: Bearbeitet durch User
von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nö, weiß ich nicht.

Es gibt aber den STM32Cube Programmer.
Auch für Linux und auch als Kommandozeilen Version.

von pegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hinweise.


Ich habe im Web

https://github.com/texane/stlink/issues/671

folgende Ergänzungen gefunden, die ich in die
Files ./src/chipid.c und ./include/stlink/chipid.h

Eingepflegt habe.

./src/chipid.c
===============
        {
            //RM0433 document was used to find these paramaters
            .chip_id = STLINK_CHIPID_STM32_H74XXX,
            .description = "H743xx device",
            .flash_type = STLINK_FLASH_TYPE_F4,
            .flash_size_reg = 0x1FF1E880,      // section 61.2
            .flash_pagesize = 0x800,           // No flash pages
            .sram_size = 0x100000,             // "SRAM" byte size in 
hex from
            .bootrom_base = 0x1FFF0000,        //! "System memory" 
starting address from
            .bootrom_size = 0x1E800            //! @todo "System memory" 
byte size in hex from
        },


./include/stlink/chipid.h
==========================

STLINK_CHIPID_STM32_H74XXX       = 0x450  /* Found on page 3069 in the 
RM0433

Leider war nach dem Compilieren immer noch kein
Erkennen des H743ZI Chips möglich.

Falls jemand noch Ideen hat, bitte melden.

Ich werde mir Heute Abend mal das DB zum H743 durchsehen.
Vielleicht finde ich ja noch was Brauchbares.

Wäre zu schön gewesen, wenn es so einfach zu lösen gewesen
wäre.


Markus
DL8MBY

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
Eine printf-Zeile in

const struct stlink_chipid_params *stlink_chipid_get_params(uint32_t 
chipid)
{
  const struct stlink_chipid_params *params = NULL;
        printf("stlink_chipid_params %d\n",chipid);
  for (size_t n = 0; n < STLINK_ARRAY_SIZE(devices); n++) {
    if (devices[n].chip_id == chipid) {
      params = &devices[n];
      break;
    }
  }

  return params;
}

liefert chipid 0

>./st-info --chipid
stlink_chipid_params 0
0x0000

trotz der Erweiterung um des struct Inhalt

        {
            //RM0433 document was used to find these paramaters
            .chip_id = STLINK_CHIPID_STM32_H74XXX,
            .description = "H743xx device",
            .flash_type = STLINK_FLASH_TYPE_F4,
            .flash_size_reg = 0x1FF1E880,      // section 61.2
            .flash_pagesize = 0x800,           // No flash pages
            .sram_size = 0x100000,             // "SRAM" byte size in 
hex from
            .bootrom_base = 0x1FFF0000,        //! "System memory" 
starting address from
            .bootrom_size = 0x1E800            //! @todo "System memory" 
byte size in hex from
        },

und dem define von

STLINK_CHIPID_STM32_H74XXX           = 0x450,


Hat jemand Ahnung, wie die ID ausgelesen wird,
oder wo genau es im Code von stlink passiert.

Markus
DL8MBY

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
Auch auf die Gefahr hin, dass dieser Thread ein Monolog wird,
habe ich die Stelle gefunden.

find . -name \*.c -exec grep -i -H chip {} \;
./common.c:    ret = stlink_read_debug32(sl, 0xE0042000, chip_id);



int stlink_chip_id(stlink_t *sl, uint32_t *chip_id) {
    int ret;

    ret = stlink_read_debug32(sl, 0xE0042000, chip_id);
    printf("stlink_chip_id stlink_read_debug32 0xE0042000 %d 
%d\n",*chip_id,ret);
    if (ret == -1)
        return ret;

    if (*chip_id == 0)
        ret = stlink_read_debug32(sl, 0x40015800, chip_id);    //Try 
Corex M0 DBGMCU_IDCODE register address
        printf("stlink_chip_id stlink_read_debug32 0xE0042000 %d 
%d\n",*chip_id,ret);

    return ret;
}

>./st-info --chipid
stlink_chip_id stlink_read_debug32 0xE0042000 0 0
stlink_chip_id stlink_read_debug32 0xE0042000 0 0
stlink_chipid_params 0
0x0000


Die Ausgabe zeigt, das die Chipid an der Adresse 0xE0042000
mit 0 zurückgegeben wird.

Jetzt muss ich nur noch herausfinden, falls es keiner von Euch
sofort aus dem FF weiß, wo die Chipid im H7 abgelegt wird.


Markus
DL8MBY

: Bearbeitet durch User
von Klaus S. (skibby)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus,
beim H7 steht die CHIP-ID bei 0x5C001000

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
Danke Klaus,

habe es gerade auch gefunden!
und es funktioniert!




Hi, this returns zero, however reading the other address (0x5C001000) 
returns the chip id:




>./st-info --chipid
stlink_chip_id stlink_read_debug32 0xE0042000 0 0
stlink_chip_id stlink_read_debug32 0x40015800 0 0
stlink_chip_id stlink_read_debug32 0x40015800 268657744 0
stlink_chipid_params 1104
0x0450


int stlink_chip_id(stlink_t *sl, uint32_t *chip_id) {
    int ret;

    ret = stlink_read_debug32(sl, 0xE0042000, chip_id);
    printf("stlink_chip_id stlink_read_debug32 0xE0042000 %d 
%d\n",*chip_id,ret);
    if (ret == -1)
        return ret;

    if (*chip_id == 0) {
        ret = stlink_read_debug32(sl, 0x40015800, chip_id);    //Try 
Corex M0 DBGMCU_IDCODE register address
        printf("stlink_chip_id stlink_read_debug32 0x40015800 %d 
%d\n",*chip_id,ret);
    }

    if (*chip_id == 0) {
        ret = stlink_read_debug32(sl, 0x5C001000, chip_id);    //Try 
Corex M0 DBGMCU_IDCODE register address
        printf("stlink_chip_id stlink_read_debug32 0x40015800 %d 
%d\n",*chip_id,ret);
    }

    return ret;
}



>./st-flash --debug --serial /dev/ttyACM0 read /tmp/1.bin 0x0800000 0x100
st-flash 1.5.0
2018-04-25T15:01:42 DEBUG common.c: stlink current mode: mass
2018-04-25T15:01:42 DEBUG common.c: stlink current mode: mass
2018-04-25T15:01:42 DEBUG common.c: *** stlink_enter_swd_mode ***
2018-04-25T15:01:42 DEBUG common.c: *** looking up stlink version
2018-04-25T15:01:42 DEBUG common.c: st vid         = 0x0483 (expect 
0x0483)
2018-04-25T15:01:42 DEBUG common.c: stlink pid     = 0x374b
2018-04-25T15:01:42 DEBUG common.c: stlink version = 0x2
2018-04-25T15:01:42 DEBUG common.c: jtag version   = 0x1d
2018-04-25T15:01:42 DEBUG common.c: swim version   = 0x12
2018-04-25T15:01:42 DEBUG common.c: *** stlink_jtag_reset ***
2018-04-25T15:01:42 DEBUG common.c: *** stlink_reset ***
2018-04-25T15:01:42 INFO common.c: Loading device parameters....
2018-04-25T15:01:42 DEBUG common.c: *** stlink_core_id ***
2018-04-25T15:01:42 DEBUG common.c: core_id = 0x6ba02477
2018-04-25T15:01:42 DEBUG common.c: *** stlink_read_debug32 0 is 
0xe0042000
stlink_chip_id stlink_read_debug32 0xE0042000 0 0
2018-04-25T15:01:42 DEBUG common.c: *** stlink_read_debug32 0 is 
0x40015800
stlink_chip_id stlink_read_debug32 0x40015800 0 0
2018-04-25T15:01:42 DEBUG common.c: *** stlink_read_debug32 10036450 is 
0x5c001000
stlink_chip_id stlink_read_debug32 0x40015800 268657744 0
stlink_chipid_params 1104
2018-04-25T15:01:42 DEBUG common.c: *** stlink_read_debug32 800 is 
0x1ff1e880
2018-04-25T15:01:42 INFO common.c: Device connected is: H743xx device, 
id 0x10036450
2018-04-25T15:01:42 INFO common.c: SRAM size: 0x100000 bytes (1024 KiB), 
Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2018-04-25T15:01:42 DEBUG common.c: *** set_swdclk ***
2018-04-25T15:01:42 DEBUG common.c: stlink current mode: debug (jtag or 
swd)
2018-04-25T15:01:42 DEBUG common.c: stlink current mode: debug (jtag or 
swd)
2018-04-25T15:01:42 DEBUG common.c: *** stlink_force_debug_mode ***
2018-04-25T15:01:42 DEBUG common.c: *** stlink_status ***
2018-04-25T15:01:42 DEBUG common.c:   core status: halted
2018-04-25T15:01:42 DEBUG common.c: *** stlink_read_mem32 ***
data_len = 256 0x100
 80 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

2018-04-25T15:01:42 DEBUG common.c: *** stlink_exit_debug_mode ***
2018-04-25T15:01:42 DEBUG common.c: *** stlink_write_debug32 a05f0000 to 
0xe000edf0
2018-04-25T15:01:42 DEBUG common.c: *** stlink_close ***



Markus
DL8MBY

von Markus W. (dl8mby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

falls jemand das Tool braucht,
oder gar es ins github rein stellen kann,
(ich kann es leider noch nicht) wäre
das schön.


Markus
DL8MBY

PS.: Ich würde erst ein paar Binaries
in den H7 laden um zu sehen, ob die SW
wirklich ordentlich funktioniert.

Für daraus resultierenden Ärger oder
Schaden übernehme ich keine Verantwortung!

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Leider ist es mit der Chip-ID bzw. Adresse derselben nicht getan, der H7 
unterscheidet sich doch deutlich vom F7 )-:
Deshalb gibt's etwa bei openOCD einen separaten Flash-Driver dazu.

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
Hallo A.B.,

konnte ich mir nicht z.B. ein Binary mit einem bestimmten
Muster programmieren und es wieder auslesen um zu sehen,
ob die Routinen richtig funktionieren und die Daten richtig
schreiben?

Nur so kann man Schritt für Schritt Fehler finden und eventuell
beheben.

Ich arbeite schon länger mit den stlink Tools am F4 und würde
gerne auch für den F7 und H7 diese nützen und andere Hobby-STM32
-Nörds sicherlich auch, wenn sie unter Linux arbeiten.

Eclipse ist aber nicht so mein Favorit, weshalb die CLI Tools vorziehe.


Markus
DL8MBY

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> konnte ich mir nicht z.B. ein Binary mit einem bestimmten
> Muster programmieren und es wieder auslesen um zu sehen,
> ob die Routinen richtig funktionieren und die Daten richtig
> schreiben?

Klar, kann man ausprobieren, kaputt wird da höchstwahrscheinlich nichts 
gehen. Aber z. B. die Adressen des Flash-Controllers sind komplett 
anders,
der H7 hat auch mehr oder minder zwei getrennte. Insofern ist im voraus 
klar, dass es nicht funktionieren kann, Ausprobieren ist also 
Zeitverschwendung.

> Ich arbeite schon länger mit den stlink Tools am F4 und würde
> gerne auch für den F7 und H7 diese nützen und andere Hobby-STM32
> -Nörds sicherlich auch, wenn sie unter Linux arbeiten.
> Eclipse ist aber nicht so mein Favorit, weshalb die CLI Tools vorziehe.

Ähm, und? 1) ist etwa openOCD auch ein CLI-Tool und 2) läuft's auch 
unter Linux. Außerdem kenne ich beide Wünsche nur zu gut, die habe ich 
nämlich genauso.

Es gibt ja noch Blackmagic, aber ob es da schon Unterstützung für den H7 
gibt, weiß ich nicht.

Auch in openOCD ist die Unterstützung noch recht rudimentär, Flash 
programmieren etc. geht, aber das Ändern der Option-Bits, RDP-Level-1 
und -2 geht nur mit ein bisschen händischen Registerzugriffen. Geht 
alles, aber etwas unkomfortabel ...
Ebenso das Tauschen der beiden Flash-Bänke.

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
@A.B.

habe mal testweise openocd probiert, allerdings fehl mir da auch
z.Z. noch ein stm32h7x.cfg File (nur stm32f7x.cfg vorhanden)

Da gibt es aber auch einen Fehler, wegen einer ChipID, die nicht
richtig erkannt wird. Aber möglicherweise ist mein OpenOCD
Packet zu alt. Werde mich etwas spielen, vielleicht klappt es ja.
Man lernt jedenfalls einiges dabei.

Danke für Deine Erklärung.

Markus
DL8MBY


>openocd -f /usr/local/share/openocd/scripts/interface/stlink-v2-1.cfg -c 
"adapter_khz 1000; transport select hla_swd" -f 
/usr/local/share/openocd/scripts/target/stm32f7x.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.org/doc/doxygen/bugs.html
adapter speed: 1000 kHz
hla_swd
Info : The selected transport took over low-level target control. The 
results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v29 API v2 SWIM v18 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.249012
Warn : UNEXPECTED idcode: 0x6ba02477
Error: expected 1 of 1: 0x5ba02477
in procedure 'init'
in procedure 'ocd_bouncer'

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
In der Tat wohl zu alt. Die relevanten Patches sind:

http://openocd.zylin.com/#/c/4181/
http://openocd.zylin.com/#/c/4182/

von Markus W. (dl8mby)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@A.B.

die patch Orgie habe ich nun hinter mir - huh!

was nun?

OpenOCD 0.10.0 soweit installiert und es scheint auch
ein H743 Target erkannt zu werden.

> halt
target halted due to debug-request, current mode: Thread
xPSR: 0x21000000 pc: 0x0800199a msp: 0x20001618

Siehe Anhang!

Markus
DL8MBY

: Bearbeitet durch User
von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> was nun?
>
> OpenOCD 0.10.0 soweit installiert und es scheint auch
> ein H743 Target erkannt zu werden.
>
>> halt

Der Anhang ist etwas ... verstümmelt, das Ende fehlt. Aber sieht ja am 
Anfang erfolgreich aus.

Zu dem "was nun?": Nun ja, kommt drauf an, was man eigentlich machen 
will.

Test, ob Flash-Größe erkannt: flash probe ...
Flash programmieren: flash write_image ...
dto.: flash write_bank ...
Flash auslesen: flash read_bank ...
Flash komplett löschen: stm32h7x mass_erase ...
Start (der progr. Firmware): reset run

Wichtig ist noch, beim Start von openOCD "stm32h7x_dual_bank.cfg" 
anzugeben,
nicht "stm32h7x.cfg", denn der h743 hat zwei Flash-Bänke, von denen 
sonst nur die erste konfiguriert würde.

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
@A.B.,

ich habe eine openocd.cfg im Projekt Dir mit
dem Inhalt:

source [find  board/stm32h7x3i_eval.cfg]

in dem File board/stm32h7x3i_eval.cfg steht wiederum

source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32h7x_dual_bank.cfg]
reset_config srst_only


so wie Du darauf hingewiesen hast:
source [find target/stm32h7x_dual_bank.cfg]

Danke!

Markus
DL8MBY

von Markus W. (dl8mby)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo Forum,

ich habe mal meine Schritte zusammengestellt
um unter OpenSuse 42.3 openocd-0.10.0 für
das Nucleo-H743ZI Board zu patchen, zu compilieren,
und zu installieren.

Ich hoffe es hilft dem einen oder anderem
bei den ersten Schritten.

Falls jemand eine bessere Methode kennt, die
schneller zum Erfolg führt, bitte kund tun.

Markus
DL8MBY

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
@A.B.
und
die openocd-Experten

Was mich noch etwas verwirrt ist die size Angabe beim Lesen mit
dem flash banks Kommando.

> flash banks
#0 : stm32h7x.flash (stm32h7x) at 0x08000000, size 0x00000000, buswidth 
0, chipwidth 0
#1 : stm32h7x.flash1 (stm32h7x) at 0x08100000, size 0x00000000, buswidth 
0, chipwidth 0

Heißt dass, das die OpenOCD Installation noch nicht richtig 
funktioniert?

Ein halt Befehl bringt das default Blinky-Programm zum stehen und ein
reset run startet es wieder, somit scheint ein Teil zu funktionieren.

Wie kann ich die Funktionalität beim Nucleo-H743ZI testen, ohne gleich
ein Programm schreiben und/oder laden zu müssen.

Danke für hilfreiche Antworten.

Markus
DL8MBY

Nachtrag:

Aber ein flash probe 0/1 liefert sinnvolle Werte!

> flash probe 0
Device: STM32H7xx 2M
flash size probed value 2048
STM32H flash has dual banks. Bank (0) size is 1024kb, base address is 
0x8000000
flash 'stm32h7x' found at 0x08000000

> flash probe 1
Device: STM32H7xx 2M
flash size probed value 2048
STM32H flash has dual banks. Bank (1) size is 1024kb, base address is 
0x8100000
flash 'stm32h7x' found at 0x08100000

: Bearbeitet durch User
von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
Und noch eine Frage!

Wie kann ich die 0x4000000 beim od -c intepretieren, wenn ich
nur 1048576 Bytes gelesen habe? (ist Faktor 64 mehr ???)

> flash read_bank 0 /tmp/stm32h7_bank0.bin 0x08000000 0x100000
wrote 1048576 bytes to file /tmp/stm32h7_bank0.bin from flash bank 0 at 
offset 0x08000000 in 9.373802s (109.241 KiB/s)

> flash read_bank 1 /tmp/stm32h7_bank1.bin 0x08100000 0x100000
wrote 1048576 bytes to file /tmp/stm32h7_bank1.bin from flash bank 1 at 
offset 0x08100000 in 9.319505s (109.877 KiB/s)

>od -c /tmp/stm32h7_bank0.bin | more
0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
4000000 <== ?????

>od -c /tmp/stm32h7_bank1.bin | more
0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
4000000 <== ?????

Markus
DL8MBY

Nachtrag: und noch folgender Output von openocd:

> flash info 0
#0 : stm32h7x at 0x08000000, size 0x00100000, buswidth 0, chipwidth 0
  #  0: 0x00000000 (0x20000 128kB) not protected
  #  1: 0x00020000 (0x20000 128kB) not protected
  #  2: 0x00040000 (0x20000 128kB) not protected
  #  3: 0x00060000 (0x20000 128kB) not protected
  #  4: 0x00080000 (0x20000 128kB) not protected
  #  5: 0x000a0000 (0x20000 128kB) not protected
  #  6: 0x000c0000 (0x20000 128kB) not protected
  #  7: 0x000e0000 (0x20000 128kB) not protected
STM32H7xx 2M - Rev: Y
> flash info 1
#1 : stm32h7x at 0x08100000, size 0x00100000, buswidth 0, chipwidth 0
  #  0: 0x00000000 (0x20000 128kB) not protected
  #  1: 0x00020000 (0x20000 128kB) not protected
  #  2: 0x00040000 (0x20000 128kB) not protected
  #  3: 0x00060000 (0x20000 128kB) not protected
  #  4: 0x00080000 (0x20000 128kB) not protected
  #  5: 0x000a0000 (0x20000 128kB) not protected
  #  6: 0x000c0000 (0x20000 128kB) not protected
  #  7: 0x000e0000 (0x20000 128kB) not protected
STM32H7xx 2M - Rev: Y

: Bearbeitet durch User
von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> flash banks
#0 : stm32h7x.flash (stm32h7x) at 0x08000000, size 0x00000000, buswidth
0, chipwidth 0
#1 : stm32h7x.flash1 (stm32h7x) at 0x08100000, size 0x00000000, buswidth
0, chipwidth 0

liefert erst nach dem "probe" gültige Werte. Ist aber sonst kein 
Problem, da die meisten Kommandos das automatisch machen, wenn noch 
nicht erfolgt.

Das "od" spricht von Natur aus oktal ... Wohl noch ein Relikt aus der 
PDP-11-Ära. "od -A x -t x1" oder so ist etwas genießbarer.

04000000 = 0x100000 = 1048576

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
Danke,

darauf bin ich trotz Linux Hintergrund nicht von selbst
drauf gekommen.

Markus

PS.: Wo bekomme ich nun eine .bin oder ihex Datei, die ich
in den H7 laden könnte? Habe noch keine Vorstellung, wie ich
es und ob überhaupt mit meiner Toolchain für den H7 erzeugen
kann.

von A. B. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:

> PS.: Wo bekomme ich nun eine .bin oder ihex Datei, die ich
> in den H7 laden könnte? Habe noch keine Vorstellung, wie ich
> es und ob überhaupt mit meiner Toolchain für den H7 erzeugen
> kann.

Die Toolchain ist kein Problem, denn die CPU-Architektur ist dieselbe 
wie beim F7. Allerdings die Peripherie ... Sprich die Header-Dateien, 
ggf. HAL usw. Am einfachsten mittels CubeMX. Das heißt nicht, dass man 
das CubeMX inkl. HAL benutzen muss! Nur damit bekommt man das ganze 
Paket bequem (und kann es ggf. auch so aktualisieren). Teilweise ist die 
Peripherie praktisch identisch mit der der anderen Serien (z. B. GPIO) 
bis auf die Basisadressen, aber teilweise komplett anders (RCC).

Die aktuelle Paket-Version für den H7 ist STM32Cube_FW_H7_V1.2.0, ein 
paar schlappe 100 MByte ... Die Binär-Version der Firmware vom 
Nucleo-Board ist mit dabei.

von Markus W. (dl8mby)


Bewertung
0 lesenswert
nicht lesenswert
A.D. danke für Deine Erklärung.

Ich habe in der Zwischenzeit versucht ein Binary aus der
stm32h7x.S aus dem openocd source zu erstellen und es zu flashen.

Scheint zu funktionieren.
Zumindest finde ich die Patterns im Flash an der vermuteten Stellen.

Markus

arm-none-eabi-gcc -c stm32h7x.S
arm-none-eabi-objcopy -O binary stm32h7x.o stm32h7_flash_write_code.bin
==> stm32h7_flash_write_code.bin

>od -A x -t x1 .../ARM/wrk/stm32h7/stm32h7_flash_write_code.bin
000000 45 68 06 68 26 b3 76 1b 42 bf 76 18 36 1a 08 3e
000010 20 2e f6 d3 4f f0 32 06 e6 60 4f f0 08 07 55 f8
000020 04 6b 42 f8 04 6b bf f3 4f 8f 8d 42 28 bf 00 f1
000030 08 05 01 3f f3 d1 26 69 16 f0 01 0f fb d1 05 4f
000040 3e 42 03 d1 45 60 01 3b db d1 01 e0 00 27 47 60
000050 30 46 00 be 00 00 ee 03
000058


> program .../ARM/wrk/stm32h7/stm32h7_flash_write_code.bin 0x08000000
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800d9dc msp: 0x20001670
adapter speed: 4000 kHz
** Programming Started **
auto erase enabled
wrote 131072 bytes from file 
.../ARM/wrk/stm32h7/stm32h7_flash_write_code.bin in 1.914574s (66.856 
KiB/s)
** Programming Finished **

flash read_bank 0 /tmp/stm32h7_bank0_mw.bin 0x0 0x100

>od -A x -t x1 /tmp/stm32h7_bank0_mw.bin
000000 45 68 06 68 26 b3 76 1b 42 bf 76 18 36 1a 08 3e
000010 20 2e f6 d3 4f f0 32 06 e6 60 4f f0 08 07 55 f8
000020 04 6b 42 f8 04 6b bf f3 4f 8f 8d 42 28 bf 00 f1
000030 08 05 01 3f f3 d1 26 69 16 f0 01 0f fb d1 05 4f
000040 3e 42 03 d1 45 60 01 3b db d1 01 e0 00 27 47 60
000050 30 46 00 be 00 00 ee 03 ff ff ff ff ff ff ff ff
000060 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
*
000100

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.