Keine UART Programmierung bei R32C möglich

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?

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.

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.

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.

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 ;)

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.

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.

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.)

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.

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.

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?

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...

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

Vanye R. schrieb:

Gibt es eigentlich mittlerweile einen Gcc fuea die R32? ich dachte

Vielleicht geht der? https://people.redhat.com/~dj/m32c/

"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).

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

Vanye

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.

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.