Programator-dibager MCU-a

Pokusavam da napravim programator i dibager MCU familije MC9S08. On koristi BDM (pozadinski dibag mod) za komunikaciju sa prototipom. Postupak je sledeci:

Komunikacija mastera i prototipa se vrsi preko jedne veze, BDMIO, u poludupleksu (jedan pin na MCU). Veza je na strani prototipskog MCU-a open drein sa pulap otpornikom od oko 4K7.

1. Prototipski MCU se resetom uvede u BDM. To je jednostavno i necu opisivati.

2. Master (programator i dibager MCU-a) izaziva sink sekvencu drzanjem desetak ms BDMIO na nuli. Prototipski MCU mu potom salje log. 0 u trajanju 128 BDM ciklusa. Na osnovu toga master meri frekvenciju BDM kloka prototipskog MCU-a. Ova frekvencija se krece od 3.5MHz do 17MHz, zavisno od tipa prototipskog MCU-a.

3.Slanje i prijem jednog bita se vrsi za 16 BDM kloka. Referentni klok je deseti.

4.Slanje pocinje tako sto 4 BDM kloka master drzi 0 na BDMIO, a onda ako salje 1 on dize nivo na log 1 u trajanju do 16-tog BDM kloka. Ako salje 0, onda dize signal BDMIO na log. 1 na 14-tom kloku BDM ciklusa. Prototipski MCU detektuje nivo BDMIO na 10-tom kloku i tako zna sta prima.

5. Prijem bita se inicira od mastera drzanjem log. 0 2 do 4 BDM kloka, a potom master drzi BDMIO na visokoj ompedansi. Tada prototipski MCU salje signal log. 0 ili log. 1 po istom principu, samo sto ovoga puta master detektuje stanje BDMIO linije na 10-tom kloku BDM-a.

Sobzirom da maksimalna frekvencija BDM-a moze biti 17MHz, onda 16 BDM kloka potrebnih za slanje jednog bita traje manje od 1us. Ovo zahteva ili vrlo brz mikrokontroler, ili mnogo dosetljivosti da bi se realizovalo. Kako na forumu ima onih koji rade sa razlicitim mikrokontrolerima, mozda vide resenje sa nekim od njih. Takodje i bilo koja ideja bi bila korisna.

Da stvar bude komplikovanija prototipski MCU se moze napajati naponom od 1.8V do 5.5V (zavisno od tipa), pa su potrebni i translatori nivoa.

U prilogu saljem oblik signala koje sam opisao.

Vidim, niko se ne javlja.
Meni bi najvise odgovaralo kada bi opisani problem mogao da resim sa MCU-ovima koje koristim (MC9S08). Kupio sam jedan MULTILONK, od firme PE, koji radi to sto ja hocu da postignem. Ali zajedno sa softverom je skup, a ne prodaju ga bez softvera. Juce sam ga otvorio, i umesto neke babaroge od MCU-a vidim da su ugradili MC9S12UF32 (16-to bitni, 32KB flash, 3.5KB RAM, USB, takt CPU-a do 30MHz). Zbog USB-a radi na 24MHz.

To sto je 16-to bitni nije presudno za moj problem, ali ocigledno je da su realizovali funkciju ne sirovom snagom vec mudrim dosetkama. Ja posedujem MC9S08JM32, koji ima USB i radi na 24 MHz pa se pitam kakvim dosetkama mogu i sam da realizujem ranije opisanu funkciju.

Shvatam da je ovo tezak problem, cak i za najiskusnije programere na bilo kom MCU, jer principi su vazni posto svi MCU-ovi imaju uglavnom integrisani isti hardver. To omogucuje da se jedno resenje sa jednog MCU-a verovatno moze uz modifikaciju preneti i na drugi, ali je vazna ideja.

Posto ovaj forum moze komotno da se zove PIC mikrokontroleri, gde zbog besplatnih razvojnih sistema i gotovih resenja vecina ne ulazi u srz MCU-a, oslanjam se na casne izuzetke koji to rade i koji jedini mogu da daju neku korisnu ideju.

Pozdrav svima.

Ja sam shvatio da je najveći problem kako semplovati tu liniju sa podacima koja može da ide i do 17MHz pošto protokol izgleda imaš. Ja stvarno ne bih znao za dosetku kako da se to uradi sem ako nema nekog hardverskok perifernog modula koji može da se upotrebi i za slušanje. Možda baš isti takav kakav ih i šalje. Ili modifikovana konfiguracija I2C veze ili slično. Pogledaj taj uređaj koji imaš na kom pinu sempluje podatke i pogledaj koje sve periferije se koriste njime.

Vrlo je moguće da ti cena postane prihvatljiva kada bolje sagledaš sa čim sve treba da izađeš na kraj da bi sam napravio ovako nešto. Ali ne treba olako ni odustati. Bolje bi bilo da pokušaš na njihovom specijalizovanom forumu. Uglavnom će ti u početku reći da kupiš to i da ne trošiš svoje vreme na takve stvari ali ćeš možda kasnije od nekog ipak saznati kako može da se uradi. Trebaš samo da budeš precizniji šta pitaš. Neće niko da odradi ceo posao ali će ti reći ako zna odgovor na konkretno pitanje.

Da pogledao sam,

BDMIO vodi na tajmerski kanal i na ulaza SPI modula konfigurisanog kao slave. Takodje sa drugog tajmerskog kanala vodi clk za SPI. E sad je caka u tome kako on koristi tajmer da generise potrebne signale, dok SPI moze lako da prima podatke sa BDMIO.

Hvala, i pozdrav.

Nezgodno je ako se pokusa problem rjesiti tako sto pretpostavimo da svake mikrosekunde treba ocitati jedan bit i nesto na osnovu toga uraditi. Po meni je vjerovatnije da u razmjeni podataka izmedju debugera i tog ciljnog mikrokontrolera postoji neki protokol, kao i format podataka koje medjusobno razmjenjuju a koji se zasniva na duzini poruka od 8, 16, 24... ili vise bitova (odnosno prenosi se blok bitova). U tom slucaju taj blok se moze bez vecih problema nekim externim hardverom (npr. obican shift registar i brojac po modulu 16 koji okida na 10) privremeno snimiti, pa proslijediti debugeru (ili mikrokontroleru u obrnutom smjeru) kad se zavrsi prenos citavog bloka.
Ne znam kakve su mogucnosti konfigurisanja timera i serijskog adaptera kod motorolinih mikrokontrolera ali mozda je moguce da su kod tog uredjaja koji si nabavio kombinacijom ta dva modula "napravili" neku modifikaciju serijskog protokola koja odgovara ovoj kombinaciji (dakle, semplovanje na svakoj desetoj uzlaznoj ivici takta). Npr. timer generise potreban takt od npr. 5MHz. U istom ritmu broji i brojac po modulu 16 koji npr. kad dodje do 9 setuje tu tajmersku liniju koja ide ka clk pinu od serijskog modula, a kad dobroji do najkasnije 15 resetuje je i tako dobijes potreban clk za serijsku komunikaciju koja odgovara ovom protokolu.
Znaci, dobio bi se clk slicno ovome kakav sam docrtao na orginalnom grafiku.

SPI je izgleda iz tog razloga i podesen kao slave, jer se njime upravlja preko spoljnih linija (koristeci signale sa timera i sl.) a ne "iznutra" preko softwera, iako u principu debager je i dalje master na toj serijskoj liniji, samo posredno vuce konce preko spoljnih pinova.
Medjutim, to ocigledno nije dovoljno da bi se shvatili svi detalji, fali jos taj protokol, pri cemu ne mislim na fizicki raspored signala za slanje jednog bita nego i sve ostalo. Serijska komunikacija ima i start/stop/parity bitove kao i duzinu poruke itd. i treba vidjeti sta je sa njima ako se na strani debugera koristi serijski modul, odnosno treba znati kakvi paketi bitova putuju po toj vezi.

Ovde se SPI koristi samo kao hardverski shift registar jer bi za hvatanje 17MHz trebalo minimum 34 MIPS-a. Kao slave je konfigurisan jer nije potrebno da SPI generiše CLOCK već samo da hvata sekvencu a umesto kloka koristi tajmer koji je podešen u prvim koracima handshake-a. Tada je mereno koliko vremena treba da se odigraju inicijalne sekvence i proporcijom se utvrđuje brzina (baudrate) na koji se postavi taj timer da zameni klok za SPI.

A naleteo sam i na tvrdnju da je JTAG-ICE (In Circuit Emulator) u stvari ekvivalent za BDM (Background Debug Modules) i da se razlikuje pinout i drastično cena, pogledaj

http://robotics.ee.calpoly.edu...doku.php?id=sensor_motes:start

naravno treba dalje ovo istražiti, recimo ovaj app note http://www.freescale.com/files...ollers/doc/app_note/AN2596.pdf i kako stoji familija koju želiš da koristiš sa ICE-om, a ja verujem da ti dodatne linije koje bi koristio JTAG ne bi pravile naročit problem ako dizajniraš novu pločicu.

Korak,
jel to imaš neki dump ili source gde si video konfiguraciju??? Jel to već radi? Šta mu fali zapravo?



Odin,
nema "spoljnih" signala već se za određenu periferiju jednostavno konfiguracionim bitovima odabere šta će da bude klok.

Dibager se nalazi u PC-u kad se startuje program za debagovanje. Uređaj koji nazivaš master je u stvari jednostavan most koji je upravljan totalno preko USB-a i prosleđuje sekvence koje dobije od PCja samo realizuje tu serujsku vezu koja je nezgodna jer je ideja da se koristi jedna jedina žica.

Protokol za tu jednu žicu ima ovde AN2104 - Using Background Debug Mode for the M68HC12 Family
http://www.motorola.com.cn/sem...cudsp/forms/appnote/AN2104.pdf



Ovo je definitivno serijska veza. Falling edge, to je početak start bita. Dalje odbroji devet E ciklusa da se pomeri ka sredini pa sempluje vrednost. Na taj način se eliminiše trigerovanje šumom. Perioda za svaki bit je 16 E ciklusa. Ne znam tačno koji je SYSCLK za dati MCU familije MC9S08 ali ako pretpostavim 20 MHz onda je E klok 10 MHz pa je tada serijska veza 625 K baud-a i ovaj tajmer koji generiše klok za SPI treba tu vrednost da gađa.


Transakcije su sledećeg oblika
Prvo host šalje 8 bitnu komandu, zatim 16 adresu i nakon toga u zavisnosti od komande sluša 16 data bitova ili i njih šalje uređaju koji se debaguje. Preko adresa se pristupa različitim registrima i aktiviranjem odgovarajućih bitova moguće je menjati razne debug modove...

Pa to sam i mislio kad sam rekao da su tajmer i serijski modul ukomponovani da se napravi nesto sto odgovara ovoj komunikaciji. Medjutim, gledano sa strane SPI-ja ne radi se o 17MHz, nego o 17MHz/16, dakle nesto vise od 1MHz, jer u tih 17MHz BDM takta, na svaki 16-ti se pojavljuje jedan bit i takav takt stize od timera. Odnosno, ne radi se o semplovanju, u klasicnom znacenju te rijeci gdje je potrebna duplo veca frekvencija da bi se semplovani signal mogao rekonstruisati, nego o nekoj modifikovanoj serijskoj komunikaciji na priblizno 1MHz (u slucaju da je BDM 17MHz).
Ako sam ja dobro razumio, ni na jednoj liniji komunikacije izmedju debugera i uC-a se ne pojavljuje tih 17MHz, inace ona sinhronizacija od 128 nula na pocetku ne bi bila ni potrebna. Sinhronizacija izmedju clk signala na strani debugera koji generise njegov tajmer i tog BDM clocka u prototipu se vrsi mjerenjem trajanja tih 128 bitova, a sinhronizacija se dalje odrzava na nivou svakog bita sa onih pocetnih 3-4 nule i dizanjem na jedinicu na 14-om taktu.
Prema tome, brzina komunikacije izmedju debugera i prototipa je od nekih 218Kbit/s do 1.06Mbit/s. Ako se nisam negdje z****o.

@barum

dok sam ja kucao prethodnu poruku, ti si u medjuvremenu vec poslao zvanicne detalje koji su potvrdili nase pretpostavke. Vjerujem da sad to i ne izgleda tako strasno za realizovati kako se cinilo na pocetku.
Pozdrav.

Da, da. I ja sam tek sad shvatio o čemu se radi. Zapravo svaki bit ima start i stop sekvencu koja se koristi da dodatno sinhronizuje komunikaciju. Mislim da je ovaj E clock koji sam ja citirao u stvari sinonim za BDM klok.

Bit uvek počinje sa 4/16 vrednosti nula a završava se sa 2/16 vrednosti jedinice. Sredina između ta dva je deveta šesnaestina kada se vrši semplovanje.

Kada se prima bit onda master šalje 2/16 vrednosti nula a zatim prebacuje pin kao ulazni i on biva pullup-ovan ka jedinici do kraja 4/16 kada kontrolu preuzima debagovani uređaj koji upravlja linijom od te četvrte šesnaestine do četrnaeste šesnaestine. Sad je malo nedorečeno ko upravlja linijom zadnje dve šesnaestine jer nije ostavljeno lufta da se kontrola vrati nazad masteru. Ali kako je u pitanju uvek nula onda može i malo da se preklope pa će uvek da se pojavi nula jer je dovoljno bar jedan drajver da sinkuje liniju.

SPI je definitivno zadužen za semplovanje i šiftovanje dok se firmver bakće sa okvirom za svaki bit menjanjem tristate vrednosti pina za komunikaciju i finim korigovanjem tajminga.

Hvala vam na sadrzajnoj diskusiji, sasvim ste razotkrili sustinu problema.

Odmah posle slanja jednog bita, posle 16-tog BDM clk-a, moze da krene slanje sledeceg bita, ali i ne mora. Ogranicenje pauze je 512 BDM clk-a kada ciljni (prototipski) MCU to shvata kao prekid komunikacije.

Posle slanja bajta komande koja ima (ili nema) svoje parametre mora da sledi mala pauza da ciljni MCU dekodira naredbu i postane spreman za slanje svojih podataka. Inace protokol ima ACK i noACK, ali se to moze iskluciti iz protokola. Umesto toga moze se traziti od ciljnog MCU-a da sa svkom porukom koju salje, posalje i vrednost statusno-kontrolnog registra BDM komunikacije.

Ideja koju imam je da generisem PWM signal koji ima periodu 16 BDM kloka, a za slanje log. 1 BDMIO ima log. 0 4 BDM ciklusa, a za slanje log. 0 isti signal ima log. 0 14 BDM kloka. Ovo se lako realizuje. Problem je sto treba na kraju slanja poruke ciljnom MCU-u pin koji generise BDMIO predje u stanje visoke impedanse. To se uradi tako sto se iskljuci tajmerski kanal, tada pin postaje obican IO pin ves podesen kao ulazni. HC12 ima tajmersku jedinicu koja moze na neki dogadjaj da odredjene pinove tajmerskog kanala (ima mask registar za to) moze da prevede u IO kanale sa unapred zadatom direkcijom i stanjem na pinu. Moja ideja da to uradim sa MC9S08JM60 ima otezavajucu okolnost sto njegova tajmerska jedinica nema tu mogucnost, pa moram da pratim softverski kada je zavrseno slanje poruke ciljnom MCU-u. To ce napraviti vecu pauzu izmedju slanja poruke i prijema poruke.

Sada racunam 'nanosekunde' za pojedine operacije, sobzirom da moram da menjam toff/ton za PWM signal. 4 BDM siklusa ce trajati 250ns (za 16MHz BDM kloka), a 14 ce trajati 875ns. Ovo su sve kratka vremena da bi se koristili interrupt-i za promenu toff/ton. MC9S08 kada se desi interrupt stavlja sve registre CPU-a na stek, za sta mu treba 10 ciklusa, a povratak iz interrupt-a (rti) trosi 9 ciklusa, sto je ukupno 19 ciklusa. Ako se ovome doda slucaj kada se interrupt desi kada je pocela najduza asemblerska naredba, onda treba dodati jos 4 ciklusa, sto ukupno iznosi 23 ciklusa po 41.7ns iznosu oko 958ns. Ako se tome doda i kod interrupt procedure onda to prevazilazi 1us. Srecom tajmer je baferovan, i dovoljno je da softverski testiram bit koji kaze kada je zavtsena foff perioda, i tada. zavisno da li je sledeci bit 0 ili 1 upisujem odgovarajucu vrednost u registar tajmerskog kanala koji generise PWM. Ova vrednost se cuva u baferu, a postaje aktuelna na sledeci prelaz sa toff na ton PWM signala. Racunica pokazuje da se sa ovakvim pristupom ima dovoljno vremena da se upravlja generisanjem potrebnog PWM signala koji predstavlja BDMIO signal koji se salje ciljnom MCU-u.

Prijem je malo slozeniji. Treba generisati na BDMIO 2 do 4 BDM ciklusa log. 0, pa preci u visoku impedansu i generisati klok na 10-tom BDM kloku za klok SPI-a. Generisanje kloka za SPI je jednostavno jer se radi o kontinualnom PWM signalu koji generisem drugim tajmerskim kanalom. Problem je sto sto posle inicijalizacije prijema sa log. 0 na BDMIO mora odmah de se predje u stanje visoke impedanse. Cini mi se da za ovo ne mogu da koristim tajmer, pa razmisljam o koriscenju nop instrukcija u potrebnom broju. To je za sada dilema

Inace sinronizaciju sam probao i dobro sam izmerio BDM klok.

Hvala na saradnji, pozdrav.

Imam slično iskustvo iz pravljenja programera za dsPIC30F familiju. Tamo mi je glavni problem bio nedorečena dokumentacija i neophodna četiri kloka u inicijalnom handshake-u kao i kada se treba semplovati bit za prihvatanje jer se nije slagalo sa dokumentacijom. I još je problem bio što i posle poslednjeg pročitanog bita drajver za data liniju na programiranom mikrokontroleru ostaje aktivan i tek kada se desi prva ivica kloka sledeće instrukcije on se isključuje praveći ponekad konfuziju pa sam stavio nešto veći vremenski interval posle prve ivice prvog kloka da se lepo preda kontrola nazad programatoru. To sam rešio uz priličnu pomoć mikročipovog foruma. Komunikacija je bila do 6 mega bauda ali je bilo lako jer sam sam upravljao klokom. No da se vratimo na ovaj slučaj.

Ovde je malo nezgodno što nema linije za klok pa kod koji se izvršava mora da bude fleksibilan za razne brzine. Interapti za svaki bit ne mogu da budu rešenje. Ali moguće je da kao i kod PIC mikrokontrolera svaki izvor interapta kad je onemogućen ipak obeleži događaj setovanjem svog flag-a. Recimo taj PWM generator se isto verovatno sastoji od jednog brojača i registra za poređenje koji kad dostigne jednakost generiše događaj i resetuje brojač. Zatim za svaki od četiri PWM kanala je postojao dodatni registar koji se stalno poredi sa istim brojačem ali ga ne resetuje već samo generiše događaj a ako je uključen interapt za taj događaj on se stavlja u red i po prioritetu izvršava. Ako je interapt isključen ali PWM modul podešen da generiše ovaj događaj onda sam ja mogao da zaustavim program u petlji od dve instrukcije dok se događaj ne desi da bi na taj način ostao u sinhronizaciji. Dakle treba nekoliko takvih compare modula koji bi se prvo podesili na vrednosti koje treba da predstavljaju četiri šesnaestina i četrnaest šesnaestina i onda bi jedna rutina za slanje bita bila univerzalna za razne brzine jer bi za sporije brzine duže čekala da se izbroji veća vrednost a za veću brzinu bi prolazila možda čak i na prvo testiranje flag-a.

Ako nema hardverskog ovakvog trigera onda bi mogao da posluži i običan softverski brojač. Recimo ako postoji instrukcija koja dekrementira pa ako je nula preskače sledeću instrukciju (decrement and skip if zero) mogla bi da skida sa postavljene vrednosti i tako pravi različitu pauzu potrebnu za različite brzine. Ovo uključuje nešto veći rad oko brojanja koliko koja instrukcija koristi ciklusa i eventualno raspoređivanje nop instrukcija da se pogodi pravi trenutak. Znači otprilike četiri ovakva brojača se setuju kopiranjem iz četiri postavljenih vrednosti. Zatim se postavlja izlazni smer za pin i logička 0 i kreće se sa petljom koja umanji za jedan pa pita dal je nula pa opet umanji za jedan pa pita... tek kad bude nula preskoči bezuslovni skok koji pravi petlju i nastavi dalji rad u rutini za bit zatim se odradi sledeći korak postavljanje bita ili pripremi semplovanje (okrene smer u ulazni, hi-z) zatim sledeći brojač krene da se umanjuje da bi se čim anulira izvršilo semplovanje. i posle još brojač koji će da reguliše period do one "uvek jedinica na kraju" i četvrti brojač da se anulira za period te krajnje jedinice.

Ta rutina zgodno bi bilo da bude makro pa da se ekspanduje za svaki bit svoje vrste bajta (prijem ili slanje). Može da se proširi na više stotina instrukcija ali neće biti dodatnih call/return komplikacija niti brojač tekućeg bita i pitanje dal treba još bitova.

Pozdrav

Pade mi na pamet i drugačiji pristup, da se u SPI registar upiše vrednost koja odgovara bitu i da se onda prepusti njemu da to isporuči prema brzini koju dobija na liniji za klok, SPSCK. Dakle za bit 0 ide binarno 0000000000000011 a za bit 1 ide 16 bitna vrednost 0000111111111111. Kad se prima bit onda on šalje 0000111111111111 ali tada treba da se pogleda šta je primio i ako ima vrednost 0 na devetom (ili desetom?) bitu da se to prihvati. Znači logička jedinica kad se pošalje može da ostane nepromenjena ako i target u isto vreme vraća jedinicu ali ako vraća 0 ona pobeđuje i linija je sinkovana za taj deo bit perioda. Znači SPI modul kao mali signal generator i logički analizator u isto vreme. :)

Hvala barum,
tako i ja planiram realizaciju. Inace svaki interrupt, pa i od tajmera, postavlja fleg koji ne mora da izazove interrupt ako on nije dozvoljen. On moze softverski da se testira kako bi se posle njega prepodesio PWM. Kako je tajmerska jedinica baferovana, prakticno nema gubitka vremena koje je inace potrebno za pomenuto podesavanje PWM-a sobzirom na bit koji se salje.

Hvala na sugestijama.

Pozdrav.

Red je da kada se zavrsi neki posao da se o tome obaveste ucesnici po ovoj temi.

Posao je zavrsen i testiran samo sa mikrokontrolerima koji se napajaju sa 5V, jer tek sad ce biti napravljena plocica koja ce sadrzati i kola za prilagodjenje razlicitih nivoa signala zbor razlicitih napajanja ciljnog MCU-a (1.8V do 5.5V). Resenje je bez spoljasnjih hardverskih dodataka, dakle, potpuno softversko i otprilike onako kako je i pisano u okvitu ove teme. Test je bi sa BDC klokom u opsegu od 4.2MHz do 17MHz.

Ostaje mi jedan problem. Naime, koristim hid drajver PC-ja za USB komunikaciju. To je vec ranije uradjeno, ali ostvarila se moja bojazan da brzina nije velika. Naime ovaj drajver sluzi za tastaturu, misa i t. d. i moze da prihvati do 128 uredjaja, dakle, koncipiran je za nesto drugo. Pravo resejne je napisati poseban drajver i instalirati ga na PC-ju. To nisam nikada radio i morao bih prvo nesto da naucim u vezi sa tim. Ostvarena brzina sa HID-m je oko 4KB u sekundi, sto znaci da se 64KB (najveci flash) moze preneti za 16 sekundi, dok bi programiranje (teoretski) bilo za 1.3s. Stvarno sam u dilemi, jer ne mogu da predvidim tezinu posla oko pisanja posebnog USB drajvera, i da li se to isplati? Sta mislite.

Zahvaljujem svim ucesnicima na doprinosu.

Srdacan pozdrav.

Mislim da se na kratak rok uopšte ne isplati. Jako je rasprostranjen slučaj da su loši drajveri upropastili upotrebljivost odličnog hardvera. Na duži rok, detaljno upoznavanje najnižeg nivoa nekog operativnog sistema moglo bi da bude korisno.
Ja lično nikad nisam uspeo da nabavim upotrebljiv DDK tako da sam malo bio probao da pravim drajver za paralelni port uz pomoć samo onih sistemskih zaglavlja koja dolaze u okviru VS-a i život mi se smučio bio dok sam pokušavao da obradim sve one izuzetke koji mogu da budu prijavljeni i da debagujem uz pomoć nekih logera koji generišu petsto linija u sekundi.

Postoje i mnogi pristupačni gotovi drajveri na netu.