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?
Angehängte Dateien:
-
weak_txd.png
66 KB -
IMG_2689.JPG
300 KB
:
Bearbeitet durch User
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?
Angehängte Dateien:
-
04-12-_2023_12-01-25.png
47 KB -
r32c-r5f64524kfd_pinout_uart-pgm.png
340 KB -
mcu_conn_serial.png
35 KB
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
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.
Angehängte Dateien:
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.
:
Bearbeitet durch User
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?
Angehängte Dateien:
-
uart_fine.png
49 KB
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
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.
:
Bearbeitet durch User
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.