uint64_t auf STM32F103

Doran S. schrieb:
> Ich benutze den arm-none-eabi-gcc und im Anhang ist mein makefile.

Du meinst, der Bug steckt im Makefile?

Vermutlich steht in Zeile 42 des source codes oder linker scripts oder 
startup codes "if uint64_t, then fail"...

Oliver

Hallo,

hatte vermutet, dass eventuell eine Compiler-Option fehlerhaft sein 
könnte, daher das Makefile...

Der Code, der Ärger macht sieht so aus:

1

write_byte(0x04);    // FTWO 45.01MHz

2

write_byte(0x5C);

3

write_byte(0x2E);

4

write_byte(0x33);

5

write_byte(0xF0);

6

7

uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) / ((uint64_t)(125000)));

8

write_byte(0x04);    // FTWO

9

write_byte(0xFF & (FTW >> 24));

10

write_byte(0xFF & (FTW >> 16));

11

write_byte(0xFF & (FTW >> 8));

12

write_byte(0xFF & FTW);

Die stdint.h ist natürlich eingebunden. Woran könnte der Fehler liegen?

Doran S. schrieb:
> uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) /
> ((uint64_t)(125000)));

Sicher daß deine DDS mit 125kHz läuft? Oder sind es nicht eher 125 MHz?

Hallo,

Ja, der DDS läuft natürlich mit 125MHz. Ich rechne aber in kHz, daher 
passt das. Der Fehler muss aber in der gezeigten Zeile liegen, denn wenn 
ich diese Zeile z.B. durch

1

uint32_t FTW = 0x5C28F5C3;

 ersetze, dann geht alles.

Ich kann auch z.B. den Compiler-Output bereitstellen, oder den gesamten 
Quellcode, falls dies hilft? Was benötigt ihr?

Wie groß is freq?

Am C-Code iegt es in der Zeile nicht. Wenn Ram insgesamt knapp ist, 
könnten die 64-Bit-Routinen natürlich das Faß zum überlaufen bringen, 
aber so wirklich glaube ich da nicht dran.

Oliver

Hallo,

der RAM ist sehr gering ausgelastet, der Linker gibt folgendes aus:

1

Memory region         Used Size  Region Size  %age Used

2

           Flash:        5312 B       256 KB      2.03%

3

           SRAM0:          28 B        64 KB      0.04%

freq = 14000.

Hat sonst noch jemand Tipps?
So sieht die entsprechende Stelle disassembliert aus:

1

    uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) / ((uint64_t)(125000)));

2

 8000d2a:  2300        movs  r3, #0

3

 8000d2c:  4a1a        ldr  r2, [pc, #104]  ; (8000d98 <configure_AD9951+0xd8>)

4

 8000d2e:  4629        mov  r1, r5

5

 8000d30:  4620        mov  r0, r4

6

 8000d32:  f7ff f9e3   bl  80000fc <__aeabi_uldivmod>

7

 8000d36:  4605        mov  r5, r0

Vielen Dank schon mal.

(4294967296 * 14000) / 12500 != 1546188227 (0x5C28F5C3)

Vincent H. schrieb:
> (4294967296 * 14000) / 12500 != 1546188227 (0x5C28F5C3)

Das stimmt, aber:
(4294967296 * 14000) / 125000 = 481036337 (0x1CAC0831).
Und auch wenn ich

1

uint32_t FTW = (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) / ((uint64_t)(125000)));

durch

1

uint32_t FTW = 0x1CAC0831;

ersetze, funktioniert es. Das Problem muss deshalb in der Berechnung 
liegen...

Hat noch jemand einen Tipp?

leo schrieb:
> Das ist sicher keine 64bit Operation.

Ich denke doch. r1:r0 /% r3:r2

1

 8000d2a:  2300        movs  r3, #0

2

 8000d2c:  4a1a        ldr  r2, [pc, #104]  ; (8000d98 <configure_AD9951+0xd8>)

vmtl steht an Adresse 8000d98 der Wert 125000

1

 8000d2e:  4629        mov  r1, r5

2

 8000d30:  4620        mov  r0, r4

vmtl das Produkt von vorher

Frank M. schrieb:
> Du meinst, der Bug steckt im Makefile?

Vielleicht. Wenn er die falsche Lib erwischt.

An Adresse 080000fc steht:

1

080000fc <__aeabi_uldivmod>:

2

 80000fc:  b953        cbnz  r3, 8000114 <__aeabi_uldivmod+0x18>

3

 80000fe:  b94a        cbnz  r2, 8000114 <__aeabi_uldivmod+0x18>

4

 8000100:  2900        cmp  r1, #0

5

 8000102:  bf08        it  eq

6

 8000104:  2800        cmpeq  r0, #0

7

 8000106:  bf1c        itt  ne

8

 8000108:  f04f 31ff   movne.w  r1, #4294967295  ; 0xffffffff

9

 800010c:  f04f 30ff   movne.w  r0, #4294967295  ; 0xffffffff

10

 8000110:  f000 b97a   b.w  8000408 <__aeabi_idiv0>

11

 8000114:  f1ad 0c08   sub.w  ip, sp, #8

12

 8000118:  e96d ce04   strd  ip, lr, [sp, #-16]!

13

 800011c:  f000 f806   bl  800012c <__udivmoddi4>

14

 8000120:  f8dd e004   ldr.w  lr, [sp, #4]

15

 8000124:  e9dd 2302   ldrd  r2, r3, [sp, #8]

16

 8000128:  b004        add  sp, #16

17

 800012a:  4770        bx  lr

Leider kenne ich mich mit Assembler nicht so aus. Hilft dies weiter?

Mr.T schrieb:
> Springt er in eine Exception (Hard Fault,...)?

Habe versucht, eine LED im Hard Fault Handler blinken zu lassen, aber da 
kommt nichts...

Doran S. schrieb:
> 800011c:  f000 f806   bl  800012c <__udivmoddi4>

Dann mach da mal weiter. Der Code oben testet nur auf Division durch 0.

An Adresse 800012c steht eine sehr lange Funktion, siehe Datei anbei.

Vielleicht ist es das alte Stack-Alignment-Problem. Zeig mal das ganze 
Linkerscript und den Startupcode. Was sagt der Debugger zum Crash? 
Hard-Fault? Register-Inhalte, insb. SP? An welcher Stelle crasht es 
genau?

Was ist das "alte Stack-Alignment-Problem"? Das kenne ich nicht.

Das Linker-Skript sieht so aus:

1

ENTRY(_reset)

2

3

MEMORY {

4

  Flash (rx):  ORIGIN = 0x08000000, LENGTH = 256K

5

  SRAM0 (rwx): ORIGIN = 0x20000000, LENGTH = 64K

6

}

7

8

_stack_end = ORIGIN(SRAM0) + LENGTH(SRAM0);

9

10

SECTIONS {

11

  .text : {

12

    _text_section_start = .;

13

    KEEP(*(._vectors))

14

    *(.text)

15

    *(.text*)

16

    *(.rodata .rodata.* .constdata .constdata.*)

17

    _text_section_end = .;

18

  } > Flash

19

20

  . = ALIGN(4);

21

22

  .bss : {

23

    _bss_section_start = .;

24

    *(.bss)

25

    *(.bss*)

26

    _bss_section_end = .;

27

  } > SRAM0

28

29

  . = ALIGN(4);

30

31

  .data : {

32

    _data_section_start = .;

33

    *(.data)

34

    *(.data*)

35

    _data_section_end = .;

36

  } > SRAM0 AT > Flash

37

}

Mit dem Debugger kann ich leider nicht ran, weil die Hardware nur einen 
UART-Anschluss hat (über den ich flashe). Gibt es Alternativen? Kann man 
das irgendwie simulieren?

Doran S. schrieb:
> Was ist das "alte Stack-Alignment-Problem"? Das kenne ich nicht.

Bei manchen Beispiel-Linker-Scripten von ST ist der initiale 
Stack-Pointer falsch gesetzt, sodass er ein falsches Alignment hat, und 
dann das Speichern von 64bit-Werten auf dem Stack scheitert. Das scheint 
hier aber nicht der Fall zu sein.

Doran S. schrieb:
> Mit dem Debugger kann ich leider nicht ran, weil die Hardware nur einen
> UART-Anschluss hat

Fehler Nr. 1 beim Hardware-Design...

Doran S. schrieb:
> Gibt es Alternativen? Kann man
> das irgendwie simulieren?

z.B. mit einem anderen STM32F103-Board. Keil µVision kann auch STM32 
simulieren.

Wenn ich das gesamte Projekt als gepacktes Archiv hochlade, könnte dann 
jemand, der eine Hardware mit Debug-Möglichkeit hat, das mal bei sich 
ausprobieren? Vielleicht hat ja mein Controller einen Hardware-Schaden?

Hallo,

habe noch so ein Board gefunden: 
https://www.reichelt.de/evaluationboard-stm32-value-line-discovery-stm32-vldiscov-p219361.html?&trstct=pos_14
Darauf habe ich das selbe Problem. Man kann also die Hardware 
ausschließen.

Auf dem Board ist ja ein ST-Link. Kann ich damit debuggen?

Hallo,

ich komme einfach nicht weiter. In Keil uVision muss ich mich erst 
einarbeiten. Anbei jedoch das komplette Programm als Disassemble. Wer 
darin den Fehler findet und mir beibringen kann, was schief gelaufen 
ist, bekommt von mir ein 1X16 LCD als Weihnachtsgeschenk zugesendet.

Hallo,

anbei das komplette Projekt als ZIP-Archiv. Ich benutze keine IDE, 
sondern gebe im Terminal "make" ein.

Hallo,

oh, das habe ich übersehen. Im Anhang eine Version ohne Deaktivierung 
der Debug-Schnittstelle. Das Problem besteht trotzdem noch.

Es ist eine selbst entwickelte Platine. Der Controller ist der 
STM32F103RCT6.

Hallo,

das tut mir Leid, ich habe aber tatsächlich in der letzten Version keine 
Deaktivierung der Debug-Schnittstelle mehr drin. Die Datei STM32F100.c 
ist entsprechend angepasst.

Vielen Dank aber trotzdem für Deine Mühe. Bin eh ganz durcheinander, 
weil ich das heute den ganzen Tag versucht habe. Vielen Dank für die 
Tipps von allen Seiten.

Das Angebot steht aber noch.

Hallo,

an PA13, PA14 und PA15 hängt Peripherie. Deshalb brauche ich diese als 
"normale" Ausgänge. Wenn ich es wieder aktiviere, dann funktioniert 
natürlich manche Peripherie nicht mehr, aber der Fehler, dass der 
Mikrocontroller kein Programm mehr ausführt, besteht immer noch.

1

// PA13, PA14 and PA15 as normal GPIO

2

RCC->APB2ENR |= (0x01 << 0);

3

AFIO->MAPR |= (0x04 << 24);

Diese Zeilen habe ich darum in der zweiten Version auskommentiert.

Wenn Du noch weitere Infos brauchst, kann ich diese natürlich liefern.

Viele Grüße!

OT512 schrieb:
> Vielleicht entwickelt der Compiler (uint64_t)(0x100000000) zu Null?

Dann wäre es kein C oder C++ Compiler.

Oliver

Johannes S. schrieb:
>> (0x04 << 24);
>
> Wird das nicht 0?

Bei 16-Bittern schon. Aber nicht bei einem 32-Bitter.

Man könnte auch Räucherstäbchen anzünden, und einen Datentyp-Voodoo-Tanz 
aufführen.

Oliver

Hallo,

vielen Dank für die hilfreichen Antworten an alle.
Also, wenn ich das EmBitz-Projekt von STM Apprentice kompiliere (und mit 
"stm32flash -w F103_uint64_Test.hex -v -R -i -dtr,rts,-rts:dtr,rts,-rts 
/dev/ttyUSB0") flashe, dann geht es! Es muss also irgendwie an den 
Einstellungen (Compiler, Linker) liegen....

Habe mal wie von Dieter Graef vorgeschlagen -lgcc bei den Linker-Flags 
hinzugefügt, aber das hat keine Änderung verursacht.

Auch macht es keinen Unterschied ob ich uint64_t oder int64_t 
benutze....

Bin echt ratlos. Hat noch jemand eine Idee?

Johannes S. schrieb:
> beim gcc auf einem F407 mit gcc kompiliert wird das richtig gerechnet:
>

1

>     uint64_t freq = 14000;

2

>     uint32_t FTW = (uint32_t)((0x100000000ULL * freq) / 125000ULL);

3

>     printf("testvar: %lx\n", FTW);

4

>

> output:
> testvar: 1cac0831

Cool, wie hast Du compiliert? (Welche Compiler- und 
Linker-Einstellungen?)

Doran S. schrieb:
> ich komme einfach nicht weiter.

Hilf dir doch selbst. Reduziere das Programm auf ein Minimum, welches 
immer noch den Fehler hat - idealerweise nur eine main()-Funktion mit 
eine paar wenigen Zeilen, ganz ohne jegliche Ansteuerung externer 
Peripherie. Du kannst ja ggf. eine LED einschalten o.ä. um zu sehen ob 
es noch läuft, auf der tatsächlichen Hardware ohne Debug-Möglichkeit.

Stelle sicher dass die Division tatsächlich zur Laufzeit durchgeführt 
wird, und nicht vom Compiler wegoptimiert. Eine Möglichkeit das zu 
tricksen wäre z.B.:

1

uint32_t test (uint32_t freq) __attribute__ ((noinline));

2

uint32_t test (uint32_t freq) {

3

  return (uint32_t)(((uint64_t)(0x100000000) * (uint64_t)(freq)) / ((uint64_t)(125000)));

4

}

5

6

int main () {

7

  test (1234);

8

}

Das Ergebnis-Programm mit Fehler spielst du dann auf ein 
STM32F103-Eval-Board, debuggst es mit einem ST-Link und gehst es Schritt 
für Schritt durch bis es abstürzt. Dieses Programm 
(Code+Kompilat/ELF-Datei) kannst du dann auch hier hochladen damit wir 
es auch ausprobieren können.

Warum steht im Code eigentlich was von STM32F100 während es aber ein 
STM32F103 sein soll? Nicht dass der Takt oder Power-Management falsch 
initialisiert wird oder so. Das kann alle möglichen kuriosen Effekte 
haben.

Hallo,

bin nun einen Schritt weiter: Wenn ich mein Linker-Skript (STM32F100.ld) 
und meinen Startup-Code (crt0.c) durch den vom Projekt von "STM 
Apprentice" ersetze, dann geht es. Mein Fehler ist also entweder im 
Startup-Code und/oder im Linker-Skript. Kann jemand erkennen, was im 
einem Startup-Code oder Linker-Skript fehlt?

Doran S. schrieb:
> Kann jemand erkennen, was im
> einem Startup-Code oder Linker-Skript fehlt?

Im Linkerscript fehlt vor dem "_bss_section_start", dem 
"_bss_section_end", "_data_section_start", "_data_section_end", 
"__end__", "(*.stack)" jeweils ein ".=ALIGN(4)". Wo hast du das kaputte 
Linkerscript her? Warum nimmst du nicht eins von der IDE oder aus 
STM32Cube?

Ist denn die Definition des Interrupt-Vektor im Startup-Code korrekt und 
für deinen Controller passend?

Hallo,

also, das Problem war letztendlich das Linker-Skript.
(Und als ich das korrekte von dem Projekt von "STM
Apprentice" zusammen mit einem Startup-Code "crt0.c" verwendet hatte, 
hat es nicht funktioniert, weil ein paar Namen (von Sections) anders 
sind. Nachdem ich das korrigiert hatte, hat es funktioniert.)

Um sowas in Zukunft besser zu können, möchte ich mehr über 
Linker-Skripte lernen. Kann mir jemand Literatur oder ein Tutorial dazu 
empfehlen?

Außerdem ist mir nicht so ganz klar, was die einzelnen Sections 
bedeuten, also wozu der Prozessor diese benötigt.

Was liegt in .init? Was in .fini? Was ist das .eh_frame? .ARM.extab und 
.ARM.exidx? Wo kann man diese Dinge lernen?

Vielen Dank an alle für die vielen Tipps, die dann zur Lösung geführt 
haben.

Ein Problem bleibt: Wem schicke ich nun das Display? ;-)