@@ -384,7 +384,7 @@ <h3> 3. Makefile</h3>
384
384
cstartup.elf: cstartup.o
385
385
386
386
%.elf:
387
- @echo $@
387
+ @echo $@ from $+
388
388
$(CC) $(CPU) -T$(LD_SCRIPT) $(LDFLAGS) -nostartfiles -o $@ $+
389
389
$(SIZE) $@
390
390
$(OBJDUMP) -hS $@ > $(subst .elf,.lst,$@)
@@ -397,15 +397,26 @@ <h3> 3. Makefile</h3>
397
397
Finally, to keep track of the memory model and the load location, I put
398
398
the load address in the name of the binary file generated.
399
399
400
- < pre > all: $(PROJECT).$(BINLOC).bin $(PROJECT).hex</ pre >
400
+ < pre > all: $(PROJECT).hex $(PROJECT).$(BINLOC).bin</ pre >
401
+
402
+ With the corresponding rule
403
+
404
+ < pre >
405
+ %.$(BINLOC).bin: %.elf
406
+ @echo $@
407
+ $(OBJCOPY) -O binary $< $@
408
+ </ pre >
401
409
402
410
This way if I build uptime prototype in GORAM memory model
403
411
404
412
< pre >
405
413
$ make
406
- f030f4.elf
414
+ f030f4.elf from startup.ram.o txeie.o uptime.1.o libstm32.a
415
+ Memory region Used Size Region Size %age Used
416
+ FLASH: 1163 B 2 KB 56.79%
417
+ RAM: 208 B 2 KB 10.16%
407
418
text data bss dec hex filename
408
- 1164 0 20 1184 4a0 f030f4.elf
419
+ 1163 0 208 1371 55b f030f4.elf
409
420
f030f4.hex
410
421
f030f4.0x20000800.bin
411
422
</ pre >
@@ -419,19 +430,18 @@ <h3> 3. Makefile</h3>
419
430
420
431
< h2 > Caveat: stm32flash v0.6 intel hex bug</ h2 >
421
432
422
- At the time of writing, < b > stm32flash</ b > v0.6 has a bug that prevents
423
- writing intel hex files correctly at address other than the origin of
424
- the Flash. A bug fix and the possibility to directly read the base
425
- address from the intel hex file are planned to be included in v0.7.
433
+ < b > stm32flash</ b > v0.6 had a bug that prevents writing intel hex files
434
+ correctly at address other than the origin of the Flash. A bug fix and the
435
+ possibility to directly read the base address from the intel hex file was
436
+ merged in v0.7.
426
437
< p >
427
- Until v0.7 is out, I am using my own patched version of stm32flash or
428
- the binary files when I need to test GOFLASH and GORAM memory models.
429
- < p >
430
- As I branched off my own patched version of < b > stm32flash</ b > , I added a
438
+ I have branched off my own patched version of < b > stm32flash</ b > , I added a
431
439
< code > -x</ code > option to write and execute an intel hex file:
432
440
433
441
< pre > stm32flash -x file.hex COM#</ pre >
434
442
443
+ This patch is scheduled to be merged in v0.8.
444
+
435
445
< h2 > Testing</ h2 >
436
446
437
447
I build all four memory models and check that they can be loaded and
@@ -448,6 +458,6 @@ <h2>Checkpoint</h2>
448
458
< a href ="38_crc32.html "> Next</ a > , I will add integrity check at startup by
449
459
doing CRC32 validation of the code.
450
460
451
- < hr > © 2020-2024 Renaud Fivet
461
+ < hr > © 2020-2025 Renaud Fivet
452
462
</ body >
453
463
</ html>
0 commit comments