MSP430FR5739 Port schaltet nicht

Klaus R. schrieb:
> Die LEDs sind an P2.7 und P3.7 angeschlossen.

Mit Vorwiderstand? Sonst -> Port kaputt.

und:

WDTCTL = WDTPW | WDTHOLD;

ist besser als "+"

Und dann:
wie schnell ist denn dein Systemtakt?
100000 cycles können unsichtbar schnell rum sein...

Joe F. schrieb:
> Klaus R. schrieb:
>> Die LEDs sind an P2.7 und P3.7 angeschlossen.
>
> Mit Vorwiderstand? Sonst -> Port kaputt.

Ja klar. Die LEDs werden über einen Vorwiderstand angesteuert. Das Board 
kommt ja von OLIMEX. Und ich selber kenne mich auch damit ein wenig aus.

Das der Port oder die Ports defekt sind glaube ich auch nicht. Ich hatte 
ja nach dem erfolgreichen Test des geladenen, mir unbekannten Programms 
sofort mit der Programmierung begonnen. Zu dem habe ich noch ein zweites 
Board. Das zeigte das gleiche Verhalten. Der Oszi kam erst später dazu. 
Alles auf einer Arbeitsfläche mit ESD-Schutz.

Die Frage wäre, sind die MSP430FRxxx in Sachen IO-Ports unterschiedlich 
zu den MSP430Fxxxx - Typen? Im Datenblatt und den TI-Demos konnte ich 
nichts erkennen.
mfg klaus

Klaus R. schrieb:
> sind die MSP430FRxxx in Sachen IO-Ports unterschiedlich
> zu den MSP430Fxxxx - Typen?

Eigentlich nur bei der genauen Pinbelegung. Und natürlich LOCKLPM5, das 
du vergessen hast.

Aber zu den FR57xx gibt es ein User's Guide und Beispielprogramme, also 
brauchst du dich um Fxxx gar nicht kümmern.

Hallo Klaus,

schau noch mal in das Fammily User Guide bzw Datasheet.
Hab grad keines zur hand, aber ich hab mir da auch ein wenig zeit mit 
vergeudet.
Die FR modelle haben ein PORT lock register welches jegliche IO änderung 
verhindert.

hier was ich mache in den ersten zeilen von main() an einem MSPFR5969

<snip>
  P2SEL1 |= BIT0 | BIT1;                    // USCI_A0 UART operation
  P2SEL0 &= ~(BIT0 | BIT1);

  P2SEL1 |= BIT5 | BIT6; // eUSCSI_A1  P2.5 & P2.6
  P2SEL0 &= ~(BIT5 | BIT6);


 // Disable the GPIO power-on default high-impedance mode to activate
  // previously configured port settings
  PM5CTL0 &= ~LOCKLPM5;
<snap>

vielleich hilft das.

mfG
Peter

Vielen Dank an euch beide.

 PM5CTL0 &= ~LOCKLPM5; löst das Problem leider nicht.

Peter C. schrieb:
> Die FR modelle haben ein PORT lock register welches jegliche IO änderung
> verhindert.

Dieses Lock-Register habe ich noch nicht entdeckt. Was ich gefunden habe 
ist ein Schutz in Verbindung mit JTAG.

"The JTAG security lock key resides at the end of the 
bootloader(BSL)memory at addresses..."
http://www.ti.com/lit/ug/slau320x/slau320x.pdf

Ich hoffe ich komme mit dem Lock-Register für IOs weiter.

Ich habe mal alle P1 - Ports abwechselnd auf low und high gesetzt. Es 
sieht nicht gut aus. P1.0 - P1.5 sind immer low, P1.6 und P1.7 sind 
immer high.

###########################
Habe gerade entdeckt das ich die ganze Zeit beim IAR im Debugg-Mode den 
Simulator verwendet habe. Gewöhnlich arbeite ich mit dem CCS6. Es gab 
aber mal ein Fall da kam ich nur mit dem IAR weiter.

Mein erster Versuch lief unter dem CCS6 und konnte den Code nicht auf 
das Device laden. Der IAR meckerte nicht und deshalb habe ich das 
Ladeproblem nicht weiter verfolgt.

Das IAR - Log sieht wie folgt aus:

Thu Aug 25, 2016 22:23:02: Using license: Standalone license - IAR 
Embedded Workbench for Texas Instruments MSP430, 8K KickStart Edition 
6.40
Thu Aug 25, 2016 22:23:02: Firmware version 2.0.0.7
Thu Aug 25, 2016 22:23:02: Interface dll version 2.0.0.7
Thu Aug 25, 2016 22:23:03: Device : MSP430FR5739
Thu Aug 25, 2016 22:23:03: External voltage : 0.0 V
Thu Aug 25, 2016 22:23:03: VCC voltage : 0.0 V
Thu Aug 25, 2016 22:23:05: Failed to get device
Thu Aug 25, 2016 22:23:06: Could not write device memory : (WriteMemory) 
, address=0xc200, buffer=1@, count=0xa0
Thu Aug 25, 2016 22:23:08: Could not write device memory : (WriteMemory) 
, address=0xc200, buffer=1@, count=0xa0
Thu Aug 25, 2016 22:23:10: Could not write device memory : (WriteMemory) 
, address=0xc200, buffer=1@, count=0xa0
Thu Aug 25, 2016 22:23:12: Could not write device memory : (WriteMemory) 
, address=0xc200, buffer=1@, count=0xa0
Thu Aug 25, 2016 22:23:14: Could not write device memory : (WriteMemory) 
, address=0xc200, buffer=1@, count=0xa0
Thu Aug 25, 2016 22:23:17: Could not write device memory : (WriteMemory) 
, address=0xc200, buffer=1@, count=0xa0
Thu Aug 25, 2016 22:23:19: Could not write device memory : (WriteMemory) 
, address=0xc200, buffer=1@, count=0xa0
Thu Aug 25, 2016 22:23:19: Trying to initialize target failed
Thu Aug 25, 2016 22:23:25: Fatal error: Closing debug session   Session 
aborted!
Thu Aug 25, 2016 22:23:25: Failed to load debugee: H:\Entwicklung\IAR 
Workbench\Workbench_6_4\MSP430FR57x Demo - Toggle 
LED\Debug\Exe\Demo_Toggle LED.d43

Das Board wird vom JTAG mit ca. 3,04 V gespeist. Das von OLIMEX geladene 
Programm lief ja auch.

Thu Aug 25, 2016 22:23:03: External voltage : 0.0 V

Ist klar, ich habe nichts eingespeist.

Thu Aug 25, 2016 22:23:03: VCC voltage : 0.0 V

Welche dies ist ist mir unklar. Das Board hatte 3,04V, was ja auch 
reicht.

Thu Aug 25, 2016 22:23:05: Failed to get device

In den Options ist unter Debugger zwischen FET Debugger und Simulator zu 
wählen. Gewählt ist der FET Debugger.

Unter FET-Debugger ist Connection auf Olimex USB und Automatic 
eingestellt.
(läuft nicht)
Das Ändern von Automatic auf TNV2 0000000 brachte auch keine Änderung.

Man sie das der JTAG angesprochen wird. Neben der grünen LED abeitet 
auch die rote LED.

Bis morgen!
KLaus

Klaus R. schrieb:
> Als Programmieradapter habe ich von OLIMEX den JTAG-TINY-V2.

Bist Du Dir sicher, daß der überhaupt den 'FR5739 unterstützt?

Seitdem TI die eigenen Programmieradapter praktisch verschenkt, sehe ich 
keinen Grund mehr, die Olimex-Klone mit ihren frickeligen 
Installationsprozeduren zu verwenden.

Für den 'FR5739 gibt es von TI ein "Experimenter Board", auf dem ein 
passender SBW-Adapter verbraut ist:

http://www.ti.com/tool/msp-exp430fr5739

Klaus R. schrieb:
> PM5CTL0 &= ~LOCKLPM5; löst das Problem leider nicht.
>
> Peter C. schrieb:
>> Die FR modelle haben ein PORT lock register welches jegliche IO änderung
>> verhindert.
>
> Dieses Lock-Register habe ich noch nicht entdeckt.

Doch, hast du.  :-)

> Was ich gefunden habe ist ein Schutz in Verbindung mit JTAG.

Wenn du damit herumspielst, bist du möglicherweise erfolgreich und 
sperrst dich aus.

> Failed to load debugee

Und da ist das Problem.

Rufus Τ. F. schrieb:
> Bist Du Dir sicher, daß der überhaupt den 'FR5739 unterstützt?

Ist in der Liste von Olimex.

Clemens L. schrieb:
> Rufus Τ. F. schrieb:
>> Bist Du Dir sicher, daß der überhaupt den 'FR5739 unterstützt?
>
> Ist in der Liste von Olimex.

Die Liste war mir auch bekannt. Danach hatte ich vor dem Kauf des 
MSP430-HFR5739 schon geschaut.

Ich werde gleich den JTAG mit mit dem MSP430-CCRF testen und schauen ob 
das Board noch ansprechbar ist. Der JTAG von OLIMEX soll ja auch etwas 
empfindlich sein
mfg klaus

Hallo,
der MSP430-CCRF, ein OLIMEX-Board mit dem CC430F5137 läuft 
erwartungsgemäß (unter dem IAR 6.4 gestestet). Das Board läßt sich 
programmieren und läuft dann mit dem veränderten Code.

Clemens L. schrieb:
> Wenn du damit herumspielst, bist du möglicherweise erfolgreich und
> sperrst dich aus.

Gespielt habe ich nicht gerade. Es wurde nur der simple LED-Blinking 
Programm versucht zu laden.

Also doch das Port-Lock Register? Dagegen spricht ja eigentlich, das der 
ursprünglich, von OLIMEX geladene Source, nicht mehr läuft. So wie ich 
das verstehe, sollte ja gerade der Port-Lock den JTAG sperren, um den 
Code zu sichern.

mfg klaus

Klaus R. schrieb:
> So wie ich das verstehe, sollte ja gerade der Port-Lock den JTAG sperren

Portlock != JTAG-Fuse.

Zwei unterschiedliche Baustellen.