RS485 Probleme zwischen Mikrocontroller und PC

Wie macht sich denn die teilweise nicht funktionierende Kommunikation 
bemerkbar?
Springen Bits oder fehlen Bytes?
Schonmal den EFM32 mit nem Debugger benutzt und einen Fehler gefunden?

Marcel D. schrieb:
> Zwischen den Paketen schläft der Controller und wird per USART-Interrupt
> geweckt.

Das Schlafen würde ich mal testweise unterlassen. Wie lange dauert es, 
bis der µC aus dem Schlaf heraus wieder komplett arbeitsfähig ist? Ich 
weiß zumindest, dass bei AVRs je nach "Tiefe" des Schlafs schon eine 
gewisse Zeit vergehen kann.

Björn G. schrieb:
> Wie macht sich denn die teilweise nicht funktionierende Kommunikation
> bemerkbar?
> Springen Bits oder fehlen Bytes?
> Schonmal den EFM32 mit nem Debugger benutzt und einen Fehler gefunden?

Die macht sich bemerkbar in dem einfach nicht mehr aufgewacht wird bzw. 
die While-Schleife auf der PC-Seite nicht verlassen wird. Da der 
Interrupt auf dem µC schon beim ersten Bit springt, muss das Problem 
wohl auf der PC-Seite sein. Es scheint als würde er manchmal willkürlich 
Daten empfangen und aus der Schleife raus springen oder keine Antwort 
empfangen und in der Schleife bleiben. Die Implementierung am Controller 
sollte so funktionieren wie sie ist, habe damit das Hauptprogramm 
geschrieben, welches der Bootloader schreiben soll. Dort funktioniert 
alles einwandfrei, auch von der PC-Seite aus.

Das Schlafen ist übrigens kein Problem, laut Datenblatt ist der 
Controller aus EM1 sofort wieder da. Erst in den darunter liegenden Modi 
benötigt er wake-up-time.

Hallo Marcel,

hast Du die Möglicheit, in die RS485-Kommunikation eine Art Sniffer zu 
hängen und so mal mitzuschneiden, was denn da tatsächlich auf dem Bus 
passiert?
So ist es schon mal leichter, en Fehler auf PC oder uC einzugrenzen. 
Weiterhin glaube ich nichts blind, was in Datenblättern behauptet wird, 
da ich schon zu oft Bugs im Prozessor hatte, die noch nicht mal im 
Errata standen.

Kay Imperator schrieb:
> Hallo Marcel,
>
> hast Du die Möglicheit, in die RS485-Kommunikation eine Art Sniffer zu
> hängen und so mal mitzuschneiden, was denn da tatsächlich auf dem Bus
> passiert?

Könnte n LogicAnalyzer an den Bus packen und schauen was so läuft.
Müsste ich morgen mal ausprobieren wie gut das so klappt.

Ich denke wie gesagt aber nicht, dass mir der EnergyMode dazwischen 
funkt, die Abfrage des Busses ist Interrupt gesteuert und bedarf keiner 
weiteren Aktivität außer bei einem Signal das Register zu leeren. 
Außerdem funktioniert es, wie gesagt, in einem anderen Programm 
einwandfrei und das sogar mit 3,5MBaud/s ( statt wie jetzt mit 1MBaud/s 
).
Schauen was der LogicAnalyzer so bringt...

Man könnte noch versuchen, ein paar Test-Byte zu Fuß zu schicken, 
während der uC schläft und auf seine Daten wartet ...
z.B. mit einem irgend einem Serial-Terminal und dann sehen, wie der uC 
reagiert.

Wäre z.B. mit diesem Tool recht komfortabel:
http://www.heise.de/download/hterm.html

Marcel D. schrieb:
> Zwischen den Paketen schläft der Controller und wird per USART-Interrupt
> geweckt.

Ich mache das immer grundsätzlich so, daß ich zuerst nur die Funktion 
implementiere.
Und erst, wenn alles einwandfrei läuft, überlege ich, ob Stromsparen 
einen Effekt haben könnte und füge es dann hinzu.

Habe nun anscheinend den Fehler gefunden, mein PC-Programm schickte ab 
und an ein paar Nullen zuviel mit auf den Weg, was meinen Controller 
durcheinander brachte. Bin nun auf die Boost-API umgestiegen, diese 
erledigt den Job doch weitaus besser und alles läuft nun einwandfrei bis 
auf das Springen zur Zieladresse. Versuche es gerade mit diesen 
Funktionen

1

void BOOT_jump(uint32_t sp, uint32_t pc)

2

{

3

  (void) sp;

4

  (void) pc;

5

  /* Set new MSP, PSP based on SP (r0)*/

6

  __asm("msr msp, r0");

7

  __asm("msr psp, r0");

8

9

  /* Jump to PC (r1)*/

10

  __asm("mov pc, r1");

11

}

12

13

void BOOT_boot(void)

14

{

15

  uint32_t pc, sp;

16

17

  uint32_t *bootAddress = (uint32_t *)(0x4000 + 0x0100);

18

19

  /* Set new vector table */

20

  SCB->VTOR = (uint32_t)bootAddress;

21

22

  /* Read new SP and PC from vector table */

23

  sp = bootAddress[0];

24

  pc = bootAddress[1];

25

26

  /* Do a jump by loading the PC and SP into the CPU registers */

27

  BOOT_jump(sp, pc);

28

}

Leider springt er mir immer wieder nur an den Anfang des Programms 
zurück, nicht an meine neue FW. Habe das andere Programm mit einer 
abgeänderten Linker-File gefüttert, damit diese erst ab Adresse 0x4000 
anfängt.

1

MEMORY

2

{

3

  FLASH (rx) : ORIGIN = 0x00004000, LENGTH = 16384

4

  RAM (rwx)  : ORIGIN = 0x20000000, LENGTH = 4096

5

}

Hab ich da was übersehen? >_>

@Jonny:
- Bin ist 11KB groß
- Ja, er kann sie speichern
- Wird ab Adresse 0x4000 bis 0x6890 gespeichert :)