Mam dziwny problem, mianowicie przy wywoływaniu funkcji eeprom_update_block następuje reset mikrokontrolera, natomiast odczyt niby jest ok i zwraca same FFFF czyli 65535

W strukturze jest tablica uint16_t dwuwymiarowa, może w tym tkwi problem? bardzo proszę o rzucenie okiem na kod



Natomiast plik .c



Funkcje zapisujące i odczytujące te strukturę z EEPROM



Sprawdzane na prockach ATMega88P i Atmega328P z bootloaderem generowanym przez mkbootloadera.

Także po wywołaniu funkcji do odczuty z EEPROM i wypisaniu danych z tej struktury w RAMie przez UART są same 65535 dla 40 pozycji i 4 przycisków, natomiast jak zapełnię swoimi danymi strukturę w RAM, które poprawnie wypisują się przez UARTA i wywołam funkcję zapisu do EEPROM to procek się resetuje i na UART od razu lecą ?????? ze zgłoszenia się bootloadera.

Nie mam pomysłu gdzie szukać babola Proszę o pomoc

_________________
.

może tak?

W pliku .h



W pliku .c

_________________
Jestem na GG 31324
Nowy soft, nowa nadzieja.

Jak wstawiłem jak napisałeś to mi teraz kompilator zwracał błąd w linijce


In file included from ../jr_IR_SWITCH/timers.c:17:0:
../jr_IR_SWITCH/ir_switch.h:44:42: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'EEMEM'
extern T_IR_SWITCH_KEYS ir_switch_key_EE EEMEM; //EEPROM

Jeżeli zlikwiduję w pliku h ten EEMEM, a zostawie w c i przestawię miejscami jak proponowałeś to błędu nie ma, jednak nic to nie zmienia

Coś mi się wydaje, że coś jest nie tak z adresami, że coś psuje zapis sam program w pamięci i dlatego procek się restartuje. Nawet raz tak się zrobiło, że bootloader się popsuł i musiałem wgrywać jeszcze raz bo tylko wysyłał znaki ?, lecz przestał odpowiadać w ogóle. Reszta kodu działa ok i nie ma żadnych problemów, tylko ten zapis do EEPROMA się tak dziwnie zachowuje. W innym projekcie mam tak samo w sumie zrobione i działa to jednak tam nie było podwójnej tablicy i wartości były uin8_t a nie 16_t. W sumie to może przeprowadzę testy samego zapisu zmiennej, potem tablicy jednowymiarowej i dwu. Zobaczę czy będą jakieś różnice w działaniu

_________________
.

A zrób tę tablicę dwuwymiarową jako static, w strukturze umieść tylko wskaznik do tablicy. Coś czuję, że ta tablica nie jest zainicjalizowana i wskaźnik do tablicy ma taką wartość, ze write_eeprom indeksuje juz poza pamięcią, stąd zwiecha.

Poprawiłem to co napaćkałem w pierwszym poście. Nie powinno się pisać po piwie. Wstawiłem i skompilowałem. e-gadżet pokazał że zarezerwował tyle ile zadeklarowałeś czyli 320 bajtów.
Nawiasem mówiąc to robiłem coś podobnego niedawno i tak:
w pliku .h


W pliku .c


No i zmiana wartości w EEPROM
plik main.c



Wzorce kodów zaczerpnięte od Mirka z filmu o strukturach.
http://mirekk36.blogspot.com/2012/11/avr-eeprom-struktury-poradnik-do-ksiazek.html
Wszystko pięknie działa.

_________________
Jestem na GG 31324
Nowy soft, nowa nadzieja.

A jak u Ciebie wygląda " copy_ram_to_eem(); " ?

------------------------ [ Dodano po: 5 minutach ]

Ja bym jeszcze spróbował:


Jeśli i tu będzie się wywalać, to błąd jest chyba gdzie indziej, ale bez pełnego kodu ciężko wyrokować.

To ten błąd co miałem wcześniej jak w pliku h dodałem EEMEM to z powodu tego, że w tylko w c miałem załączone #include <avr/eeprom.h>, po dodaniu tego do h już też mogłem napisać EEMEM jednak to nic nie zmieniło co do działania samego programu

Zrobiłem jeden test i ciekawy wynik mnie spotkał

Mianowicie wgrałem program bezpośrednio do procka przez programator i DZIAŁA! Zapisuje ładnie do eeprom i odczytuje!

Także teraz ponownie z bootloaderem próba. Wykonałem takie czynności:

1. Generacja BLS w mkbootloaderze


2. Przed wgraniem ustawienie fusebitów w procku, zaznaczone boot Reset vector enabled


3. Okienko calca przez zapisem do procka


4. Zmiana w kodzie polegająca na dodaniu fragmentu, aby nie resetował się watchdog po soft restarcie


5. Sprawdzenie czy odzywa się bootloader i wgranie przez niego skompilowanego wcześniej kodu z nowym fragmentem


6. Wynik wgrania wsadu


Program uruchamia się poprawnie, dane na uart ładnie spływają. EEPROM pokazuje mi wszędzie FFFF i tak powinno być jak jest wyczyszczony przy wgryuwaniu przez programator i przyyyy wywołaniu tej samej funkcji co wcześniej działającej bez bootloadera jest reset i dane faktycznie do EEPROMa są niezapisane

Czy coś tu źle ustawiłem lub trzeba jeszcze jakieś czynności przeprowadzić?

_________________
.

A jak u Ciebie wygląda " copy_ram_to_eem(); " ?



To też z poradnika Mirka o strukturach

_________________
Jestem na GG 31324
Nowy soft, nowa nadzieja.

Zmodyfikowałem program tak, ze teraz mam tablicę struktur i w środku tablice jednowymiarową uint16_t. Do pamięci EEPROM zapisuję 4 razy przyciski oddzielnie. Objaw ten sam, że za każdym razem jak wgram przez programator to jest ok, natomiast przez bootloader to albo w ogóle program się nie uruchamia i lecą same ????? albo resetuje się przy zapisie do EEPROM.

Podejrzewam, że to może być wina przejściówki USB na UART. Mam ją na chipie cp2104. Kiedyś jak wyszedł program Mk2DecoderIR to nie mógł on w ogóle wgrać wsadu do procka przez bootloadera mimo, że odbieranie danych i wysyłanie przez UART było poprawne. Po kilkunastu próbach i różnych wersji oprogramowania Mirek wprowadził modyfikacje, że teraz wgrywa się bez problemu! Jednak MkBootloder jest doś stary ( wersja ) i nie zawiera pewnie w sobie tych poprawek.

Także zastanawia mnie czy nie jest to wina tego, że są jakieś błędy w transmisji i program wgrywany przez bootloader nie działa poprawnie mimo iż napisane jest, że program wgrany poprawnie. Ciekawe czy MkBootloader to w jakiś sposób weryfikuje czy wsad jest ok? Pewnie nie

Tak idąc tym tropem pomijając mkBootloadera pojawiła się możliwość wgrania wsadu przez MkClipsa. Także czemu nie spróbować? Obojętnie co chce wgrać i do jakiego procka to jest ten sam problem co był w mk2DecoderIR czyli program zawiesza się przed rozpoczęciem wgrania samego wsadu:


I tak można w nieskończoność czekać i nic się nie dzieje. Nie można zamknąć również samego programu bo pojawia się komunikat, że czeka na zakończenie wątku bootloadera i po akceptacji w ogóle można ubić program tylko z menadżera urządzeń. Powtarzalność 100%.

Także na razie przez tę przejściówkę poprawnie wgrywa i to za każdym razem bez problemów jedynie Mk2DecoderIR, teraz wgrany na nowo bootloader i wsad:

Program działa bez problemów i odbiera ramki.

Spróbuje jeszcze przeprowadzić próbę przez komponent MkBooload w delphi, ale ponieważ nie ma exeka i trzeba skompilować program to muszę najpierw zainstalować w starterze resztę komponentów, aby skompilować projekt. Chyba, że ktoś już to zrobił i ma możliwość podrzucenia tego testowego exeka w celu sprawdzenia czy wgrywa się poprawnie, to będzie szybciej


Zamówiłem już przejściówkę USB na UART na FT232 - zobaczymy czy będzie jakaś różnica tylko, że przyjdzie pewnie dopiero w poniedziałek, albo wtorek.

Proszę również Mirka o wypowiedź czy te poprawki z MK2DecoderIR dla tej przejściówki na chipie cp2104 są uwzględnione chociażby w MkClipsie czy komponencie MkBootload.

No i kiedy można się spodziewać nowszej wersji mkBootladera bo w filmikach jakiś czas temu była zapowiedź

_________________
.

Także skompilowałem sobie z najnowszymi wersjami komponentów programik TESER dla delphi i on natomiast poprawnie wgrywa wsad jak mkbootloader
--- BLS INFO ---
PageSize: 128
BLS Address: 0x7E00
Microcontroller: atmega328p
F_CPU: 8000000 MHz
BLS ver: 1
-----------------
BLS upload start, Firmware Size = 1792
[================= Progress 100 % =================]
Upload succesful
Thread end, Upload OK

Jednak ostatecznie objaw działania programu podobny jak wcześniej reset...

Ogólnie mam dwa procki na różnych płytkach jeden to atmega88pa i drugi atmega328p na którym testuje te same programy. Na tę większą atmegę poprawnie wgrywa się się program i bootloader przez program mk2DecoderIR. Mam do niej podłączony również programator.

Mam też prosty program testowy, aby testować czy wgrał się wsad bootloadera poprawnie, wyświetla on na terminalu takie dane:


Więc nic ciekawego, jedynie tekst i licznik co zmienia się co 0,1s, również wypisany jest odebrany pojedynczy znak z klawiatury i jeżeli jest to r to następuje reset. Opóźnienie jest na zwykłym delayu. Nic więcej tam nie ma. Jak widać program wgrany przez programator działa poprawnie i to za każdym razem.

Natomiast jak wgram bootloader i chociażby przez wyżej skompilowany program TESTOWY komponentu do DELPHI to niby wgrywa się ok jednak na konsole dostaje:


Czyli wysyła się początek programu bo pierwsza linija w kodzie jest tr_cls( 1 ); czyli jak widać idzie kod sterujący do konsoli i następuje reset i tak w kółko.

Testowane na dwóch przejściówkach na CP2104, na tych dwóch różnych prockach i objawy są takie same. W tym kodzie bardziej skomplikowanym co zapisuje się EEPROM czasem udaje się wgrać program na tyle przez bootloader, że restart jest tylko w momencie zapisu do EEPROM.

Nie mam już pomysłów w czym jest problem. Wygląda na to jakby nie działała ta sekcja wyłączająca watchdoda po starcie programu w .init3 skopiowana ze strony atnela i programu mkbootloader.

Tylko nie wiem czemu za każdym razem poprawnie sobie wgrywa kod mk2DecoderIR w tej samej konfiguracji kabli itp. Nic nie jest zmieniane sprzętowo. Działa za każdym razem. Natomiast tutaj takie problemy

Jeszcze pozostanie mi sprawdzić na tej przejściówce z ft232. Sprawdzę czy mkClipse się zawiesza przy programowaniu i czy efekt jest ten sam co na tej CP2104 czy może są jakieś różnice.

Chyba, że ktoś ma jeszcze jakiś pomysł co można by było sprawdzić, albo jakiś prosty kod do bootloadera co u niego działa na któryś z tych procków co wymieniłem, aby wyeliminować błędy w kodzie?

_________________
.

Dziękuję wszystkim za pomoc i cierpliwość. Dla potomnych rozwiązanie

Dzisiaj przyszła przejściówka na ft232 iiiii na tych samych kabelkach, programach i testach wszystko zaczęło działać jak należy. Nic się nie resetuje, wszystko wgrywa od kopa i działa bez żadnych problemów.

Także problem występuje prawdopodobnie w transmisji jak bootloader wgrywa wsad do procka i przez to programy w losowych momentach się wykrzaczają i następuje reset.

Czasem tańsze ( przejściówki na cp2104 ) znaczy dosłownie gorsze chociaż do zwykłej transmisji i podglądu danych przez UART wystarczają

_________________
.

Z ciekawości to sprawdź na analizatorze logicznym długość trwania pojedynczego bitu dla różnych prędkości. I czy na niskich prędkościach bootloader też nie działa.

Na różnych prędkościach jest to samo

_________________
.