Forum: Mikrocontroller und Digitale Elektronik Keine UART Programmierung bei R32C möglich


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Olli Z. (z80freak)


Angehängte Dateien:

Lesenswert?

Ich versuche eine R32C (Group 152) MCU per UART mode 2 zu programmieren. 
Diese ist in einem Board eingelötet und alle notwendigen Pins liegen auf 
einem Debug-Header. Die MCU Pins sind alle laut Datenblatt beschaltet, 
sodass eine UART-Kommunikation möglich sein sollte (u.a. CNVSS and 
HIGH).

Zur Kommunikation nutze ich einen (original) FTDI Adapter (USB) mit 5V 
Pegel für RX/TX. Auf dem DSO sehe ich das er versucht beim senden den 
Pegel runter zu ziehen, es aber nicht schafft (Sendeversuch eines 0x00). 
Klemme ich die TXD Leitung vom Board ab, ist das Signal am FTDI 
einwandfrei.

Ich habe auch schon andere Serial-Adapter versucht und auch einen 
Levelshifter (mit 2 Transistoren) dazwischen gesetzt um etwas mehr Drain 
zu erhalten, leider alles ohne Erfolg/Änderung.

Auf dem Board sind keine weiteren Pull-Ups/Downs am Signalpfad, die Pins 
gehen direkt zu einem Debug-Header.

Ich kann mir einfach nicht vorstellen das die MCU so am Signalpegel 
ziehen soll das dieser einbricht. Ebensowenig das der FDTI nicht genug 
Strom liefert um den Pegel zu halten. Die Gesamt-Stromaufnahme im 
Programmiermodus beträgt 50mA.

Kann das jemand erklären bzw. kennt dieses Problem?

: Bearbeitet durch User
von M. K. (sylaina)


Lesenswert?

Olli Z. schrieb:
> Kann das jemand erklären bzw. kennt dieses Problem?

Spontan würde ich sagen, der RX des Mikrocontrollers ist nicht als 
Eingang beschaltet...du bist doch mit dem TX des FTDIs an den RX des 
Mikrocontrollers gegangen und nicht an den TX des 
Mikrocontrollers...oder?...ODER?

von Olli Z. (z80freak)



Lesenswert?

M. K. schrieb:
> Spontan würde ich sagen, der RX des Mikrocontrollers ist nicht als
> Eingang beschaltet...du bist doch mit dem TX des FTDIs an den RX des
> Mikrocontrollers gegangen und nicht an den TX des

RX zu RX, TX zu TX. So ist es normalerweise gedacht, aber ich habe es 
auch gekreuzt versucht.

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Olli Z. schrieb:
> RX zu RX, TX zu TX. So ist es normalerweise gedacht

Nee. So ist es normalerweise komplett falsch. RX ist ein Eingang, TX ist 
ein Ausgang. Oder irgendjemand hat deinen FTDI-Adapter sehr merkwürdig 
beschriftet.

Ohne angeschlossenem UART-Adapter solltest Du am TX-Ausgang des µC einen 
High-Pegel messen, und der RX-Eingang sollte hochohmig sein.

von Olli Z. (z80freak)


Lesenswert?

Harald K. schrieb:
> Ohne angeschlossenem UART-Adapter solltest Du am TX-Ausgang des µC einen
> High-Pegel messen, und der RX-Eingang sollte hochohmig sein.

Beide haben 5V im Ruhepegel, was aber mit internen Pull-Ups normal sein 
dürfte. So oder so sollte der FDTI den Pegel auf Low ziehen können, auch 
wenn die MCU was anderes meint. Die liefert max. 5mA am Ausgang und die 
internen Pull-Ups sind eher 47k oder mehr.

von M. K. (sylaina)


Angehängte Dateien:

Lesenswert?

Olli Z. schrieb:
> RX zu RX, TX zu TX. So ist es normalerweise gedacht

Glaub ich nicht. Hab mal aus dem Datenblatt zum FT232B geklaut. Wie du 
sehen kannst wird TXD so gezeichnet, dass der Pfeil vom Chip weg zeigt, 
d.h. da kommen Daten raus. Und bei deinem Mikrocontroller ist es genau 
das Selbe: Der TXD-Pfeil zeigt vom Chip weg, d.h. da kommen Daten raus 
und gehen nicht rein. Deshalb immer: TX ->-> RX und RX <-<- TX und nie 
RX <--> RX und TX -><- TX. Extra mit Pfeilen gezeichnet und damit es 
überhaupt funktionieren kann müssen die Pfeile immer in die selbe 
Richtung zeigen, nie gegeneinander oder voneinander weg ;)

von Andreas B. (bitverdreher)


Lesenswert?

Wenn ich mir das hier anschaue:
https://www.renesas.com/us/en/document/apn/r32c100-series-rewriting-flash-memory-using-serial-interface-uart
dann werden dabei Pin 7_0 (TxD2) und 7_1 (RxD2) verwendet.

von Rolf (rolf22)


Lesenswert?

Olli Z. schrieb:
>> RX zu RX, TX zu TX. So ist es normalerweise gedacht

> Glaub ich nicht. Hab mal aus dem Datenblatt zum FT232B geklaut.

Diese beiden Anschlüsse werden auf den Platinen oft andersherum 
beschriftet, da kann man nie sicher sein.

Der Hintergrund ist die ursprüngliche Nutzung von RS-232. Da war RX am 
Terminal (DTE) ein Eingang, am Modem (DCE) aber ein Ausgang. So konnte 
man RX und TX ohne Überkreuzen verbinden. Die Namen haben die Leitungen 
bezeichnet (RX = vom Modem über die DFÜ-Fernleitung empfangene und dem 
DTE übergebene Daten)
https://de.wikipedia.org/wiki/RS-232

Heutzutage sind die Rollen nicht so klar. Der Rechner kann die Rolle 
eines DTE oder eines DEE spielen und wenn man z. B. ein FTDI verwendet, 
sitzt praktisch  auf beiden Seiten ein Rechner.

von Rolf (rolf22)


Lesenswert?

Olli Z. schrieb:
> So oder so sollte der FDTI den Pegel auf Low ziehen können, auch
> wenn die MCU was anderes meint.

Jedenfalls dürfen Ausgänge nicht gegeneinander arbeiten. Die 
Pin-Belegungen solltest du also unter allen Umständen zunächst durch 
Messungen sicher feststellen.
Z. B. kannst du bei getrennter Leitung Widerstände anschließen, dann 
siehst du, wer was wohin ziehen kann.

(Beim Messen kann man übrigens reinfallen, wenn der FTDI seine 
Masse/Versorgung über die USB-Buchse vom PC bekommt und das Messgerät 
seine Masse/Versorgung anderswoher aus dem Stromnetz.)

von Olli Z. (z80freak)


Angehängte Dateien:

Lesenswert?

Andreas B. schrieb:
> Wenn ich mir das hier anschaue:
> 
https://www.renesas.com/us/en/document/apn/r32c100-series-rewriting-flash-memory-using-serial-interface-uart
> dann werden dabei Pin 7_0 (TxD2) und 7_1 (RxD2) verwendet.

Danke für den Tipp. Ich habe hier 
Beitrag "Re: Keine UART Programmierung bei R32C möglich" ja den Auszug aus 
dem Datenblatt des Group 152 R32C gepostet und da ist es halt UART1. Das 
wird je nach Modell leicht unterschiedlich sein. Bei meinem ist es aber 
wohl Pin 6_6 (RDX) und 6_7 (TXD).

Aber nochmal: Es liegt ganz sicher nicht an verdrehter RX/TX Leitung. 
Das war das erste was ich getestet habe. Die Gründe wurden inzwischen ja 
genannt warum man sich da nicht immer nur auf die Beschriftungen 
verlassen kann.

: Bearbeitet durch User
von Rolf (rolf22)


Lesenswert?

Olli Z. schrieb:
> So oder so sollte der FDTI den Pegel auf Low ziehen können, auch
> wenn die MCU was anderes meint. Die liefert max. 5mA am Ausgang und die
> internen Pull-Ups sind eher 47k oder mehr.

Wenn ich das Datenblatt richtig verstehe, schafft sie max. 10 mA (Seite 
96).
Und wo steht, wieviel der FTDI schafft?

Wenn Rx am µP ein Ausgang ist, wäre das beobachtete Verhalten klar. Ob 
es ein Ausgang ist oder nicht, bestimmt aber die Software.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Lesenswert?

Du hast doch sicherlich auch die Masseleitung des FTDI-Adapters mit dem 
Board verbunden? Ansonsten fällt auf, dass die Baugruppe offenbar mit 
einem Conformal Coating überzogen ist. Befinden sich vielleicht 
Lackreste auf den Pins des Debugsteckers?

von Olli Z. (z80freak)


Angehängte Dateien:

Lesenswert?

Der Fehler ist gefunden! (mit Hilfe von Dieter S.)
Mein Pinout war falsch. Am Debug-Header liegt nicht wie dokumentiert 
RXD, das muss man sich woanders vom Board abgreifen (warum auch immer).

Jetzt funktioniert es und ja, natürlich muss man FTDI RX zu R32C TX und 
umgekehrt verbinden. Ich erhalte nun auf ein 0xFB (Bootloader Version 
Abfrage) wie erwartet ein "VER.1.01".

Das Signal ist nun auch sauber und benötigt auch keinerlei Verstärkung.

Ich bedanke mich trotzdem für die rege Beteiligung und Hilfestellung bei 
der Fehlersuche! Manchmal hat man einfach Tomaten auf den Augen...

: Bearbeitet durch User
von Vanye R. (vanye_rijan)


Lesenswert?

Ich wuerde ja erstmal die anderen Leitungen (CNVSS/EPM) kontrollieren. 
Der Bootloader braucht die. Und er muss auch zwisch sync/async 
unterscheiden.

Gibt es eigentlich mittlerweile einen Gcc fuea die R32? ich dachte 
dafuer gab es nur den Renesas fuer 2000Euro. Dann sollte doch auch ein 
original debugger drin sein.

vanye

von Olli Z. (z80freak)


Lesenswert?

Vanye R. schrieb:
> Gibt es eigentlich mittlerweile einen Gcc fuea die R32? ich dachte
Vielleicht geht der? https://people.redhat.com/~dj/m32c/

von Olli Z. (z80freak)


Lesenswert?

"Wie gewonnen so zerronnen" - nachdem ich die Hardware-Probleme gelöst 
hatte wollte ich ans Flashen gehen.

Dazu habe ich das FDT (Flash Development Toolkit) in der Version 4.09 
von Renesas verwendet. Damit konnte ich den gesamten Flash (User, Data 
und E2Data) problemlos auslesen
1
Clock Frequency (External) = N/A, Clock Mode = N/A, CKM = N/A, and CKP = N/A
2
Connecting to device 'R5F64524' on 'COM6'
3
Configuration:
4
'BOOT Mode' connection - using emulated interface
5
Opening port 'COM6' ...
6
Loading Comms DLL
7
Loaded Comms DLL
8
Initiating BOOT SCI sequence
9
Attempting 9600
10
Changing baud rate to 57600 bps
11
ID code check successful
12
E2 Data Flash initialised: ECC Off
13
Device protection is currently set for this device (parallel mode only)
14
Connection complete
15
Lock Bit Disabled
16
17
All blocks marked as unknown written status
18
19
Reading 784 K from device
20
Read User Flash (0xFFF40000 - 0xFFFFFFFF)
21
  [Raw Checksum: 0x06666824]
22
Read Data Flash (0x00060000 - 0x00061FFF)
23
  [Raw Checksum: 0x001DE9E1]
24
Read E2 Data Flash (0x00062000 - 0x00063FFF)
25
  [Raw Checksum: 0x000A29CF]
26
Successfully read 784 K from device
27
28
ID Code = 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

Danach habe ich versucht den kompletten Flash mit der "Erase" Funktion 
zu löschen um das runtergeladene Image wieder drauf zu speichern.

Aber bereits beim löschen des UserFlash gibt es Probleme:
1
Erasing 14 blocks from device
2
Erasing... 'EB13'...
3
Erased block EB13 (0xFFF40000 - 0xFFF4FFFF)
4
Erasing... 'EB12'...
5
Erased block EB12 (0xFFF50000 - 0xFFF5FFFF)
6
Erasing... 'EB11'...
7
Erased block EB11 (0xFFF60000 - 0xFFF6FFFF)
8
Erasing... 'EB10'...
9
Erased block EB10 (0xFFF70000 - 0xFFF7FFFF)
10
Erasing... 'EB9'...
11
Erased block EB9 (0xFFF80000 - 0xFFF8FFFF)
12
Erasing... 'EB8'...
13
Erased block EB8 (0xFFF90000 - 0xFFF9FFFF)
14
Erasing... 'EB7'...
15
Error No 15005: 'COM6' read time out
16
Error No 15025: Erase failed
17
Operation failed

Ich habe dann, jeweils mit einem Reset dazwischen, jeden Block einzeln 
gelöscht, das hat am Ende dann geklappt. Aber so sollte es ja nicht 
sein?!

Das Programmieren wiederum verlief beim UserFlash dann unproblematisch
1
rocessing file :"C:\Users\og\AppData\Local\Renesas\FDT4.09\Workspaces\BCM\oldBCM.DDI"
2
Operation on User Flash
3
Writing image to device... [0xFFF40000 - 0xFFFB94FF]
4
Writing image to device... [0xFFFB9800 - 0xFFFBE3FF]
5
Writing image to device... [0xFFFDFF00 - 0xFFFE01FF]
6
Writing image to device... [0xFFFE0200 - 0xFFFE02FF]
7
Writing image to device... [0xFFFE0300 - 0xFFFE20FF]
8
Writing image to device... [0xFFFE2100 - 0xFFFE21FF]
9
Writing image to device... [0xFFFE2400 - 0xFFFEEFFF]
10
Writing image to device... [0xFFFF8000 - 0xFFFFA6FF]
11
Writing image to device... [0xFFFFF800 - 0xFFFFFCFF]
12
Writing image to device... [0xFFFFFF00 - 0xFFFFFFFF]
13
Data programmed at the following positions:
14
 0xFFF40000 - 0xFFFB94FF      Length : 0x00079500
15
 0xFFFB9800 - 0xFFFBE3FF      Length : 0x00004C00
16
 0xFFFDFF00 - 0xFFFE01FF      Length : 0x00000300
17
 0xFFFE0200 - 0xFFFE02FF      Length : 0x00000100
18
 0xFFFE0300 - 0xFFFE20FF      Length : 0x00001E00
19
 0xFFFE2100 - 0xFFFE21FF      Length : 0x00000100
20
 0xFFFE2400 - 0xFFFEEFFF      Length : 0x0000CC00
21
 0xFFFF8000 - 0xFFFFA6FF      Length : 0x00002700
22
 0xFFFFF800 - 0xFFFFFCFF      Length : 0x00000500
23
 0xFFFFFF00 - 0xFFFFFFFF      Length : 0x00000100
24
575.25 K programmed in 147 seconds
25
Device CRC = 0xD933, File CRC = 0xD933 (range 0xFFF40000-0xFFFFFFFF) -> CRC Check OK

Den DataFlash konnte ich ohne Probleme löschen und programmieren
1
Erasing 2 blocks from device
2
Erasing... 'EBB'...
3
Erased block EBB (0x00060000 - 0x00060FFF)
4
Erasing... 'EBA'...
5
Erased block EBA (0x00061000 - 0x00061FFF)
6
Erase complete
7
8
Writing image to device... [0x00060000 - 0x000600FF]
9
Writing image to device... [0x00061000 - 0x000611FF]
10
Data programmed at the following positions:
11
 0x00060000 - 0x000600FF      Length : 0x00000100
12
 0x00061000 - 0x000611FF      Length : 0x00000200
13
768 Bytes programmed in 0 seconds
14
Device CRC = 0x2819, File CRC = 0x2819 (range 0x00060000-0x00061FFF) -> CRC Check OK

Aber beim E2 Data Flash beiße ich mir gerade die Zähne aus:
1
Erasing 1 block from device
2
Erasing... 'E2Data0'...
3
Error No 15005: 'COM6' read time out
4
Error No 15005: 'COM6' read time out
5
Error No 15005: 'COM6' read time out
6
...
Da er "nur" einen Timeout brachte aber nicht von selbst abbrach, habe 
ich ihn einfach mal laufen lassen. Nach laaaanger Wartezeit kam 
irgendwann ein Complete:
1
...
2
Error No 15005: 'COM6' read time out
3
Error No 15005: 'COM6' read time out
4
Erased block E2Data0 (0x00062000 - 0x00063FFF)
5
Erase complete

Danach habe ich versucht zu programmieren:
1
Operation on E2 Data Flash
2
Writing image to device... [0x00062000 - 0x0006206F]
3
Error No 15005: 'COM6' read time out
4
Error No 17775: Detected Write Error state in E2 Data Flash
5
Error No 17159: Unable to download file
6
Operation failed

Wenn ich den E2 Data Flash zurücklese bekomme ich so ein "halb 
gelöschtes" Flash, d.H. im Vergleich zum vorherigen Inhalt sind sehr 
viele Bytes auf FF gesetzt worden, aber eben nicht alle.

Auch dauert der Lesevorgang des E2 Flash im Vergleich zu den anderen und 
seiner Größe von nur 8KB extrem lange (ca. 5 Minuten).

von Vanye R. (vanye_rijan)


Lesenswert?

Spannungsversorgung korrekt?
Sobalb die MCU ihre internen DCDC
Wandler hochfaehrt nimmt sie deutlich mehr Leistung auf.

Vanye

von Olli Z. (z80freak)


Lesenswert?

Vanye R. schrieb:
> Spannungsversorgung korrekt?
Danke Vanye, ja, die Spannung und Stromaufnahme sind stabil und nach 
Datenblatt richtig. Hängt an einem Labornetzteil. Die Timeouts kommen 
nicht daher.

: Bearbeitet durch User
von Soul E. (soul_eye)


Lesenswert?

Olli Z. schrieb:
> Danach habe ich versucht den kompletten Flash mit der "Erase" Funktion
> zu löschen um das runtergeladene Image wieder drauf zu speichern.

Guck Dir mal die Reset-Leitung an. Vielleicht ist Dein SBC der Ansicht, 
sein Long Window wäre jetzt zu Ende und man müsste mal den Watchdog 
triggern. Da die Applikation auf dem R32C das nicht tut, gibt es einen 
Reset.

Oft haben die SBC einen Pin, mit dem man den Watchdog zum Flashen 
deaktivieren kann. Bei Infineon heisst der TEST.

von Olli Z. (z80freak)


Lesenswert?

Soul E. schrieb:
> Oft haben die SBC einen Pin, mit dem man den Watchdog zum Flashen
> deaktivieren kann. Bei Infineon heisst der TEST.

Danke, den hatteich bereits gefunden und deaktiviert. Hier muss eine 
Spannung >=7V angelegt werden, dann löst er nicht aus. Das ist leider 
auch nicht das Problem.

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.