Forum: Mikrocontroller und Digitale Elektronik ATmega4809 UDPI probleme


von BesorgterBürger (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich möchte selbst etwas mit dem auslesen der Register oder schreiben der 
Fuses mit UDPI basteln. Im Datenblatt steht auch alles sehr schön 
beschrieben und ich habe mir das recht einfach vorgestellt (Vielleicht 
auch zu einfach)..

Die Hardware Beschaltung funktioniert. Ich konnte mit pyudpi.py den 
Controller Problemlos beschreiben. Habe mir das Programm mal angesehen 
bin aber noch nicht dahinter gekommen wie das ganze funktioniert.

Habe mir in C unter in Linux etwas gebastelt welches eine erste 
Instruktion sendet und auf die Rückgabe wartet nur mal um zu testen ob 
überhaupt was geht. Empfangen habe ich nur das was ich gesendet habe 
aber nichts vom Controller.

Eingestellt habe ich den UART so wie im Bild im Punkt Data Frame.
Gesendet habe ich dann hintereinander: (SYNC)85,(LDS)0,(ADDR)0

Habe auch rumprobiert mit das ich ein Wort empfange und oder sende, auch 
einen anderen Befehl wie STS welcher ja ein ACK zurück geben sollte 
welches ich nicht erhalten habe.

Was vielleicht hier noch wichtig wäre, wäre das senden eines Breaks, was 
ich aber in C nicht weiß, wie sowas zu realisieren ist..

Hat das jemand von euch schon mal gemacht? Habt ihr da Ideen dazu?

Vielen dank.

Mfg
BesorgterBürger

von S. Landolt (Gast)


Lesenswert?

> Hat das jemand von euch schon mal gemacht?
Ja. Allerdings auf einem ATmega1284P bzw. AVR128DA28 in Assembler.

> ich habe mir das recht einfach vorgestellt
Nun ja, wenn man sich sehr genau an das Datenblatt hält, dann klappt das 
auch - nach vielen Fehlversuchen, 'serial programming' der älteren AVR8 
ist dagegen ein Kinderspiel.

> Habt ihr da Ideen dazu?
Was genau ist nun die Frage?

> senden eines Breaks ... wie sowas zu realisieren
Ist schon eine Weile her - man muss dafür auf 300 Bd heruntergehen; 
müsste ich erst nachschauen.

von BesorgterBürger (Gast)


Lesenswert?

S. Landolt schrieb:
>> Hat das jemand von euch schon mal gemacht?
> Ja. Allerdings auf einem ATmega1284P bzw. AVR128DA28 in Assembler.

Primär bezog sich die frage auf das Auslesen des Flashs  Register  
Fuses oder das beschreiben dieser. Da hilft mir der Assembler recht 
wenig ^^

S. Landolt schrieb:
> Nun ja, wenn man sich sehr genau an das Datenblatt hält, dann klappt das
> auch - nach vielen Fehlversuchen, 'serial programming' der älteren AVR8
> ist dagegen ein Kinderspiel.

Ich weiß, klappte sogar auf anhieb.. Hilft mir aber bei UDPI nicht viel.

S. Landolt schrieb:
> Was genau ist nun die Frage?

Ich bekomme keine Rückantwort vom Controller. Warum? Hab ich irgendwas 
überlesen? Fehlt ein Byte? In meiner Übertragung ist 9600B eingestellt, 
sollte ja nicht zu schnell sein.

S. Landolt schrieb:
> Ist schon eine Weile her - man muss dafür auf 300 Bd heruntergehen;
> müsste ich erst nachschauen

Hab ich in dem Python Skript auch irgendwas gesehen aber habe nicht 
verstanden was da dann gesendet oder gemacht wurde..

von S. Landolt (Gast)


Lesenswert?

> 9600B eingestellt, sollte ja nicht zu schnell sein
Ich arbeite mit 200 kBd.

> habe nicht verstanden was da dann gesendet oder gemacht wurde..
'even parity, 2 stop-bits, 8 bits', Null-Character bei 300 Bd, ergibt 
ein Low von 30 ms, verlangt wird "Recommended BREAK Character Duration 
... 24.60 ms".

von S. Landolt (Gast)


Lesenswert?

> Empfangen habe ich ... nichts vom Controller
> Gesendet habe ich dann hintereinander: (SYNC)85,(LDS)0,(ADDR)0

Ohne vorangestelltes BREAK, wie in 30.3.2.1 UPDI Enable beschrieben, 
wird das wohl nicht klappen.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

@TO:
übrigens kannst dir auch gern den Code hier anschauen, falls das 
leichter lesbar sein sollte.

https://github.com/ElTangas/jtag2updi

: Bearbeitet durch User
von BesorgterBürger (Gast)


Lesenswert?

S. Landolt schrieb:
> 'even parity, 2 stop-bits, 8 bits', Null-Character bei 300 Bd, ergibt
> ein Low von 30 ms, verlangt wird "Recommended BREAK Character Duration
> ... 24.60 ms".

Kein Erfolg leider..

Veit D. schrieb:
> übrigens kannst dir auch gern den Code hier anschauen, falls das
> leichter lesbar sein sollte.
>
> https://github.com/ElTangas/jtag2updi

Danke, schaue ich mir an.

von S. Landolt (Gast)


Lesenswert?

Beispiel: lesen der Fuses SYSCFG0 und SYSCFG1, liefert C0 und 07:
alle Werte in hex, '/' bedeutet BREAK
1
snoopy_UPDI
2
 /
3
55 04 85 12 C0
4
55 04 86 12 07  /

von BesorgterBürger (Gast)


Angehängte Dateien:

Lesenswert?

S. Landolt schrieb:
> Beispiel: lesen der Fuses SYSCFG0 und SYSCFG1, liefert C0 und 07:
> alle Werte in hex, '/' bedeutet BREAK

Hab nun mal eine andere Sprache (Autoit) getestet falls ich evtl. 
Programmierfehler gemacht habe. Allerdings auch kein Erfolg.. Ich poste 
den Primitiven Code mal da die Sprache doch sehr offensichtlich ist, 
vielleicht entdeckt ja jemand der Erfahrung mit updi hat etwas..

Habe die Ausgabe mal angefügt, als Eingabe habe die von dir Angegebenen 
Fuses mal probiert. Keine Spur vom Controller. Mittels pyupdi habe ich 
kurz vorhin nochmal getestet ob die Hardware noch stimmt, keine 
Probleme, konnte etwas Auslesen..
Im Anhang ist noch zu sehen das ich versucht habe die zweite Fuse direkt 
danach anzusprechen. Die letzten zwei Zeilen mit den '00000000' sind 
nicht vom Controller.

Soweit ich es in pyupdi und https://github.com/ElTangas/jtag2updi 
verstanden habe, machen sie es sehr ähnlich, nur anders, da es bei mir 
nicht geht ^^
1
#Region---------------------------------------------------------------------------------Includes & NoTrayIcon
2
#NoTrayIcon
3
#include "CommMG.au3"
4
#EndRegion
5
6
#Region---------------------------------------------------------------------------------Globale Variablen
7
$comout = 0
8
$loop = 10
9
#EndRegion
10
11
;_CommSetport(Port, errors, baud, bits, parity, stop, flowcontrol)
12
$set1 = _CommSetport(5,0,300,8,1,2,0)
13
_CommSendByte(0)
14
;_CommSendByte(0)
15
;Sleep(30)
16
_CommClosePort()
17
18
$set1 = _CommSetport(5,0,9600,8,1,2,0)
19
_instruction()
20
21
While $loop
22
   $loop -= 1
23
   $comout = _CommReadByte()
24
   ConsoleWrite(hex($comout) & @CRLF)
25
   Sleep(10)
26
WEnd
27
_exit()
28
29
func _instruction()
30
   _CommSendByte(85)
31
   _CommSendByte(4)
32
   _CommSendByte(133)
33
   _CommSendByte(18)
34
35
   ;_CommSendByte(85)
36
   ;_CommSendByte(4)
37
   ;_CommSendByte(134)
38
   ;_CommSendByte(18)
39
EndFunc
40
41
func _exit()
42
   _CommClosePort()
43
   Exit
44
EndFunc

von S. Landolt (Gast)


Lesenswert?

Die '1' in _CommSetport(5,0,9600,8,1,2,0) bedeutet Even Parity?

von BesorgterBürger (Gast)


Lesenswert?

S. Landolt schrieb:
> Die '1' in _CommSetport(5,0,9600,8,1,2,0) bedeutet Even Parity?

Ja

von S. Landolt (Gast)


Lesenswert?

Was zeigt denn Ihr Protokoll-Programm, wenn Sie mit diesem pyupdi die 
Fuses lesen?

Notfalls muss man mit Logic-Analyzer oder Speicheroszilloskop 
protokollieren, auch wenn das etwas langwierig & mühsam wird.

von S. Landolt (Gast)


Lesenswert?

... oder eben ein kleines Programm für einen uC schreiben, der dann 
protokolliert.

von Axel R. (axlr)


Lesenswert?

Ich würde mir das auch mal mitm Oszi auf der seriellen Schnittstelle 
ansehen, ob das 'Break' hinhaut...

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
Noch kein Account? Hier anmelden.