Yhteyden yrittäminen fdt:stä

PetriK · Viesti Kirjoittaja **PetriK** » 30 Loka 2007, 23:05

No niin, käytin muutaman tunnin testaukseen ja tulos ei muuttunut eilisestä. Kuten yleensäkin tällaisissa projekteissa, harvoin kaikki sujuu ja onnistuu ensimmäisellä yrityksellä.

Tästä pitäisi nyt sitten päästä ylöspäin - hyvät neuvot olisivat tarpeen.

Alla viesti mitä lähetin RR:lle kun hän kysyi edistymisestä. Tästä näkee mitä on verifioitu ja yritetty ja vähän mitä pohdintaa on omassa mielessä menossa.

Isot linjata on - joko ECU on mennyt rikki avatessa tai sitten tämä itse tehty ohjelmointilaite/softa eivät toimi yhdessä.

Jos ennättäisi päivän aikana soittaa sinne Glyn:lle niin ehkä pitäisi pistää myös e8 tilaukseen... mutta FDT antoi muistaakseni siitä ilmoituksen että kerneliä ei ole testattu sen kanssa - joten siksi sarjaportin kautta ensin tällaista yritystä.

--->

Here is the log from programmer, please note from the beginning that I can see a burst of bits going to the processor RX pin on the scope.

Clock Frequency = 10.0000MHz, Clock Mode = 0, CKM = 4, and CKP = 2
Connecting to device 'SH/7052F' on 'COM1'
Configuration:
'USER Mode', direct connection
Opening port 'COM1' ...
Loading Comms DLL
Loaded Comms DLL
Sending inquiry for getting line size
Error No 15005: 'COM1' read time out
Error No 15005: 'COM1' read time out
Error No 15019: Download() failed

- Verified MD1, FWD on the board power on. MD0, MD1 were OK.
- Verified RSET by looking at the scope and datastream missing for a second
- Verified that the TTL converter works by hooking it into a loop and it gives characters back to the terminal
- Verified with scope that the Flash Development Toolkit software actually sends a burst of data to the receiving pin on the cpu
- Tried various baud settings on programming line

Can not see anything coming out from the processor pin on the scope. Anyway as you know my scope is not one of the best ones.

- Verified that the processor power is around 3.7v, the TTL signal is at 4.5v when it reaches the cpu. That I dont know if its right or wrong ?
- I had a problem with building the RS-TTL converter, forgot to cut one line from the experimental board (vero board). But that was on the RX line as far as I could see it so that should not affect TX.
- D404 was maybe dremeled too much, but that is hooked up to the IC401 which I assume is really FWD signal for Yoshbox writing signal. The purpose of this should be verified.
- Dremeled off the R906. All the other data lines have 100ohm, so installed 100ohm there. But thats on TX line after the point I used the scope so should not effect.
- On old fztat the FWD signal is put on +12V when programming, that sounds way too much for this processor but I really should find out ?
- Maybe the flash development toolkit does not work with self made TTL interface, maybe FZTAT works ?
- Maybe the baud rate is incorrect ?

Edited By PetriK on 1193778987

busajasa · Viesti Kirjoittaja **busajasa** » 30 Loka 2007, 23:52

Tämmöinen osui vielä silmääni manuskasta.

Eli tuossa on vielä nuo moodit. Extended moodi muistaakseni tarkoittaa ulkoista muistia jota ei nyt pitäisi olla käytössä. Nuo jännite arvot tuolla ala laidassa kannattaa myös huomioida....

Pitää vielä huomenna himppasen lukaista tuota SCI osaa manuskasta. Oma-aloitteisesti sen SCIn pitäisi osata kätellä nopeus - eli hassua että sieltä ei tule mitään liikennettä nastoista...

PetriK · Viesti Kirjoittaja **PetriK** » 31 Loka 2007, 04:17

Tässä vielä mitä RR vastasi. Tässä Tuo PVcc on jäänyt ihan kokonaan huomiomatta.

Here is the log from programmer, please note from the beginning that I can see a burst of bits going to the processor RX pin on the scope.
Clock Frequency = 10.0000MHz, Clock Mode = 0, CKM = 4, nd CKP = 2
Connecting to device 'SH/7052F' on 'COM1'
Configuration:
'USER Mode', direct connection
Opening port 'COM1' ...
Loading Comms DLL
Loaded Comms DLL
Sending inquiry for getting line size
Error No 15005: 'COM1' read time out
Error No 15005: 'COM1' read time out
Error No 15019: Download() failed

- Verified MD1, FWD on the board power on. MD0, MD1 were OK
- Verified RSET by looking at the scope and datastream missing for a second
- Verified that the TTL converter works by hooking it into a loop and it gives characters back to the terminal
- Verified with scope that the Flash Development Toolkit software actually sends a burst of data to the receiving pin on the cpu
- Tried various baud settings on programming line
- Can not see anything coming out from the processor pin on the scope. Anyway as you know my scope is not one of the best ones.

- Verified that the processor power is around 3.7v, the TTL signal is at 4.5v when it reaches the cpu. That I dont know if its right or wrong ?

This CPU is a dual voltage chip. It has one voltage for the Core and another for the I/O. If you look on the chip pin out you will see there are Vcc power connections for the core and PVcc connections for Port Power supply. It could be running 3.3V core and 5V I/O or it could be running 3.3 and 3.3 in which case your TTL levels maybe confusing it.
The way to find out is measure the voltage on one of the PVcc pins

- I had a problem with building the RS-TTL converter, forgot to cut one line from the experimental board (vero board). But that was on the RX line as far as I could see it so that should not affect TX.
- D404 was maybe dremeled too much, but that is hooked up to the IC401 which I assume is really FWD signal for Yoshbox writing signal. The purpose of this should be verified.
- Dremeled off the R906. All the other data lines have 100ohm, so installed 100ohm there. But thats on TX line after the point I used the scope so should not effect.

If you power the ECU up with nothing connected except power what is the voltage at the harness pins of all these lines; Tx Rx FWE MD1?

- On old fztat the FWD signal is put on +12V when programming, that sounds way too much for this processor but I really should find out ?

I would not put 12V on any of those pins. The old FZTAT also required a 12V Vpp voltage which this cpu does not appear to have

- Maybe the flash development toolkit does not work with self made TTL interface, maybe FZTAT works ?

Everything I've read says the toolkit should work direct connect. Here is a stupid question, but just to cover the all the bases....Are you running the 232/TTL converter and the ECU off two different power supplies? Are you sure you have the 232/TTL connected to an ECU ground?

- Maybe the baud rate is incorrect ?

The manual suggests you should use either 9600 or 19200 at 8,n,1. It also talks about how the boot mode automatically measures the host baud and sets its baud automatically to match but it is unclear as to whether the User Mode does the same thing. Boot mode looks like it is more likely to work but would erase the entire chip. That would be bad to say the least.
Perhaps it is only possible to reflash the entire ecu as a whole from the harness connectors. The would be a usuable system for the factory as they have the source code but at the same time makes what we are trying to do very hard. Perhaps in the end it will be necessary to pull the code via the AUD interface and then flash via the FZTAT. You would only
have to notch one ecu of each type to get the code. Others you could just boot flash with that code + your map mods. I thought what I was doing was scary

If you can't get the fZTAT to work there is always the AUD. The code may tell us why the FZTAT doesn't work.

Edited By PetriK on 1193797060

PetriK · Viesti Kirjoittaja **PetriK** » 31 Loka 2007, 04:28

busajasa kirjoitti:Pitää vielä huomenna himppasen lukaista tuota SCI osaa manuskasta. Oma-aloitteisesti sen SCIn pitäisi osata kätellä nopeus - eli hassua että sieltä ei tule mitään liikennettä nastoista...

Saatko samalla katsottua jännitetasot myös TTL signaalille. Jos se nyt vaan on niin että 5V on liikaa ?

Mutta jos luin oikein tuota kuvaasi (hieno homma että tuo löytyi) niin 5.0V eli kun käytän suoraan Vcc:tä MD1 ja FWD:ssä niin tuon pitäisi toimia ?

Mutta sen sanon että on hienoa yrittää näitä asioita tällaisessa porukassa jossa on osaamista tällä tasolla !

65-1193743727 · Viesti Kirjoittaja **65-1193743727** » 31 Loka 2007, 09:03

Voi olla tyhmä kysymys, kun en ole penkonut täysin läpi mitä tähän mennessä on tehty, mutta oletko selvittänyt mitkä ovat prossun käyttöjännitteet, core ja i/o? Tuo 3,7V kuulostaa vähän erikoiselta, 3,3V tai 5V olisi tyypillisempi.

PetriK · Viesti Kirjoittaja **PetriK** » 31 Loka 2007, 09:10

TTL tasoisessa signaalissa nolla on +5v ja looginen 1 on kun signaali on maadoitettu. Olisikohan tässä syy miksi CPU ei ole pystynyt työntämään mitään ulos kun pullup:t ehkä puuttuvat ? Mä en nyt muista miten tuo boardin linjat menee, mutta tässä yksi kohta tarkistettavaksi.

Edelleen kaikki muutkin vinkit kullan arvoisia...

F-ZTAT programming manual (new version for 7051)

ps. Mittasin tuon käyttöjännitteen skoopilta silmämääräisesti ja muistin väärin. On varmaan ihan oikein koska prossu käy ja kukkuu. Tarkistan vielä tänään illalla.

Edited By PetriK on 1193814719

65-1193743727 · Viesti Kirjoittaja **65-1193743727** » 31 Loka 2007, 09:33

Noiden pull-up:ien selvittämisessä auttaa kun mittaat linjojen (RXD, TXD, jne) jännitteen kun ECU:ssa on virrat päällä ja ohjelmointilaite ei ole kytkettynä. Nähtävästi niiden pitäisi silloin olla 1-tilassa (3,3/5V), ainakin mikäli pull-upit ovat olemassa.

Tuo prossun TXD-linjan pull-up vaikuttaa vähän hassulta, en ihan suoraan hahmota sen funktiota. Pitäisi ehtiä vilkaisemaan prossun datalehteä/manuaalia, niin varmaan selviäisi.

PetriK · Viesti Kirjoittaja **PetriK** » 31 Loka 2007, 09:38

Tässä vielä vastaava vähän tuoreempi datatalehti liittyen FDT:hen jossa on samaa asiaa käsitelty. Vieläkään ei löytynyt suoraan 7052:seen sopivaa...

Joo mitataan kun pääsen sopivan pöydän ääreen illemmalla.

FDT application note (with interface schematic)

Lisäksi löytyi tällainen tieto että FDT on juuri tuolle prossulle oikea ohjelmointityökalu:

SH7052F HS6400FDIW3SR
HS6400FDIW3SRF Flash Development Toolkit V.3

Flash software compatibility

Ja tässä application note FDT:hen liittyen:
FDT application note with interface circuit

Edited By PetriK on 1193816727

PetriK · Viesti Kirjoittaja **PetriK** » 31 Loka 2007, 12:31

AVcc=5.05v (Processor pin 53)
PVcc=5.05v (Processor pin 158)
Vcc=3,43v (Processor pin 19)

Vss=0v

Rx=5,00v (not connected stage @ processor and harness)
Tx=5,05v (not connected stage @ processor and harness)

Vcc=5.05v (Harness connector voltage)

Rx=5,05v (connected stage @ processor)
Tx=5,05v (connected stage @ processor)

Eli ei johdu pull uppien puutteesta.

Mutta yksi asia löytyi: FWE = 0 tai 4.0v, tuo kiertää 1KOhm kautta.Kun kytken FWE:n pois käytöstä niin prosessorin FWE nasta menee tasolle 0v. Ilman 1K kytkettäessä suoraan menee prosessorin FWE nasta tasolle 5.01v - mutta tällöin löysin prossun jännitesyötössä häiriöitä muutaman millivoltin sakara-aallon verran.

Olin kytkenyt tuon 1KOhm vastuksen ledille (eli tavallaan jännitteenjakajan keskelle) eikä +5V tasolle

ECU toimii normaalitilassa edelleen, tuo mittariston data stream tulee ulos nätisti.

Uusi kysymys on että onkohan jännitesyötössä tai maadoituksessa jotain vikaa ?

Edited By PetriK on 1193827170

busajasa · Viesti Kirjoittaja **busajasa** » 31 Loka 2007, 15:18

Pikaisesti ainoat asiat jotka tuli mieleen on tuo mitä RR mainitsi:

-onko maa potentiaali sama läpi siirto ketjun - toisin sanoen sekä ECU että host näkevät samat potenttiaali erot?
-eihän virta lopu ja aiheuta oskillaatiota ja alenemia?

ECU herää henkiin se tiedetään - ei ole rikki; siis lisää experimentaalia

Kun ECU herää henkiin niin onko Tx nastassa mitään elämää? Itseäni hieman härnää se että manuskassa ei missään sanota miten tuolta Flashilta luetaan dataa - kirjoittamisesta on kyllä tietoa. FDT se varmaan osaa tehdä temput, mutta lähinnä se että pitääköhän ECU olla ajettuna johonkin tilaan että alkaa syöttää Tx:ään dataa. Pahimmillaanhan voi olla että softassa vaaditaan joku input kombinaatio (muu kuin programming mode) jotta tuo flashin takana oleva SCI alkaa herätä henkiin. Ja tuo kombinaatiohan on vain Denson tiedossa jos näin on ;-(

Sitten ei taida olla muuta keinoa kuin se toinen liitin jota kautta koneeseen pitää mennä - ainakin eka kerran jotta saa reverce engineerattua sen pinni kombinaation...

No ei maalailla vielä piruja seinälle.. edelleen uskon että siguna tasot kun saadaan kohdalleen ja oikeat pinni kombinaatiot niin jotain pitäisi tapahtua.

Eli onko Rx/Tx nastoissa mitään elämää silloin kun kone on normaalisti käynnissä? Nythän on ilmeisesti pyritty ajamaan konetta userprogramming modeen ja sitten pyritty tutkimaan noita Tx/Rx nastoja?

PetriK · Viesti Kirjoittaja **PetriK** » 31 Loka 2007, 16:48

Yksi veikkaus on että jotain on mennyt harjatessa rikki joka vaikuttaa vain ohjelmointiin ja se pitäisi nyt löytää. Signaalit tulevat perille, joten ohjelmointitilassa ecussa tapahtuu jotain joka muuttuu. Pyörässä on kyllä toimiva ecu - mutta ennen kuin tiedetään että missä on vika ettei lukeminen onnistu niin ei viitsisi sitä ottaa tähän kokeiluun mukaan.

Virtaoskillaatio - ei tullut mieleenkään. Testaa illalla 12v akulla, sitten selviää. Samoin löysin eilen illalla että maadoitus ei ole aivan aukoton, yksi E (olisiko ollut E02, tarkistan) on kytketty eri paikkaan kuin muut). Tuo maa ei ole mulla kytketty, mutta mun mielestäni tuo meni enemmänkin sinne injektroien ja puolien ohjaukseen. Maapotentiaalin mahdollista eroa olen pyrkinyt mittaamaan skoopilla ja yleismittarilla. Ainut iso juttu on tuo kohtuullisen iso vaihtojännite jota regulaattori pukkaa lävitse ja joka menee suodattamatta tuonne +5V linjaan. Sen perusteella tuo maadoitus pitää kyllä tutkia tarkemmin.

Kaivoin tänään lounaan aikoihin renesasin sivulta sisältäen myös tuon datan tiedot, siellä on kuvattu bytetasolla miten data liikkuu tyyliin...

Initialization:
Send 20h, max 30 times
Receive 00h, sychronize baud rate
Send xxh, command
Receive xxyyzz, result
...

Dokkarit taisi jäädä läppärille joka ei tullut nyt mukaan, joten ne täytyy laittaa jakoon tänne myöhemmin.

Eli mielestäni tuon portin ei pitäisi mitään työntääkään ulos muuta kuin kysyttäessä. Ainakaan missään muussa tilanteessa en ole nähnyt muuta kuin käden vapinasta tulleita piikkejä tuossa signaalissa.

Sen sijaan se toinen sarjaportti työntää ulos tavaraa koko ajan, se joka on liitetty mittaristoon.

Tuo diodi johon viittasin aiemmin siinä FWE linjassa, sen tarkoitus lienee enabloida FWE joissain tilanteissa - täytyy mitata tarkemmin mihin se menee. Se on niin päin että se pystyy syöttämään jännitteen FWE:lle, joka tarkoittaa että ecu itse enabloi FWE:n joissain tilanteissa. Mutta voihan se olla jotain muutakin.

Kiitos vinkeistä - noilla pysyy taas puuhailun parissa muutaman tunnin.

PetriK · Viesti Kirjoittaja **PetriK** » 31 Loka 2007, 21:59

No niin,

- ei ole ongelmia virransaannissa - testattu akulla, arttu vahvisti että rippeli on pieni.
- tuo D404 on ohjelmoinninaikainen asia, eli estämässä resetointia. Niin pitkälle ei vielä ole päästy.
- Jännitetasot on oikealla tasolla - varsinkin nyt kun FWE ei enään tule jännitteenjakajalta

Yksi asia tuli mieleen - varsinaisen ohjelman suoritus ei missään vaiheessa pysähdy vaikka FWE aktivoidaan. Tiedän tämän siitä että mittaridata jatkuu vaikka FWE on aktivoitu.

Tässä on nyt joku perustavaa laatua oleva asia jota ei vielä ole löydetty liittyen ohjelmointitilan aktivointiin.

Yritän ehtiä soittamaan sinne Glyn:iin ja tilata e8:n.

busajasa · Viesti Kirjoittaja **busajasa** » 31 Loka 2007, 22:05

Eli ei päädy on-board programming tilaan? Entä kun antaa sen softa resetin (RES nastaan muutos - joka ainakin manuskan mukaan pitäisi olla 0-->1) kun nuo nastat on asetettu FWE mukaan lukien oikeaan tasoon (ajautuu resettiin kun RES menee 0:aan mutta käynnistää exception handlerin kun nousee takaisin ylös)

Kaavioiden mukaan

MD1=1
MD2=1
FWE=1

ajaa reset tilasta tuonne user programming tilaan. Eli kone käynnissä -> nastat oikean tilaan --> reset....

Edited By busajasa on 1193861806

PetriK · Viesti Kirjoittaja **PetriK** » 31 Loka 2007, 22:19

Jep - jotain on pielessä. Skoopista loppui akut - ja taitaa meikäläiseltäkin tältä illalta olla tässä. Aivot menevät loopissa kun ei keksi mistä kiikastaa vaikka täältä palstalta tuleekin todella hyviä vikkejä.

Pitäisi saada jostain pari käytännön vinkkiä. Onko esim. FDM:ssä joku signalointi joka tekee resetit ohjelmallisesti ? Onko joku signaali vieläkin väärin päin ? Onko mahdollisesti Tx nasta vaan hajonnut kun TTL konvertterissa oli bugi ensimmäisellä käynnistyskerralla (tosin silloin Tx linjassa oli 10K vastus joten epätodennäköistä)? Onko prossulla joku suojaus vielä päällä niin ettei FWD mene vahingossa päälle ?

Kärsimättömänä laitoin e8 tilauksen glynille, katsotaan saavatko mitään toimitettua pelkällä internettilauksella. Mailiin eivät ainakaan vastanneet. Noita tulee pari kappaletta, toisessa mukana evaluointiboardi 70xx sarjan vehje jolla voi myös harjoitella AUD väylän kanssa.

EDIT - edellisessä vastaavassa ECU projektissa meni yli kaksi kuukautta ja viestejä tuli noin 1000kpl. Joten tässä kyllä tietää mitä on tiedossa. Suurin ongelma siinäkin oli koodin lukeminen. Lopulta koodi luettiin byte kerrallaan sarjaportin kautta. Ohjelma asennettiin lisäkortilla prossun muistiväylään. Tämä hanke ainakin vaikuttaa alkumetreillä helpommalta.

Edited By PetriK on 1193862286

busajasa · Viesti Kirjoittaja **busajasa** » 31 Loka 2007, 23:12

En nyt löydä kuvaa siitä sun 232/TTL konvertterista. Voiko siinä olla jotain hämärää että signaali ei konvertoidu oikein/oikelle tasoille?

Tuosta softan ulos saamisesta olin itsekkin tuossa jo huolissani.. Tuota voisi ehkä kiertää siten että kun päästään siihen programming moodiin niin syötettään koneeseen softa joka suoltaa muistipaikat a:sta ö:hön sarjaporttiin. Flashaamaan kun pitäisi anyway päästä - makso mitä makso

Pitää huomenna jatkaa tuon manuskan kimpussa jos sieltä tulisi jotain valaisua miksi kontrolleri ei mene tuonne user programming modeen.