Lpc2478 Jtag

[murphy]

Ehk on keegi tegelenud selle prosega, suure hurraaga läksin vana meetodi kaudu ja ei disaininud ISP liidest vaid ainult jtag pesa. Avastasin aga et JTAG ei suhtle sõltumatta enable pinn olekust. Tegu on revC ehk esimene. Errata ei märgi midagi. Netist midagi pole leidnud. Jootsin ISP lakktraadiga külge ja see töötab ja flashib, secure enable on maas. Seega peaks nagu töötama. Specist ei leia et saaks kuskilt sisse ka lülitada jtagi või et oleks mõni register selle jaoks.
Lisan veel et mäletan ühest LPC2210 projektist et teatud mälu conf registrite surkimisel kadus jtag,enam ei mäleta ainult milliste. Isenesest LPC24xx ja LPC22xx suht sarnased, isegi sstartup ja linker skript faili sobis ilma eriliste muudatusteta.

[murphy]

Vs: Lpc2478 Jtag

Aitame siis vahelduseks inimesi, tegin startup faili ymber pmst tegin keil startup to GCC startup converteri, tõsi mõned asjad tuli siiski käsitsi teha.
Lisan ka siia, ehk abiks mõnele.
Ei vastuta kui miski ei tööta nagu peaks, kõiki asju pole testinud.
Testitud aga kella osa.
Netist oli asja võimatu leida, tundub et GCC+keil kooslust kasutavad vähesed.
Jääb registrite bitinikerdus ära saab asju ilusa graaflisena teha nagu inimlik.

[murphy]

Vs: Lpc2478 Jtag

Veel juttu omaette.
NXP lehelt tasub koodi näidete suhtes kaugele eemale hoida.
vähemalt MCI ja USB lib, isegi yle yhe rea pole seal absurde ja buge täis.
Tekib selline tunne et mine anna vastu pead et sellist sodi yles riputatakse.
Ja veel tootja enda kodukal.


Hea näide

    CmdRespStatus = MCI_STATUS;    
    if ( CmdRespStatus & (MCI_CMD_TIMEOUT) )
    {
      MCI_CLEAR = CmdRespStatus | MCI_CMD_TIMEOUT;
    }

kus MCI_CLEAR register kustutab vastava biti MCI_STATUS registris kui seatud kõrgeks.
pmst siis kood tähendab
kustutame kõik status pitid ja igaks juhus yritame kustutada olematud, antud juhul(MCI_CMD_TIMEOUT);
Paar rida edasi oodatakse flagi, flagi mis enne potist alla lasti.

Sarnast jura on kogu kood täis
huvitaks kas tegelased testivad ka seda mida kokku käkivad.




Lisan veel updated startupi, irku osas oli yks asi muutmata jäänud.

[murphy]

Vs: Lpc2478 Jtag

veel näide võtab ikka muigama vahel, vähemalt pole koodi ymber kirjutajal igav
MCI_CLOCK &= ~(0xFF);
selle asemel et kohe teha MCI_CLOCK &= 0xFF00;

[qratman]

Vs: Lpc2478 Jtag

Selles viimases näites need laused päris samad ei ole. Ma arvan et see on edaspidise ühilduvuse tõttu kirjutatud "MCI_CLOCK &= ~(0xFF);". Selles mõttes et KUI tulevikus peaks see register tehtama 32 bitiseks, siis antud rida täidab oma ülesande ikka õigesti. Sinu variant aga nulliks kõrgemad 16 bitti.

Oletades et MCI_CLOK on 32 bitine siis:
MCI_CLOCK &= 0xFF00; tulemus: 0x0000FF00
aga
MCI_CLOCK &= ~(0xFF); tulemus: 0xFFFFFF00

Aga jah, hetkel on need jupid võrdsed.

[murphy]

Vs: Lpc2478 Jtag

12 bitti seepärast kirjutasin, tegelt speks ytleb veel
31:12 - Reserved, user software should not write ones to reserved
bits. The value read from a reserved bit is not defined.
seega isegi
MCI_CLOCK &= 0xF00;
oleks õige
See tulevik on omaette teema.
Speksi järgi ei tohi 1 kirjutada ja kuna väärtus on undef siis võib olla seal 1 ja 1and 1 annab 1.
Mõte oli et miks peaks ma optimeerimise sisse lylitama kui saab ise optimaalset koodi kirjutada ka.

Hetkel minu kood 519 rida (umbes 90% funktsionaalsusest)
ja orig kood 1375 rida.
Erinevus et minu kood töötab orig ei jõua esimesest käsust kaugemale.
ei anna ka viga sest while(1) ja timeouti pole on nende error handler