ADC DMA Problem z wykonywaniem programu

[Elvis]

Faktycznie, kod źródłowy sporo pomaga. Problem okazał się dużo ciekawszy niż w pierwszej chwili wyglądało, więc w końcu odnalazłem zakurzone blue pill, podłączyłem programator i postanowiłem sprawdzić o co w tym chodzi.

Najpierw wersja skrócona - lepiej na razie nie używać CubeIDE... to nowe środowisko, powiedziałbym że wersja beta. Więc jest w nim dużo więcej błędów niż w starych i sprawdzonych.

A teraz pełna wersja:

Na początek faktycznie - błąd się pojawia, występuje w dość przypadkowych momentach, nie ma najmniejszego sensu... Chociażby podczas inicjalizacji DMA, HardFault jest wynikiem dereferencji wskaźnika NULL, który pojawia się magicznie. Więc typowe debugowanie niewiele daje oraz wskazuje na problemy ze stosem.

I tutaj niestety musimy zejść do poziomu samego procesora. Po uruchomieniu mamy:

Jak widzimy po prawej stronie wskaźnik stosu, czyli rejestr sp ma wartość 0x200001fc, czyli od początku pamięci SRAM dzieli go 0x1fc = 508 bajtów. To za mało na skomplikowany program działający na liczbach zmiennopozycyjnych.

Teoretycznie wielkość stosu ustawiamy w pliku linkera, czyli STM32F103C8TX_FLASH.ld:

Tutaj znajdziemy dwie ważne wartości. _estack to adres "końca" stosu, czyli najwyższego adresu zajmowanego przez stos. Widzimy tutaj pierwszy błąd, bo adresy powinny być podzielne przez 4, a często i przez 8. W każdym razie powinniśmy zmienić deklarację na:

/* Highest address of the user mode stack */
_estack = 0x20005000;	/* end of "RAM" Ram type memory */

Teraz to czego szukamy, czyli wielkość stosu:

_Min_Stack_Size = 0x400 ;	/* required amount of stack */

Domyślna wartość 0x400 oznacza 1024 bajty. Mikrokontroler STM32F103C8 ma 20 KiB pamięci SRAM, więc nie musimy być aż tak oszczędni - można ustawić stos na nieco większy.

Okazuje się jednak, że zmiana _Min_Stack_Size nie wpływa na wartość rejestru SP, czyli faktyczny wskaźnik stosu... Mamy 508 bajtów bo coś się komuś pozajączkowało.

Nie jestem pewien, czy to najlepsze rozwiązanie, ale można poprawić problem zmieniając plik startup_stm32f103c8tx.s, który znajdziemy w katalogu Startup. Teoretycznie rdzeń Cortex-M3 ustawia wartość rejestru SP podczas uruchamiania programu - ale to jak widać nie działa poprawnie. Możliwe że wynika to ze sposobu działania debuggera i po wgraniu do pamięci flash byłoby poprawnie, ale możemy zastosować "obejście" i sami ten rejestr ustawić. Do wspomnianego pliku wystarczy dodać jedną instrukcję:

	ldr sp, =_estack

Program wygląda wówczas tak:

I u mnie działa...

Edytowano Listopad 10, 2019 przez Elvis

[Bornhartt]

Potwierdzam, wszystko działa

W sumie odczułem ulgę, że to nie był jakiś trywialny błąd, ale chyba będę musiał zrezygnować z CUBEIDE na rzecz pewnie SW4 i MXa żeby już takie historie się nie powtórzyły

Bardzo dziękuję za rozwiązanie problemu i pozdrawiam

[Elvis]

Trochę się zastanawiałem nad tym błędem i wartością rejestru SP - bo przeglądając plik startup_stm32f103c8tx.s wszystko wygląda poprawnie (nie licząc złej wartości _estack).

Wydaje mi się, że przyczyną problemów była nieco nietypowa konfiguracja. Ja najczęściej w przypadku bluepill używam bootloadera oraz  programowania przez usb. Tym razem, żeby uzyskać ten sam efekt co opisywany w wątku podłączyłem st-link z interfejsem SWD (właściwie to podłączyłem stlink z płytki nucleo). W każdym razie sam bluepill nadal uruchamiał bootloader, a dopiero później przez SWD wgrywany i uruchamiany był "właściwy" program.

Normalnie po włączeniu zasilania pierwsze słowo z kodu programu jest ładowane do rejestru SP. Tam znajduje się wartość _estack i wszystko powinno działać.

Ale jeśli zamiast programu uruchamiany jest bootloader to oczywiście rejestr SP jest kontrolerowany przez kod bootloadera. W kolejnym kroku debugger przejmuje kontrolę i uruchamia główny program. Jednak procedura jego uruchomienia nie jest identyczna z "prawdziwym" resetem. Rejestr SP powinien być więc ustawiony przez debugger, ale ktoś tego nie przewidział w skryptach dołączonych do CubeIDE... i w efekcie program startuje z wartością SP z bootloadera.

To by również tłymaczyło wpływ grzebania przy liniach BOOTx na działanie programu. Jako ciekawostkę można spróbować skompilować oryginalny program, wgrać do flasha i wystartować bez bootloadera i debuggera. Jeśli to zadziała, to będzie potwierdzenie mojej teorii...