Ezt próbáld meg megnövelni (sdcard.c):

Nálam annak idején STM32F103 esetén az írás csak 0x10 környékén volt stabil. Lehet csak annyi a probléma, hogy az SD kártyád nem bírja tartani a tempót.

A doksi amit küldtél STMCubeMX-et használ, azzal megint csak bajba leszek..
Full átláthatatlan a számomra.. Még... Kicsit tán ijesztő is, amit generál.

A legutóbbi kód amit linkeltél, a FatFs-es, az tök jó és átlátható mert sima SPL-t használ, semmi extrát. Ezzel már eljutottam odáig, hogy beolvasás, listázás és fájl létrehozás működik.
Az a része nem működik, (szerintem csak én bénázok) amely beír a létrehozott fájlba. (f_write()), kérdés miért? Lehet én nem jól használom, vagy lehet hibás ez a rész?

Így próbálkozom:

Lehet csak én nem veszek észre valamit és ezért nem működik...

Erre fut rá és : FR_INVALID_OBJECT
A meghívást feljebb látod, paraméterek szerintem jók, de lehet pont ott nem veszek észre valamit.

Növeltem rajta, sajna ráfut a hibára...

Az pedig eredetileg device: F407IG, át kel állítani F407ze-re

Próbáld meg így elnevezni a fájlt: "/teszt.bin"

Van ez a kapcsoló az ffconf.h-ban:


1 próbát megér!

És ezt is javítani kel:

Sajnos nem hozott eredményt, továbbra is FR_INVALID_OBJECT-re fut.

Termesztésen a projekt, amit létrehoztam alapból a megfelelő kontrollerre van állítva, független, hogy eredetileg a kód min volt.

Fentebb írt javaslatok alapján állítgattam a definíciókat, de sajnos sikereteken eredményt hozott, mindegyik.
A nyelv választásnál meg is hagytam a 858-asat.

Egyelőre tanácstalan vagyok, hogy mi lehet a hiba és miért fut minden aklommal erre a fránya FR_INVALID_OBJECT-re.
Dobtam fel két képet is, hogy mi van ilyenkor a file adat struktúrában.
Én arra tippelek, hogy nem megfelelő adatok vannak a struktúrában.

Közben annyira még rájöttem, hogy nem volt globális a struktúra azért nem tudta átadni egymásnak a függvény az adatokat. De ettől független még mindig nem jó, de már kicsivel tovább tud menni. Keresgélem a hibát tovább, előbb utóbb meglesz..

Szia!

Nem akarok belekontárkodni a beszélgetésbe, de a debug kép alapján azért bukik a dolog, mert az ID-k nem stimmelnek!
Ha ezt észrevetted akkor vedd tárgytalannak, amit írtam!


Itt neked az id=2, de az fs->id = 57853.

Valahol a fájlok "owner"-ei akadnak össze szerintem.

Igen, erre írtam, hogy nem volt globális a fájl információ.
Mindjárt teszek fel egy teszt projektet, abban lehetne kotorászni, hogy mi a bibi.

Ezt meg kel hivni:

disk_initialize(0); // Majd ez fogja meghívni a: SD_GetCardInfo(&SDCardInfo);
Ami lekérdezi a kártya adatait, hogy később tudjad mit használsz. És nem melékesen elvégez több hibaellenőrzést.

No készítettem egy teszt projektet: Bővebben: Link
Ha lenne időtök és megnéznétek azt megköszönném.
esetleg ha ki tudjátok próbálni az jó lenne.
Olvasás működik, fájl létrehozás is, de a fájlba írás nem..
Előre is köszi..

ui: A programban idáig eljutottam: f_write()Itt sajnos FR_DISK_ERR-el kilép, milvel clst-ben 0xFFFFFFFF van. (ebben tárolja a claster-t)
Még midig valahol elcsúsznak az adatok.

Igen, e nélkül szerintem az olvasás sem működne, sőt, semmi.
Ez benne van a kódban.
Feltettem egy teszt projektet, kukkants bele, hátha észreveszed a hibát.
Előre is köszi.

Már írtam, hogy részemről tárgytan az általad használ IAR IDE!

Mivel a demó változata csak 30 napos, annyi idő alatt még megtanulni sem lehet a használatát.
(Ezért is nem jelentkezhetett eddig senki hozzáértő!)

Én nem is erre gondoltam, de mivel én is tudtam a semmiből ismeretlen implementálni IAR környezet alá, gondolom ez nem lehet probléma egy nem kezdőnek, hogy implementálja a saját, kipróbált és rutinosan használt környezete alá.
Ha nincs is környezet, még mindig ott a kód, és az nem demo, hogy ne lehessen nézegetni.
De elfogadom, hogy nem akarsz vele kínlódni, de hátha akad erre felé majd valaki, aki meg tudja nézni.. Én meg persze addig is elvagyok vele, keresgetem a hibát.

Ez nem így működik, hogy csak te szeretnél segítséget kapni!
Segíts, hogy segítsenek!

Kértem, hogy Atolic-ben fejlesz, mert az ingyenes!
És az eredményt én is hasznosíthatnám.

Különben időközben kiderült, hogy a távol keleti betűkészletek használatára van kiélezve ez a project.
És ennek a megszüntetése túl sok munkával járna, ezért kerestem mást.

Van STM32F4DISCOVERI + BB készletem. Azon van működő kipróbált SD Fat program.
Csak átkel alakítani F407vg-ről, F407zet-re. És azon a boardon máshól vannak az egyéb HW-k is.

Szia!
Én használom Chan, SD kártya kezelő programját, igaz 8 bites kontrollerrel. Azt gondolom, hogy ha az inicializálás, olvasás megy, akkor nagy probléma nem lehet.
néhány ötlet:
A fejlesztések közben elő szokott fordulni, hogy nem sikerül jól lezárni a fájlokat, jól kilépni a rendszerből, ekkor a PC szoktam formattálni az SD-t.
Én a 852-es kódlapot használom, nem a 858-ast, igaz nem használok ékezetes betűket, Te is kipróbálhatnád ékezetes nélkül.
Nem tudom, hogy a

a karaktertömb végére kerül-e lezáró nulla, egy próbát megérne, hogy a végére tegyél egy "\0"-t.

Tehát feltételezhető, hogy kipróbáltad és próbáltad használni.
Neked működött rendesen? Meddig jutottál el vele?
Mely részét tesztelted ki, mielőtt dobtad?

Sajnos, 852-es kódlappal, ékezetek nélküli bejegyzéssel, és lezáró karakterrel sem jó.
Esetleg elkérhetem a te kódodat, vagy ki tudnád próbálni ezt amit én használok?
Csak a FatFs fájlokra gondolok, ott nincs specifikus dolog.

Amúgy addig eljutottam, hogy már aláfutásra hivatkozva hiúsul meg az írás.
Szerintem sincs itt nagy gond, főként mert minden más működik és a fájlt is létre tudja, hozni.. Az más kérdés, hogy nem tudja befejezni..
ui: még arra gyanakodom, amit említett kapu48, hogy ez a kód 411-re volt optimalizálva, én meg 407-en használnám. Bár akkor meg felvetődik a kérdés, hogy a többi, hogy a pékben mehet hibátlanul..

Nálam is ugyanez a verziójú ff.c, és ff.h fájlok vannak, mint nálad, csak az alacsony szintű kártya rutinok másak, mivel én SPI-ben használom, mert a 8 bites kontroller nem támogatja az SDIO 4 bites kommunikációt.
Egyébként én az SD használatát az f_mount-tal kezdem, nem kell előtte a disk_initialize, mert az, az ff.c-ben meghívódik, ahol kell. utána ugyanúgy használom, ahogy Te.

Néztem a diskio.c fájlodat és ott a get_fattime() rutin elég érdekes, mert nem fut le az idő és dátum DWORD-be való összerakása, az #if 0 miatt, csak 0-át ad vissza. Azt nem tudom, hogy ez befolyásolja-e a működést, de ezt a rutint meghívja mind az f_open, ha FA_CREATE_ALWAYS paraméterrel hívod meg, illetve az f_close() is.
Nálam ez így néz ki:


Itt van Chan honlapja:Bővebben: Link, ahol részletesen leírás található a működésről, bár már az R0.13b verzió fut.
És itt van egy innen elérhető link, Bővebben: Link, ahol Tilen Majerle STM32F4-re átírt verziója található, ami SPI-re és SDIO módra is tartalmaz kódot, hátha ez segít.

Köszi, de sajnos nem oldotta meg a problémát.
Tegnap már azt hittem meg lesz a hiba, de sajna tévedtem.
Beraktam egy másik kártyát és egyszer hibátlan lefutott a program, majd másodjára már nem és mikor megnéztem PC-ben a memkarit nem volt meg a file.
Szóval még midig problémás a dolog..

Annyira megint csak rájöttem, hogy a FAT kezeléssel lesz valami gondja a programnak.
Sajna nem hardveres, inkább szoftveres hiba van...
Az első képen a FAT tábla bejegyzései látszanak.
Win-ben felmásoltam egy fájlt, ami pontosan 1MB, az látszik is illetve a FAT bejegyzései mutatják, hogy helyes az adat. (128 szó lefoglalva)
Majd a többi fájl helyére nem került FAT bejegyzés.

sd_root képen az látszik, hogy az ecco.md fájlom típusa 0x20-as vagy is fájl, a többi bejegyzésnél, mivel nem történik lezárás nem tudja megadni a típusát és elhelyezkedését a fatáblában.

Az utolsó sd_bejegyzes-es képen pedig az látszik, hogy ha kézzel segítem végig debug módban, akkor a megfelelő klaszteren belül a megfelelő szektorba beírja a szöveget.
Majd sajnos a file lezárást is, segíteni kell, hogy teljes legyen a fájl.
Egyértelműen programhiba lesz, nem hiszem, hogy itt bármilyen beállítás vagy egyéb hardveres piszkálás segítene.
Sanszos, hogy a fájl írását és FAT tábla kezelését újra kellene írnom, vagy legalább is megpatkolni a mostani hibásan működő kódot. Pazar....
Kicsit szomorú vagyok, mert jól átlátható ez a program, de a sok struktúra miatt elég necces lesz ezt megpatkolni, lehet egy másikat kellene inkább keresni.

Mi a bajod a bekarikazott nullakkal? Azok szabalyos file-ok, csak nem "Archive"-ok. Mindegyik 0 byte hosszu.

Az a baj, hogy nem fejeződik be, vagy is nem zárja le a fájlokat. Más nem..

Ok, ezt ertem. Csak azt irtad, hogy "... fájlom típusa 0x20-as vagy is fájl", es erre mondtam neked, hogy nem attol file, hogy 0x20 az attributum byte. Akkor is file, ha az 0x00. De akkor is, ha 3 vagy akar 7, de lehet 0x21 is. A 0x20 bit az Archive bit, es igazabol semmi haszna vagy jelentese nincs. A 0x01 a Read Only, a 0x02 a Hidden file, 0x04 a System file, 0x08 a Volume Label, 0x10 a directory. A 0x0f-nek specialis jelentese van, azt a hosszu fileneveknel lathatod.
Az archive bitet az MS termekek beallitjak, de nem kotelezo. Lehet, hogy a te sw-ed akkor sem fogja beallitani, ha egyebkent redesen ir a kartyara. Az en sajat FAT konyvtaram sem allitja be a 0x20 bitet soha.

Az általad és az én általam is használt verzió a 0.07e, ami 2009-es. Nem biztos, hogy patkolni kell, létezik már 0.13-as verzió is, az 2018-as.
Én a helyedben kipróbálnám, a get_fattime() funkciót úgy meghívni, hogy az előző hozzászólásomban lévő változókat definiálod és fix értékekkel feltöltöd. pl. year=2018, month=5,..., talán egy próbát megérne.
Azt gondolom, hogy a file lezárással lesz a hiba.

Már úgy megy, tehát a get_fattime() már olyan mint amit mutattál, csak fixen, nincs változó.
Sajnos már a nyitásnál van hiba, mivel már akkor át kellene adni a file struktúrának, hogy mely cluster az aktuális amely még szabad és abba teheti a megnyitott fájlt.
Ezek a változók mindig uresek, tehát nullásak és emiatt fut mindig hibára az írás, majd a zárás.
Ezt egyesével kitököltem debugban.