Hallo Forum, ich möchte mich an einen UART eines BF531 dranhängen, bekomme aber keinen Output. Kann sein, daß der BF gar nicht sendet, oder ich habe des Interface nicht richtig angebunden. Ich verwende einen Waveshare FT232 USB TO UART converter. Siehe: https://vi.vipr.ebaydesc.com/ws/eBayISAPI.dll?ViewItemDescV4&item=281991786343&t=1524048470000&tid=7710&category=36327&seller=eckstein_komponente&excSoj=1&excTrk=1&lsite=77&ittenable=false&domain=ebay.de&descgauge=1&cspheader=1&oneClk=1&secureDesc=1 Danke für sachdienliche Hinweise. Markus PS.: Baudraten habe ich bis 1MBit ausprobiert mit 8N1 und anderen 8Bit Kombinationen.
Angehängte Dateien:
-
UART_with_10k_Pullups.jpg
150 KB
:
Bearbeitet durch User
An Deiner Stelle würde ich mir jemanden mit einem Oszilloskop suchen. Alles andere ist nur Rätselraten...
Moin, also, abgesehen vom Oszi Tip, die klassische Checkliste: - Loopback-Test mit dem USB-UART-Adapter gemacht? - RX/TX <-> TX/RX richtig? (Output muss jeweils mit Input verbunden sein) Wenn dir das System komplett unbekannt ist und du die Firmware nicht kennst, musst du dich für genauere Bestimmung über den JTAG reinklinken, der liegt da ja vor wie auf dem Präsentierteller.
@Strubi, dass mit dem JTAG reinklinken, habe ich mir schon gedacht. Das der USB2UART funktioniert, dass habe ich schon mit einem LA getestet. Am Anfang hatte ich keine Pullups am BF RX/TX Ein-/Ausgang (Pin# 81/82), dann meinte jemand da gehören Pullups hin, bis dato hatte ich noch nie welche am UART, hab aber trotzdem mal 10k rein gemacht. 10k deshalb da mir nicht klar ist ob der BF531 nicht auch welche intern aktiviert hat. Am JTAG wollte ich mich noch nicht, mangels Erfahrung, hin hängen, da es aber wohl darauf hinausläuft, muss ich noch auf einen zweiten USB2(UART/JTAG) Adapter aus China warten. (siehe Link) https://www.ebay.de/itm/CJMCU-2232-FT2232HL-USB-TURN-UART-FIFO-SPI-I2C-JTAG-RS232-Module-External-Memory/162805799360?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 Ist schon seit zwei Wochen auf dem Weg und sollte bald ankommen. @Henry Du schaust auf des Innenleben eines solchen. Zwei halte ich für zu protzig ;-) Markus
Moin, die Pullups sind nicht nötig. Nur bei RX (eingang CPU) werden Pullups rangemacht, damit bei undefinierten Pegeln keine wildgewordenen Interrupt-Requests den Boot-Prozess unterbrechen bzw. zum Abstürzen bringen. In deinem Fall also nicht nötig. Was haste im Sinn, Rigol/Instek der neueren Generation reverse engineeren? Platine kommt mir irgendwie bekannt vor, nur die JTAG-Nadelpads sind mir neu...
Angehängte Dateien:
@Strubi, fast, aber doch noch etwas daneben. Den ersten Brand inkrementieren (Rigol++)=? habe es ja schon fast verraten ;-) Wollte mal sehen, was der BF531 so beim Booten treibt. Das einzige was ich sehe (auf beiden Leitungen) ist nur das Hochspringen der Pegel beim Einschalten. Sonst aber keine Kommunikation auf TX. Also keine Console oder uBoot Ausgabe. Ich habe gelesen, das es zum BF von AD keine freien Tools, wie openOCD oder openJTAG die mit dem DSP reden können. Hast Du da gegenteilige Infos? Gibt es was freies für die BF Processoren? Markus
Hi Markus, ich kenne nur ein paar Varianten der Rigol-Firmware, die ist so ziemlich bare-metal, nix U-Boot, und nix GNU überhaupt. Die gegenteiligen Infos die nicht mehr so up to date sind: ADI könnte unter uClinux noch ein paar verwaiste Details und Source zu urJTAG (openjtag nachfolger) und dem ICEbear-Nachbau "gnICE" haben, guck mal blackfin.uclinux.org. Ansonsten: Wenn du gut funktionierende Reverse-Engineering-Tools zum BF brauchst, musst du bisschen in die Tasche greifen. Leider habe ich mit dem ADI-Kram durchwegs schlechte Erfahrungen gemacht, was Robustheit und Langzeitstabilität ihrer Debugger- und IDE-Lösungen angeht, ganz zu schweigen vom Respekt gegenüber der GPL. Darum haben wir damals für die GNU-Toolchain den ICEbear-Debugger entwickelt, aber schlussendlich die eigenen Sourcen auch nicht mehr unter GPL rausgegeben. Was du aber immer machen kannst: mit urJTAG per Boundary Scan das Flash auslesen. Das geht mit jedem FT2232H-Adapter.
Hallo Martin, das Flash bekommt man aus den Update Files (.ADS), das muss ich nicht auslesen. Habe die/das .LDR File. Wollte man mit qemu-bfin da mal rangehen, hat aber noch nicht geklappt. Bin aber dran. Ansonsten habe ich ein BF533 und BF561 AD Dev Board, aber kein VisualDSP++ dazu. Mit den Boards müsste ich eigentlich auch auf den Oszi BF kommen, muss mich aber da erst einlesen. Möglicherweise finde ich doch noch in meinem SW Kram eine zeitbeschränkte VisualDSP++ Version. Ich habe gedacht das wäre einfacher, aber AD hat da ja seine eigenen Zöpfe geflochten. Markus
Markus W. schrieb: > Ansonsten habe ich ein BF533 und BF561 AD Dev Board, > aber kein VisualDSP++ dazu Ich weiss ehrlich gesagt nicht, was für dich einfacher ist. Den Hack über die EZKITs hatte ich anfangs mal probiert, das ist für verlässliche Fehlersuche aber nix gewesen. Hatte sogar mal einen Treiber für die FT2232H mit VDSP gemacht, aber seit der 5.0 und diversen ELF-Verstümmelungen von Seiten der ADI-Tool-Guys flog der Kram in die Ecke. Falls du deinen eigenen Code draufladen willst, würde ich die GNU-Toolchain empfehlen.
Martin, mit eigenem Code meinst Du für den FT2232H - richtig? (den internen Controller, der USB nach GPIO umsetzt.) Markus
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.