LPC2378 SD-Karte blockiert Reset

[Horst (Gast)]

Hallo Forum,

ohne jetzt viel zu erklären und Code zu posten:

Was kann den LPC2378 daran hindern bei einem Reset per Taster diesen 
auch auszuführen? Es hilft erst ein PowerOn Reset oder das Entfernen der 
SD-Karte.

Zum Einsatz kommt FatFS von Chan und ich habe sein Beispiel V 0.10a 
inkl. MCI lowlevel Treiber für den LPC23xx in mein Projekt integriert. 
Ich führe momentan nur die Karteninitialisierung durch und versuche 
danach den Kartenstatus abzufragen. Mit dem Dateisystem an sich mache 
ich noch gar nichts.

Die Initialisierung scheint (meist) zu klappen.
Zumindest kann ich das anhand einiger eingefügter Debug ausgaben 
nachvollziehen.
Die erste Statusabfrage klappt auch.
Bei der zweiten Statusabfrage der Karte via FS_showDiskStatus() hängt 
sich das Programm auf und zeigt oben genanntes Verhalten.

Was kann den da so blockieren? Wenn ich das verstehe, kann ich auch 
besser nach dem Problem suchen...
Hat jemand eine Idee?

Auch wenn es vermutlich nicht viel hilft, anbei die Terminalausgabe der 
Initialisierung und der Statusabfrage...

di
After power_on()
CMD0 (1: success): 1
Card is 'idle' state
CardType: 12
Card is 'ready' state
Card is 'ident' state
CardRCA: 58916
Card is 'stby' state
Card is 'tran' state
Set wide bus mode
rc=0

du
rc=0
Drive size: 15523840 sectors
Erase block size: 24576 sectors
Card type: SDv2(Block)
CSD:
00000000: 40 0E 00 32 5B 59 00 00 3B 37 7F 80 0A 40 40 AE @..2[Y..;7...@@.
CID:
00000000: 03 53 44 53 55 30 38 47 80 71 8B A0 C5 00 BB 4E .SDSU08G.q.....N
OCR:
00000000: C0 FF 80 00 ....

du
þ

di löst die Initialisierung der Karte aus
du fragt den Status ab
nach der zweiten Statusabfrage hängt das System

Die Karte ist eine 8GB SDHC

[Horst (Gast)]

Noch als Nachtrag, wenn das System blockiert, wird nach dem Entfernen 
der SD-Karte sofort neugestartet...

[leluno (Gast)]

Beim LPC1768-Beispielcode von chan hat die Pinbelegung nicht gestimmt. 
Den Low-Level-Teil überprüfen, ob sck, miso, mosi und cs richtig 
initialisiert sind.

[Horst (Gast)]

Ich bekomme aber doch bei der Initialisierung gültige Daten...
CardType: 12 besagt dass es eine SDHC (Version 2) mit Blockadressing 
ist, was auch stimmt.

Die 1. Statusabfrage liefert auch Daten (die mir aber nicht so viel 
sagen).
Erst beim 2. Versuch folgt der Absturz...

Mich wundert halt, dass der Controller dann so richtig weg ist, so dass 
auch kein Reset per Reset-Taster mehr hilft...

[Horst (Gast)]

Das ist ja auch reproduzierbar.
Ein "di" also eine neue Initialisierung nach dem ersten "du" führt auch 
zum Absturz...

[leluno (Gast)]

wird da nicht irgendwann die spi-Geschwindigkeit umgeschaltet? CPOl und 
CPHA richtig eingestellt?

[Jim M. (turboj)]

Horst schrieb:
> Erase block size: 24576 sectors

Uh oh. Das ist IIRC im SD_STATUS Register, und ich hatte hier mal einen 
Kartentyp der sich beim Lesen dieses Registers derart aufgehängt hat, 
dass nur ein Power-cycle half.

Übrigens kennen SD Karten keinen Reset - man muss dafür die 
Stromversorgung abklemmen.

[Horst (Gast)]

Jim Meba schrieb:
> Übrigens kennen SD Karten keinen Reset - man muss dafür die
> Stromversorgung abklemmen.

Das ist mir bekannt, trotzdem eine gute Idee das mal auszuprobieren.
Nur die Karte zu resetten. Dann weiß ich, dass sich die Karte 
aufhängt...

[Horst (Gast)]

leluno schrieb:
> wird da nicht irgendwann die spi-Geschwindigkeit umgeschaltet? CPOl und
> CPHA richtig eingestellt?

Die Geschwindigkeit wird irgendwann erhöht. Es handelt sich hier aber 
nicht um SPI sondern um MCI...

[Horst (Gast)]

Jim Meba schrieb:
> Horst schrieb:
>> Erase block size: 24576 sectors
>
> Uh oh. Das ist IIRC im SD_STATUS Register, und ich hatte hier mal einen
> Kartentyp der sich beim Lesen dieses Registers derart aufgehängt hat,
> dass nur ein Power-cycle half.

Aber warum reproduzierbar beim zweiten Aufruf? Und das bei mindestens 6 
verschiedenen Karten von mindestens 3 Herstellern...

[Horst (Gast)]

Die MCI lowlevel Funktionen von Chan arbeiten mit zwei IRQs (MCI und 
DMA), das hat meine alte implementation nicht gemacht.
Evtl. gibt es auch ein Problem mit nested IRQs... aber eigentlich ist 
mir das Auftreten des Problems dafür zu reproduzierbar beim zweiten 
Aufruf...

[W.S. (Gast)]

Das sieht mir nach einem Software-Schlamper-problem aus: Chan ist einer 
dieser Gesellen, die partout drauf bestehen, beim Initialisieren einen 
auf 0 geputzten RAM vorzufinden - bloß weil es irgendwo mal in einer 
C-Beschreibung stand, daß man davon ausgehen dürfte, daß aller 
Speicherplatz beim Systemstart abgelöscht sei.

Ich hatte mit Chan's FF auch seltsame Probleme dieser Art (aber ohne 
DMA), die sich verflüchtigten, als ich in dessen Init-Routine das 
Ablöschen globaler Variablen nachträglich eingebaut hatte.

W.S.

[Horst (Gast)]

Hm, ich geh eigentlich auch davon aus, dass globale Variablen implizit 
mit 0 initialisiert werden.
Sehe aber auch den Zusammenhang mit meinem Problem nicht...
Beim 1. Durchlauf tut es doch!

[Horst (Gast)]

Horst schrieb:
> Jim Meba schrieb:
>> Übrigens kennen SD Karten keinen Reset - man muss dafür die
>> Stromversorgung abklemmen.
>
> Das ist mir bekannt, trotzdem eine gute Idee das mal auszuprobieren.
> Nur die Karte zu resetten. Dann weiß ich, dass sich die Karte
> aufhängt...

Also wenn ich im Fehlerfall manuell die Versorgungsspannung der SD-Karte 
wegnehme, dann startet der uController sofort neu...

Hilft mir jetzt aber auch nicht so wahnsinnig viel weiter?!

[Horst (Gast)]

So, habe mich mal wieder der SD Karte gewidmet und folgendes 
rausgefunden.
Wenn ich eine etwas kleinere Version meines Programmes aufspiele, dann 
kann ich auch bei der 8 GB Karte mehrfach den Status abfragen.

Folgendes Programm macht keine Probleme:

LPC2378 with 32 kB {0x7FFF} SRAM and 0x3400 kB fixed for Stack leaves 0x4BFF = 19455 kB for application! bss + data?
Size after:
   text     data      bss      dec      hex  filename
 132132      476    11860   144468    23454  fat_mci_demo.elf

fat_mci_demo.elf  :
section              size         addr
.text              132132            0
.data                 476   1073741824
.initdata             476       132132
.bss                 9452   1073742300
.stack              13312   1073751752
.usbram              2408   2144337920
.comment             1134            0
.debug_aranges       5840            0
.debug_pubnames     17569            0
.debug_info         92207            0
.debug_abbrev       24291            0
.debug_line         47429            0
.debug_frame        13608            0
.debug_str          26055            0
.debug_loc          68098            0
.debug_macinfo    2446589            0
.ARM.attributes        16            0
.debug_ranges        9984            0
Total             2911076

Bei diesem steigt es nach der 2. Statusabfrage aus:

LPC2378 with 32 kB {0x7FFF} SRAM and 0x3400 kB fixed for Stack leaves 0x4BFF = 19455 kB for application! bss + data?
Size after:
   text     data      bss      dec      hex  filename
 147800      484    13372   161656    27778  fat_mci_demo.elf

fat_mci_demo.elf  :
section              size         addr
.text              147800            0
.data                 484   1073741824
.initdata             484       147800
.bss                10412   1073742308
.stack              13312   1073752720
.usbram              2960   2144337920
.comment             1134            0
.debug_aranges       6080            0
.debug_pubnames     19264            0
.debug_info         95723            0
.debug_abbrev       24831            0
.debug_line         48880            0
.debug_frame        14348            0
.debug_str          27693            0
.debug_loc          69883            0
.debug_macinfo    2483910            0
.ARM.attributes        16            0
.debug_ranges       10208            0
Total             2977422

Ich vermute daher nun eher ein Problem mit dem SRAM bzw. Stack.

Momentanes Eclipse Setup (installed software list):
  - Eclipse Standard/SDK Kepler V 4.3.1
    - Eclipse Platform
    - Eclipse Standard/SDK Feature
  - Autotools support for CDT
  - C/C++ GDB Hardware Debugging
  - Embedded Systems Register Viw (SFR)
  - EmbSysRegView Data
  - Visual C++ support

  - OpenOCD 0.7.0

Kann ich mit OpenOCD und GDB irgendwie den SRAM Verbrauch bzw. den Stack 
zur Laufzeit ansehen? Kann man auf einen Zugriff auf eine bestimmte RAM 
Adresse triggern? Ich arbeite noch nicht so lange mit Eclipse und 
OpenOCD und kenne mich da nicht so gut aus.
Wäre über Hilfe sehr erfreut.

[Grundschüler (Gast)]

Horst schrieb:
> Kann ich mit OpenOCD und GDB irgendwie den SRAM Verbrauch bzw. den Stack
> zur Laufzeit ansehen?

bei codeRed geht das. Da diese IDE auch auf Eclipse basiert, müsste es 
bei dir auch gehen.

Wenn du ein lcd hast, kannst du dir an verschiedenen Stellen im Code den 
Speicherinhalt anzeigen lassen. Das hilft manchmal weiter.

Für DMA muss der Speicherbereich festgelegt werden:
__SECTION(data,RAM1) uint8_t buffer[25600];
uint8_t *buf_rx =buffer+20480;
uint8_t *buf_tx =buffer+20992;