STM32F103RET6 уходит в HardFault_Handler Опции

[011119xx]

Работаю в Keil 4. Пытаюсь инициализировать FAT следующей функцией:

Код

void MountDrive(void)
{
    uint32_t    TotSectors;
    uint32_t    DataSectors;
    uint32_t    FirstSector;
    struct    partrecord *pr;
    struct    bpb710 *bpb;
    int i;

    SectorBuffer = (uint32_t*) malloc(512);

    if (SectorBuffer == NULL)
    {
        return;
    }

    readsector(0, (uint8_t *)SectorBuffer);

            то что ниже не привожу, так как проблема возникает выше
}

SectorBuffer объявлено выше как:

Код

uint32_t    *SectorBuffer;

При этом при попытке прочитать сектор программа уходит в HardFault_Handler в файле stm32f10x_it.c и там зависает.

Если поменять код на такой:

Код

void MountDrive(void)
{
    uint32_t TotSectors;
    uint32_t DataSectors;
    uint32_t FirstSector;
    struct partrecord *pr;
    struct bpb710 *bpb;
    int i;
    uint8_t buffer[512];

    SectorBuffer = (uint32_t *)buffer;                            

    if (SectorBuffer == NULL)
    {
        return;
    }
      
    readsector(0, (uint8_t *)SectorBuffer);                        
}

то сектор читается и перехода в HardFault_Handler не происходит. Вопрос: почему не работает первый вариант кода? Что там не так?

[zhevak]

Я только предположил, что для инициализации используется стек.
А что, если самой malloc() требуется стек?

Неверное предположение. Извините.
Самой функции malloc() для работы наверняка требуется стек. Хотя я не смотрел на ее исходные коды, и поэтому могу ошибиться. Но это не важно -- нужен ей стек для ее переменных или нет. Важно, что когда функция возвращает управление, ее стековый кадр перестает существовать. А значит, что нас совершенно не касается, что там она у себя внутри делает (если она все делает согласно своему описанию). Не думайте, что выделение и освобождение памяти -- это что-то сверхъестественное. Там все достаточно просто и особого изврата нет. Изврат начинается на стороне программиста, когда тот пытается записать по адресу, память которого уже отдана в общий пул памяти (возвращена в кучу), или когда программист забывает вернуть эту память. Один раз не пид... можно. Но если прога в цикле забирает память и не возвращает? В конце концов прога когда-нибудь да исчерпает всю память. (Мне в этом отношении нравится Линуксовый подход. -- Пестня! Попробуйте сотряпать прогу, которая постепенно сжирает память и посмотрите на реакцию системы. Уверяю -- получите удовольствие! Хотя... извините, Остапа опять пенесло!)

Не думаю, что область памяти, выделяемая с помощью malloc() из кучи, хоть как то инициализируется.
Это уже забота программиста.
Задача malloc() - просто предоставить блок свободной памяти.

Вот именно -- не инициализируется! И это единственное правильное решение. Зачем память инициализировать? Чем ее инициализировать? Нулем? 0xFF-ами? Чем??? -- Ну откуда malloc() знает, что там собирается делать программер. А поскольку любая инициализация так или иначе потребует процессорного времени, то зачем его трать, если нам нужна не такая, а какая-то другая инициализация? Вот поэтому malloc() только выделяет кусок памяти и более ничего не делает. Ну разве что перед тем как это сделать, она проверяет а вообще сможет-ли она выделить непрерывный кусок памяти запрошенного размера. Если сможет, то помечает его границы (записывает особые отметки в пограничные участки) и возвращает пользователю начальный адрес куска.

Но если вы по каким-либо причинам произведете запись сразу же за последним байтом выделенного участка, то вы сломаете структуру. Возможно, вы сможете еще писать-читать из выделенных участков памяти, но уже нормально воспользоваться механизмом выделения и возвращения (malloc-free) -- нет!

Хех. Меняю свой опыт на вашу молодость.