Зарегистрирован: Пн апр 25, 2016 15:43:23 Сообщений: 197 Откуда: Россия , Воронеж
Рейтинг сообщения:0
Добрый день. Попробывал код для работы с файлами и возникла проблема. Считывание происходит нормально , но вот запись данных ппросто производит надругательство над файлом. Поелзные данные записывают в самый конец , а перед ними куча мусора.
Столкнулся с проблемой непонимания как переписать функции.
Допустим, если взять функцию
Код:
DRESULT disk_read ( BYTE pdrv, /* Physical drive nmuber to identify the drive */ BYTE *buff, /* Data buffer to store read data */ DWORD sector, /* Start sector in LBA */ UINT count /* Number of sectors to read */ )
как ее реализовать? pdrv - можно игнорировать если я планирую работать только с SD картой? buff - тут вроде понятно, указатель на буфер в 512 байт. sector - это сектор для чтения. Я так понял, минимальный размер чтения/записи - 512 байт? count - сколько секторов читаем. Допустим, реализована функция чтения одного сектора (512 байт)
Код:
SD_ReadSector(uint32_t BlockNumb,uint8_t *buff)
, то я должен ее вызвать count раз (передавая ей номер нужного сектора для чтения), но что будет с данными, которые будут читаться в buff? Они же будут затираться. Или же мне не стоит думать об этом и просто вызвать функцию SD_ReadSector, последовательно передавая ей, в качестве аргументов, сектора, которые должны читаться?
такая реализация функции работоспособна?
Код:
DRESULT disk_read ( BYTE pdrv, /* Physical drive nmuber to identify the drive */ BYTE *buff, /* Data buffer to store read data */ DWORD sector, /* Start sector in LBA */ UINT count /* Number of sectors to read */ ) { DRESULT res; res = SD_ReadSector(sector, buff); return res; }
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
И снова здарсьте. Пытаюсь развернуть FATFS на мегабитной SPI EEPROM. Столкнулся с проблемой вылета в hard fault при попытке записать данные в файл. Изучение проблемы показало, что исключение срабатывает при условии, что я пытаюсь записать >= 16 символов (без учета конца строки) при вызове f_close Камень STM32F103C8 EEPROM M95M01
Дальше глубже. ВЫяснилось, что при ошибке портится значение регистра R3 и программа пытается вызвать функцию по не существующему адресу 0x156. В общем, причину найти не смог. Вот скриншоты нормальной работы программы и не с ошибкой
Норм
Не норм
Почему генерируется HF и как мне записать больше 16ти байт в файл?
В общем, продолжаю копать дальше. Не знаю, в правильном ли направлении двигаюсь. Предположительно нашел место, где фэйлится содержимое регистра R3.
Вот дамп памяти нормальной программы.
Вот программы курильщика
Немного поясню то, что я понял. Адрес перехода в подпрограмму формируется в регистре R3. Деббагер остановлен как раз на месте, где должен быть осуществлен переход по адресу, который находится в R3.
Код:
0x8002276 BLX R3
Окончательно адрес перехода формируется предыдущей командой
Код:
LDR R3, [R3, #0x10]
До этого момента, вроде бы, шло всё одинаково (если сравнивать работу программы рабочей и с ошибкой). Если обратить внимание на дам, то я выделил адрес адрес перехода, куда, в конце концов, должна попасть программа. Это 0х80004327. В рабочей программе этот адрес находится по смещению 0x10, как и указано в инструкции выше. Но в не рабочей программе этот адрес находится по другому смещению, но в дизассемблере смещение по-прежнему 0х10. В результате забирается адрес перехода 0х00000156. Программа пытается перейти по этому адресу, в результате чего генерируется Hard fault исключение. По-хорошему, инструкция должна выглядеть так
Код:
LDR R3, [R3, #0x0С]
Пока всё, что удалось нарыть по этой проблеме. Не знаю, на верном ли я пути. В общем, по-прежнему нуждаюсь в помощи.
Chip115, чановские либы вылетали в хард фаулт в одном случае - в неправильной конфигурации индейцев, а именно _WORD_ACCESS в файле конфигурации. Там и табличкО имеется.
Код:
/*----------/ / System Configurations /----------*/
#define _WORD_ACCESS 0 /* The _WORD_ACCESS option is an only platform dependent option. It defines / which access method is used to the word data on the FAT volume. / / 0: Byte-by-byte access. Always compatible with all platforms. / 1: Word access. Do not choose this unless under both the following conditions. / / * Address misaligned memory access is always allowed for ALL instructions. / * Byte order on the memory is little-endian. / / If it is the case, _WORD_ACCESS can also be set to 1 to improve performance and / reduce code size. Following table shows an example of some processor types. / / ARM7TDMI 0 ColdFire 0 V850E 0 / Cortex-M3 0 Z80 0/1 V850ES 0/1 / Cortex-M0 0 RX600(LE) 0/1 TLCS-870 0/1 / AVR 0/1 RX600(BE) 0 TLCS-900 0/1 / AVR32 0 RL78 0 R32C 0 / PIC18 0/1 SH-2 0 M16C 0/1 / PIC24 0 H8S 0 MSP430 0 / PIC32 0 H8/300H 0 x86 0/1 */
И снова здарсьте. Пытаюсь развернуть FATFS на мегабитной SPI EEPROM.
Если не секрет: на кой сдалась FatFS на SPI EEPROM которая очевидно внутренняя и не вытаскивается из устройства? Или предполагается, что пользователь может выпаять её из девайса, впаять в другой девайс, с целью - передать таким образом данные?
И снова здарсьте. Пытаюсь развернуть FATFS на мегабитной SPI EEPROM.
Если не секрет: на кой сдалась FatFS на SPI EEPROM которая очевидно внутренняя и не вытаскивается из устройства? Или предполагается, что пользователь может выпаять её из девайса, впаять в другой девайс, с целью - передать таким образом данные?
Могу предположить что так он хочет упростить работу с EEPROM.
_________________ Инженер R@D
Telegram чат: https://t.me/radiowolf или в поиске приложения @radiowolf. Личка:@cncoxford
Предполагается, что пользователь, при подключении устройства по USB, увидит флешку, размером 1/2 EEPROMa, куда можно будет дропнуть бинарник с прошивкой, и устройство перепрошьется при перезагрузке.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 29
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
