Yhteyden yrittäminen fdt:stä
Näin ne monesti tuppaa olemaan että laittesta ei ole yleensä syytä lukea softaa ulos - ainoastaan kirjoitaa uudempi. Näin tyypillisesti kaikessa embedded jutuissa. Valmistajallahan ei ole tarve kuin korkeintaan päivittää uusi softa sisälle. Softaversion proggis taas voi heittää jollain soppelilla pinnikombinaatiolla.timo3 kirjoitti:Voisiko se olla sillein että user programmer tila ei mahdollista kuin flash:n kirjoituksen ja vertaamisen.
Eli verratessa sinne kirjoitettaisiin mutta ei tallennetaisi ja se vaan vertaisi onko se sama kuin muistissa oleva data, mutta ei mahdollistaisi muistin uloslukemista
Ja tietyllä komennolla se antaisi diagnostikka tietoa antureilta.
Meinaa se japsipojan FKSWriter705X mahdollistaa vain muistiin kirjoittamisen miksi?
Tarviihan se kumminkin TxD ja RxD linjoja pelkässä kirjoituksessakin kättelyn takia ehkä
Kuitenkin jos flashays saadaan henkiin user programming modessa voisi olla mahdollista heittää tuonne koneeseen proggis joka lukee muistialueen alusta loppuun ja työntää dataa sarjaportin kautta ulos. Tuossakin pitäisi tietää se muistialue joka olisi vapaa kirjoitettavaksi eikä ajaisi yli noita olemassa olevia softia.
Mutta on ne saaneet noista subarun jne ecuista ulos proggikset ja ne perustuu samaan kontrolleriin. Eli kyllä sinne sisälle pääsee ja kyllä sieltä jotain kautta bytet uloskin saadaan.
Suoraa lukeminen FDT:llä kuullostaisikin lihan lapselisen helpolta
Muistaakseni Subarussa datat tulee CAN bussista. Eli ihan samasta kohdasta prosessoria. CAN:ssa taitaa myös olla SCK käytössä, mutta en ole ihan varma. Muistaakseni tuolla hakemistossa on kerrottu ns. automotive esitteessä että tässäkin prossassa olisi jo CAN tuki.
Tuo yllä näytetty kytkis on auton ecuun liittymistä varten juuri ennen CAN aikaa, ja yllätys yllätys tämäkin ECU oli denson valmistama. Kellosignaali tarvittiin ECU:lle, muuten ei data alkanut liikkumaan.
On Denson etu pitää ECU:t mahdollisimman samankaltaisina ja tehdä ohjelmissa ne tarvittavat muutokset eri pyörämallien ja merkkien välillä. Toki tämä tehdään vasta ecun toimitusvaiheessa, mutta se että prossut olisivat täysin ohjelmoituja eikä niitä voi muuttaa aiheuttaa varastoriskin jonka takia varmasti osittain siirryttiin flash prossujen käyttöön. Jos jokainen prossu pitää ohjelmoida ennen kuin se juotetaan piirilevylle syntyy tilanne jossa ECU:ja jää joskus varastoon - kun mallit muuttuvat, esim. saastepäästönormien yms. takia.
Siksi itse uskon että tämäkin ecu on ohjelmoitavissa ulkoa käsin. Tuo AUD liitin on ohjelmistokehitysliitin, se ei ole valmistuksenaikainen ohjelmointiliitin eikä myöskään auta Densoa varaston optimoinnissa.
FDT pitäisi yrittää nopeutta eri nopeuksilla, mutta mä en nähnyt kuin yhden purskeen siitä ulos. Kokeilin kyllä kaikki nopeudet vielä erikseen välillä 2.4-58k.
Manuaali kertoo 9.6k tai 19.2k - yksi edistysaskel on selvittää tuo SCK signaali, tai paremminkin sen puuttuminen.
Se IC101, sille tulee G+ eli kampuran/nokan asentotunnistin. Eli se ottaa ulkoisen signaalin ja muuttaa sen sakaramuotoon. Toisaalta se piiri voidaan myös kytkeä jännitteen avulla säätyväksi signaalikeneraattoriksi. RR sanoi että siihen nastaan 14 on kytketty output, mutta niin on myös SCK harness liittimeltä.
Tämä vaatii lisää tietoa - erityisesti noiden CAN liityntärajapintojen ymmärtämisestä.
Tuo yllä näytetty kytkis on auton ecuun liittymistä varten juuri ennen CAN aikaa, ja yllätys yllätys tämäkin ECU oli denson valmistama. Kellosignaali tarvittiin ECU:lle, muuten ei data alkanut liikkumaan.
On Denson etu pitää ECU:t mahdollisimman samankaltaisina ja tehdä ohjelmissa ne tarvittavat muutokset eri pyörämallien ja merkkien välillä. Toki tämä tehdään vasta ecun toimitusvaiheessa, mutta se että prossut olisivat täysin ohjelmoituja eikä niitä voi muuttaa aiheuttaa varastoriskin jonka takia varmasti osittain siirryttiin flash prossujen käyttöön. Jos jokainen prossu pitää ohjelmoida ennen kuin se juotetaan piirilevylle syntyy tilanne jossa ECU:ja jää joskus varastoon - kun mallit muuttuvat, esim. saastepäästönormien yms. takia.
Siksi itse uskon että tämäkin ecu on ohjelmoitavissa ulkoa käsin. Tuo AUD liitin on ohjelmistokehitysliitin, se ei ole valmistuksenaikainen ohjelmointiliitin eikä myöskään auta Densoa varaston optimoinnissa.
FDT pitäisi yrittää nopeutta eri nopeuksilla, mutta mä en nähnyt kuin yhden purskeen siitä ulos. Kokeilin kyllä kaikki nopeudet vielä erikseen välillä 2.4-58k.
Manuaali kertoo 9.6k tai 19.2k - yksi edistysaskel on selvittää tuo SCK signaali, tai paremminkin sen puuttuminen.
Se IC101, sille tulee G+ eli kampuran/nokan asentotunnistin. Eli se ottaa ulkoisen signaalin ja muuttaa sen sakaramuotoon. Toisaalta se piiri voidaan myös kytkeä jännitteen avulla säätyväksi signaalikeneraattoriksi. RR sanoi että siihen nastaan 14 on kytketty output, mutta niin on myös SCK harness liittimeltä.
Tämä vaatii lisää tietoa - erityisesti noiden CAN liityntärajapintojen ymmärtämisestä.
-
65-1193743727
Edelleenkään en ole ehtinyt pahemmin kahlailemaan noita Renesasin dokkareita läpi, eli kommentit perustuu vahvasti mutuun. Mutta veikkaisin, että tuo SCK ei nyt ole ongelman avain. Ymmärtääkseni sitä tarvittaisiin ainoastaan pitämään tiedonsiirto tahdissa ja nyt ongelmana on, että kontrolleri ei edes siirry user programming-tilaan. Selitys sille, että et näe mitään eloa SCK-nastassa voisi olla se, että kontrolleri alkaa tuottaa signaalia vasta programming-moodissa.
Normaali RS232-siirto sietää muutaman prosentin taajuusvirheen lähettäjän ja vastaanottajan välillä ongelmitta ja tähän päästään yleensä helposti ilman erillistä synkronointikelloa. Eli olettaisin vahvasti, että tuota SCK:ta ei tarvita kunhan vaan molemmat päät yrittävät kommunikoida oikealla taajuudella.
Normaali RS232-siirto sietää muutaman prosentin taajuusvirheen lähettäjän ja vastaanottajan välillä ongelmitta ja tähän päästään yleensä helposti ilman erillistä synkronointikelloa. Eli olettaisin vahvasti, että tuota SCK:ta ei tarvita kunhan vaan molemmat päät yrittävät kommunikoida oikealla taajuudella.
-
65-1193743727
Selailin tässä aamukahvin aikana vähän noita dokkareita. Mun ymmärtääkseni user programming-moodiin siirtyminen tapahtuu seuraavasti:
-Kontrolleri resettiin (RESET = 0)
-Mode-pinnit oikeaan tilaan (FWE = 1, MD2 = 1, MD1 = 1, MD0 = 1)
-Kontrolleri pois resetistä (RESET = 1)
Jos nuo kaikki signaalit ovat oikein kontrollerin pinneillä, niin pitäisi toimia.
MUTTA, user program-moodi edellyttää, että flashiin on tallennettu koodi, jota lähdetään tässä tilanteessa suorittamaan ja joka hoitaa yhteydenpidon PC:n suuntaan sekä flashin lukemisen ja kirjoittamisen. Eli saattaa olla, että tätä koodia ei löydy kontrollerilta ja mahdollisesti tässä tapauksessa sitten suoritetaan normaalia ohjelmakoodia.
User boot-moodissa tämä flashin luku- ja kirjoituskoodi taas ladattaisiin PC:ltä kontrollerin RAMiin, jolloin sitä ei tarvitsisi olla valmiina flashilla. Mutta tuon boot-moodin kanssa kannattaa olla varovainen. Nimittäin jos oikein ymmärsin, niin boot-moodiin siirryttäessä kontrolleri ensin neuvottelee yhteyden kuntoon PC:n kanssa, sitten pyyhkii flashin(!) ja sen jälkeen jää odottamaan ohjelmakoodia PC:ltä.
-Kontrolleri resettiin (RESET = 0)
-Mode-pinnit oikeaan tilaan (FWE = 1, MD2 = 1, MD1 = 1, MD0 = 1)
-Kontrolleri pois resetistä (RESET = 1)
Jos nuo kaikki signaalit ovat oikein kontrollerin pinneillä, niin pitäisi toimia.
MUTTA, user program-moodi edellyttää, että flashiin on tallennettu koodi, jota lähdetään tässä tilanteessa suorittamaan ja joka hoitaa yhteydenpidon PC:n suuntaan sekä flashin lukemisen ja kirjoittamisen. Eli saattaa olla, että tätä koodia ei löydy kontrollerilta ja mahdollisesti tässä tapauksessa sitten suoritetaan normaalia ohjelmakoodia.
User boot-moodissa tämä flashin luku- ja kirjoituskoodi taas ladattaisiin PC:ltä kontrollerin RAMiin, jolloin sitä ei tarvitsisi olla valmiina flashilla. Mutta tuon boot-moodin kanssa kannattaa olla varovainen. Nimittäin jos oikein ymmärsin, niin boot-moodiin siirryttäessä kontrolleri ensin neuvottelee yhteyden kuntoon PC:n kanssa, sitten pyyhkii flashin(!) ja sen jälkeen jää odottamaan ohjelmakoodia PC:ltä.
Jep - tuo softa pitäisi olla siellä. Kokeilin aiemmin jo boot modeakin, muttei silloinkaan yhteyttä.
Speksin mukaan prossun pitäisi vastata kun oikea baud rate löytyy - nyt ei vastaa, ei boot modessa eikä user programmer modessa. Viimeksi kyllä baud rate oli auto, nyt on selvinnyt että pitäisi olla 9.6 / 19.2k.
Mulla oli muutamia vuosia sitten samanlainen ongelma auton kanssa, silloin tuo SCK tarvittiin jotta ECU osasi synkronoitua signaaliin. Muistaakseni tuo laite josta yllä oleva kytkis on tuottaa 9.6k signaalia, joten sitäkin täytyy kokeilla. Laite kun on valmiiksi rakennettu joten se täytyy vaan johdottaa oikein. Jos ei onnistu niin sitten SCK IC101/177G:n kytkis täytyy yrittää piirtää ja ymmärtää. Tuota signaalia ei varmasti ole lailtettu tuohon turhaan - koska esim. SDS signaalista puuttuvat komponentit josta tietää että se ei ole käytössä. Sen sijaan SCK:sssa kaikki komponentit ovat paikallaan.
Testataan nyt viikonloppuna lisää.
Kohta otan pyörästä iskemättömän ecun irti ja kokeilen silllä) Ainakin erilaiset hyökkäysstrategiat ja taktiset kuviot alkavat olemaan selvillä jos tuota kokeillaan.
mutta antaa vaan tulla lisää ehdotuksia, kaikki sparraus on hyvästä koska se johtaa ajattelutoimintaan ja teorioiden testaukseen
Edited By PetriK on 1194018454
Speksin mukaan prossun pitäisi vastata kun oikea baud rate löytyy - nyt ei vastaa, ei boot modessa eikä user programmer modessa. Viimeksi kyllä baud rate oli auto, nyt on selvinnyt että pitäisi olla 9.6 / 19.2k.
Mulla oli muutamia vuosia sitten samanlainen ongelma auton kanssa, silloin tuo SCK tarvittiin jotta ECU osasi synkronoitua signaaliin. Muistaakseni tuo laite josta yllä oleva kytkis on tuottaa 9.6k signaalia, joten sitäkin täytyy kokeilla. Laite kun on valmiiksi rakennettu joten se täytyy vaan johdottaa oikein. Jos ei onnistu niin sitten SCK IC101/177G:n kytkis täytyy yrittää piirtää ja ymmärtää. Tuota signaalia ei varmasti ole lailtettu tuohon turhaan - koska esim. SDS signaalista puuttuvat komponentit josta tietää että se ei ole käytössä. Sen sijaan SCK:sssa kaikki komponentit ovat paikallaan.
Testataan nyt viikonloppuna lisää.
Kohta otan pyörästä iskemättömän ecun irti ja kokeilen silllä
) Ainakin erilaiset hyökkäysstrategiat ja taktiset kuviot alkavat olemaan selvillä jos tuota kokeillaan.mutta antaa vaan tulla lisää ehdotuksia, kaikki sparraus on hyvästä koska se johtaa ajattelutoimintaan ja teorioiden testaukseen
Edited By PetriK on 1194018454
Onko sulla kahta tietokonetta ja kahta RS232<>TTL muunninta
Olis mielenkiintoista nähdä mitä se FDT:n alussa lähettämä purske sisältää.
Varmaan FDT:n pitäisi osata kirjoittaa alussa sinne kontrollirekisteriin tiettyyn paikkaan tietyt bitit oikein, jolla määrätään yhteysnopeudet ja muut asiat sen keskustelun onnistumiseksi ECU:n ja FDT:n kanssa ja asettamalla sinne bitti tiettyyn tilaan saadaan myös SCK:n päälle.
Ja tämäkään ei varmaan mahdollista muuta kuin flash:n tyhjennyksen ja kirjoituksen.
Arvaa oliko hatusta vedetty ajatus heh...
Sitä minäkin odottelen, että saataisiin jonkunlainen yhteys sinne ennen kuin käyn oman ehjän ECU:n testaukseen.
Edited By timo3 on 1194022070
Olis mielenkiintoista nähdä mitä se FDT:n alussa lähettämä purske sisältää.
Varmaan FDT:n pitäisi osata kirjoittaa alussa sinne kontrollirekisteriin tiettyyn paikkaan tietyt bitit oikein, jolla määrätään yhteysnopeudet ja muut asiat sen keskustelun onnistumiseksi ECU:n ja FDT:n kanssa ja asettamalla sinne bitti tiettyyn tilaan saadaan myös SCK:n päälle.
Ja tämäkään ei varmaan mahdollista muuta kuin flash:n tyhjennyksen ja kirjoituksen.
Arvaa oliko hatusta vedetty ajatus heh...
Sitä minäkin odottelen, että saataisiin jonkunlainen yhteys sinne ennen kuin käyn oman ehjän ECU:n testaukseen.
Edited By timo3 on 1194022070
Oletan että ulkopuolelta ei pääse rekistereihin käsiksi - vain kontrollerin oma CPU voi sen tehdä.timo3 kirjoitti:Onko sulla kahta tietokonetta ja kahta RS232<>TTL muunninta
Olis mielenkiintoista nähdä mitä se FDT:n alussa lähettämä purske sisältää.
Varmaan FDT:n pitäisi osata kirjoittaa alussa sinne kontrollirekisteriin tiettyyn paikkaan tietyt bitit oikein, jolla määrätään yhteysnopeudet ja muut asiat sen keskustelun onnistumiseksi ECU:n ja FDT:n kanssa ja asettamalla sinne bitti tiettyyn tilaan saadaan myös SCK:n päälle.
Arvaa oliko hatusta vedetty ajatus heh...
Sitä minäkin odottelen, että saataisiin jonkunlainen yhteys sinne ennen kuin käyn oman ehjän ECU:n testaukseen.
Itse olen yrittänyt tulkita tuota mode juttua. Tuo mitä Arttu kirjoitti on totta. Eli pitäisi olla keskeystyskäsittelijä joka tekee jotain - tai se voi olla vain kiinni siitä että keskeytysvektoriin ei kirjoiteta mitään hadleri osoitetta vaan palataan takaisin ohjelman suoritukseen.
Silti uskon että joku keino tuonne on upottaa uusi softa. Olisi laitevalmistajan kannalta ihan liian kallista vaihtaa sekä HW ja SW jos koodista löytyy bugi. Taas ei taida ollakkaan sellaista koodia olemassa jossa ei olisi bugi riskiä. Tai jos Densolla on ollut niin noiden heppujen kanssa voisi perustaa firman
Edelleen olen sitä mieltä että kyllä tuonne uuden softan saa, mutta minkä moodin kautta on taas eri asia. Samoiten olemassa olevan softan ulos lukeminen ei ole millään tavalla itsestään selvyys sillä ei ole laitevalmistajan intresseissä ensinkään saada vanhaa softaa pelistä ulos.
User programming mode olisi hyvä sillä silloin voi jonkun verran vaikuttaa siihen mitä ja minne menee, kovasti vain näyttää että ohjalistossa on tietynlainen esto/tuettomuus tuolle. Boot progamming modessa erasoidaankoko muisti alue uusiksi - ihan kuin Arttukin mainitsi.
Eli tuo ei meitä sitten paljoa auta jos tuo on se millä SCI herää. Laitevalmistajan kannaltahan on yksi ja sama flashaavatko koko muistin vai osan - uusi softa sinne olisi kuitenkin tarkoitus laittaa.
Toki voisi yrittää laittaa pinnejä boot programmin moden mukaiseen asentoon ja katsoa herääkö SCI sitten?
Muuten sama kuin User programming mode mutta MD1=0.
Tällä hetkellä täällä on 1 palvelin, 2 pöytäkonetta, 4 läppäriätimo3 kirjoitti:Onko sulla kahta tietokonetta ja kahta RS232<>TTL muunninta
Olis mielenkiintoista nähdä mitä se FDT:n alussa lähettämä purske sisältää.
Varmaan FDT:n pitäisi osata kirjoittaa alussa sinne kontrollirekisteriin tiettyyn paikkaan tietyt bitit oikein, jolla määrätään yhteysnopeudet ja muut asiat sen keskustelun onnistumiseksi ECU:n ja FDT:n kanssa ja asettamalla sinne bitti tiettyyn tilaan saadaan myös SCK:n päälle.
Ja tämäkään ei varmaan mahdollista muuta kuin flash:n tyhjennyksen ja kirjoituksen.
Arvaa oliko hatusta vedetty ajatus heh...
Sitä minäkin odottelen, että saataisiin jonkunlainen yhteys sinne ennen kuin käyn oman ehjän ECU:n testaukseen.
, ja kaikki noi jollain tavalla perheellä käytössä. (3 lasta + vaimo + meikäläisen työkone + videoeditointi + ...) ja tähän projektiin hankittuna: loggaava skooppi, 3 erilaista ttl-rs232 konvertteria, 2 busan ecua (+ pyörän oma). Lisäksi entuudestaan 2 auton ecua ja 4 tai 5 erilaista ohjelmointilaitetta ... + muuta sälää.Mutta aivot on hukassa...
Toi FDT:n ensimmäinen purske on synkronointipurske, muistaakseni 0x00 max 30 kertaa. Eli näkyy skoopilta että jotain tulee kerran ja sitten ei enempää - voi olla että on tuo 30kertaa, en ole saanut kunnolla asettua vielä triggeriä.
Eli ongelma tulee protokollan synkronointivaiheessa kun ecu ei vastaa. Sen pitäisi vastata jos taajuus on riittävän lähellä asetettua taajutta.
Yksi lisätiedon murunen tulisi jos jostain saisi informaatiota ns. Denson racing ecu:sta. Siinä on käsittääkseni erlaisia loggausvaihtoehtoja.
Tuo että pyöriikö siellä tarvittavat ohjelmat onkin sitten ongelmallisempi juttu, mutta meillehän riittää jos yhdestä ecu:sta saa ladattua ohjelman ja sitten muut voivat sarjaportin kautta tehdä ohjelmoinnit - siksi tämä sarjaportti kiinnostaa. Kynnys mennä AUD liitintä avaamaan muille kuin tähän keskusteluun osallistuville voi olla korkea.
Mutta yritetään lisää kunhan uusi päivä valkenee - kokeilen todennäköisesti ensin tuota ulkoista SCK:ta. Jotenkin aiempi kokemus kertoisi että se vaadittiin silloin ja voi olla että vaaditaan nytkin.
Sitten tuo boot mode on uudestaan kokeilemiseen liittyvän riskin arvoinen juttu, AUD liittimen toiminnan voi testata tyhjälläkin flash:lla.
No sitten pari sanaa tuosta mittaristodatasta, se kulkee noin 7kbit/s vauhdilla ja sen avulla voi ohjelmoida seurattavaksi mitä vaan erillistä anturia. Autossa antureiden lisäksi sen avulla pysyi lukemaan kerrallaan yhden muistipaikan. Tuo on juuri miten noista hankalista autoista saatiin se data luettua. Ohjelmanvalmistajan kannattaa rakentaa sinne readmemorybyte tyyppinen ominaisuus koska voi olla että halutaan lukea jotain muutakin kuin kertaalleen määriteltyä dataa. Ongelma tuossa on se että se ei ole standardi PC UART:n mukainen. Se mikä pelottaa on että jostain syystä Suzuki olisi valinnut että myös tämä sarjaprotokolla ei ole standardin mukainen vaan juuri tuo 7kbit/s - mutta en kyllä ymmärrä miksi olisivat tämän tehneet.
Viimeksi asioita löytyi paljon tutkimalla google.co.jp:n avulla erilaisia hakuvaihtoehtoja. Ehkä tässäkin saattaisi löytää jotain sieltä... ?
Pientä edistymistä - MD1 maadoittaminen ja sen jälkeen reset aiheuttaa mittaridatan häviämisen. Mittaridata palautuu kun MD1 irroitetaan. Eli MD1 signaalilla on vaikutusta.
FWE ei vaikuta riippumatta siitä onko MD1 kytketty vai ei.
Yhteyttä FDT:hen ei (vielä) synny.
FWE:n pitäisi kyllä vaikuttaa ? Jäin vielä miettimään että voisiko tuo rikkinäinen diodi vaikuttaa myös resetoinninaikaiseen käyttäytymiseen ?
Edited By PetriK on 1194077487
FWE ei vaikuta riippumatta siitä onko MD1 kytketty vai ei.
Yhteyttä FDT:hen ei (vielä) synny.
FWE:n pitäisi kyllä vaikuttaa ? Jäin vielä miettimään että voisiko tuo rikkinäinen diodi vaikuttaa myös resetoinninaikaiseen käyttäytymiseen ?
Edited By PetriK on 1194077487
Jos se menee siihen mittaristodatan kautta lukemiseen, ei sen meille pitäisi ongelmaa aiheuttaa tuo 7kbit/s nopeus.
Tekee vaikka pic:llä pienen konventterin joka muuttaa sen pc:lle ymmärtävään nopeuteen.
asm:lla sen vääntö ei multa onnistu, mutta picbasic:ssa on valmiina käskyt, jota soveltamalla se pitäisi onnistua, sitten tekee visualbasic:lla ohjelman jolla lukee konvertteria
Picbasic Plus
SERIN PORTA.0 , 24660 , P_ERROR , [SerData]
BaudRate 8-bit no-parity inverted 8-bit no-parity true 7-bit even-parity inverted 7-bit even-parity true
2400 16780 396 24972 8588
4800 16572 188 24764 8380
9600 16468 84 24660 8276
Tosta laskemalla 4800 välistä 9600 paljon luku pitää olla 7kbit/s:llä
Tai sitten ihan puhtaasti pc:llä vaikka lpt portin kautta 8253 timerin avulla synkkaa sen itse softalla, windows:n puolla saattaa olla tulla liikaa heittoa moniajon takia, mutta vanhalla käyttiksellä jonka saa bootattua dossin puolelta käyntiin synkkaus ainakin onnistuu.
Onhan nuo vähän purkka viritelmiä, mutta sehän tosiaan riittää, kun saadaan ainakin kerran se flash luettua sieltä.
Tekee vaikka pic:llä pienen konventterin joka muuttaa sen pc:lle ymmärtävään nopeuteen.
asm:lla sen vääntö ei multa onnistu, mutta picbasic:ssa on valmiina käskyt, jota soveltamalla se pitäisi onnistua, sitten tekee visualbasic:lla ohjelman jolla lukee konvertteria
Picbasic Plus
SERIN PORTA.0 , 24660 , P_ERROR , [SerData]
BaudRate 8-bit no-parity inverted 8-bit no-parity true 7-bit even-parity inverted 7-bit even-parity true
2400 16780 396 24972 8588
4800 16572 188 24764 8380
9600 16468 84 24660 8276
Tosta laskemalla 4800 välistä 9600 paljon luku pitää olla 7kbit/s:llä
Tai sitten ihan puhtaasti pc:llä vaikka lpt portin kautta 8253 timerin avulla synkkaa sen itse softalla, windows:n puolla saattaa olla tulla liikaa heittoa moniajon takia, mutta vanhalla käyttiksellä jonka saa bootattua dossin puolelta käyntiin synkkaus ainakin onnistuu.
Onhan nuo vähän purkka viritelmiä, mutta sehän tosiaan riittää, kun saadaan ainakin kerran se flash luettua sieltä.
-
65-1193743727
Katsoitko skoopilla mitä reset tekee kun MD1 on maadoitettuna?PetriK kirjoitti:Pientä edistymistä - MD1 maadoittaminen ja sen jälkeen reset aiheuttaa mittaridatan häviämisen. Mittaridata palautuu kun MD1 irroitetaan. Eli MD1 signaalilla on vaikutusta.
FWE ei vaikuta riippumatta siitä onko MD1 kytketty vai ei.
Yhteyttä FDT:hen ei (vielä) synny.
FWE:n pitäisi kyllä vaikuttaa ? Jäin vielä miettimään että voisiko tuo rikkinäinen diodi vaikuttaa myös resetoinninaikaiseen käyttäytymiseen ?
Jos nyt oikein ymmärsin tuon FWE:n ja vahtikoiran yhteyden, niin se rikkinäinen diodi voi aiheuttaa tilanteen, jossa vahtikoira resetoi kontrolleria jatkuvasti silloin kun se ei suorita normaalia koodia. FWE:n ylös nostamisen pitäisi poistaa vahtikoira käytöstä tuon diodin kautta. Eli nyt kun diodi on rikki, niin ohjelmointitilaan siiryttäessä vahtikoira ei saa signaalia ja resetoi samantien kontrollerin.