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
Nö, weiß ich nicht. Es gibt aber den STM32Cube Programmer. Auch für Linux und auch als Kommandozeilen Version.
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
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
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
Hallo Markus, beim H7 steht die CHIP-ID bei 0x5C001000
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
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!
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.
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
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.
@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'
In der Tat wohl zu alt. Die relevanten Patches sind: http://openocd.zylin.com/#/c/4181/ http://openocd.zylin.com/#/c/4182/
@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
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.
@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
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
@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
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
> 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
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.
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.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.