Members Login
Username 
 
Password 
    Remember Me  
Post Info TOPIC: Using AUD interface to read the memory contents


Guru

Status: Offline
Posts: 2338
Date:
Using AUD interface to read the memory contents


The AUD connector allows quite simple protocol to read and write to the 7052 processor address space. In e10a (the AUD interface kit) a refenrence is made that only RAM address can be read, anyhow the protocol itself does not limit the address space and it is possible that e10a is limited due to copyright issues - so its worth while to check if the flash rom area can be read with AUD protocol. If the flash rom can not be read, then at least an user level microkernel can be copied using AUD to RAM memory and then FDT can be used for reading the flash memory (all this in theory). The e10a AUD interface is available from Renesas for appr 2000usd (1600eur) - but with the limitation to access only RAM area, so we need to build sw and hw for the interface to try out the access to FLASH ROM area.

To be able to access the memory we need a program that according to the flowchart below executes the signal timing below. In prinsiple this is very simple to write - but unfortunately I have about 20 years since I have written C so need some help on this.


The logic is very simple and communications just uses seven one bit registers (PB0..PB6):
- PB5 (AUDCLK) is a clock signal that is programmed going up and down with a small inbuilt delay. I dont know if this should be synchronized with a clock or if it can vary a lot. But as it is used for reading and writing I would assume it not being so citical to have an exact pulsewidth on this.
- Set PB5 (DIRection) down to write to the bus
- Set PB4 (AUDSYNCinverted) down to start reading
- Send to the bus PB0,PB1,PB2,PB3 (AUDATA) a dummybit 0000 to start the sequence
- Wait for next PB5 cycle
- Send to the bus PB0,PB1,PB2,PB3 (AUDATA) a command 1010, i.e. read from memory
- Send to the bus PB0,PB1,PB2,PB3 (AUDATA) the memory address e.g. 0xffffc000 4 bits at a time by each PB5 clock pulse
- Set PB6 (DIRection) up
- Wait from the bus PB0,PB1,PB2,PB3 (AUDATA) to receive readyflag bits 0001: wait for each clockpulse until changed.
- Set PB4 (AUDSYNCinverted) up as a signal that we are ready to start reading the memory contents
- Read from the bus PB0,PB1,PB2,PB3 (AUDATA) the memory content, e.g. 0x01234567, four bits at a time.
- Repeat the above for each memory byte to be read...

The flowchart for the program is the following:
http://macmadigan.no-ip.com/Public/ECU/sh7052/AUD_read_flowchart.JPG


The signalling is the following:
http://macmadigan.no-ip.com/Public....ing.JPG


The HW interface to AUD bus is very easy and well described.
http://macmadigan.no-ip.com/Public/ECU/sh7052/AUD_hw_interface.JPG

All the related documents for this project with self explanatory names are found here:
http://macmadigan.no-ip.com/Public/ECU/SH7052/

For this project I have SH7086 RSK which I thought to be using. For easy trialling and bug finding I can just connect the PB0..PB6 directly to RSK7086 AUD connector and use e8a for monitoring the program and knowing exactly the memory contents with Renesas Embedded Workshop. The RSK7086 costs around 150usd from Renesas including e8a which can also be used as a programmer over the serial line. Alternatively a PIC could be used as suggested by bozo.
http://macmadigan.no-ip.com/Public/ECU/sh7052/RSK7086.jpg
RSK7086.jpg



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

I plan to build a simple uProcessor unit to handle all the timing and comms to the AUD lines, and see how far it can read.

Unfortunately I see that I've knocked two surface mount capacitors off my ECU, hopefully they're absence won't upset the AUD.

The datasheet doesn't make it clear whether data is latched on the rising or falling edge of the AUDCK signal, so a little bit of experimentation coming up.

MarkW

__________________


Guru

Status: Offline
Posts: 2338
Date:

Do you have piccies of your board - I mean propably you already know what those capasitors are for ... ?
http://macmadigan.no-ip.com/Public/ECU/Busa32bitPCB-1.jpg
http://macmadigan.no-ip.com/Public/ECU/Busa32bitPCB-2.jpg
http://macmadigan.no-ip.com/Public/ECU/Busa32bitPCB-3.jpg
http://macmadigan.no-ip.com/Public/ECU/Busa32bitPCB-4.jpg

The more interesting thing is that what top level language (PicBasic ?) do you think you will be using to write your sw ... ? Propably we could use the same top level structure, variable names etc. to compare the experiences... unless you are so fast that you have it up and running before I have managed to relearn C smile.gif)....

The key questions to me at this stage are e.g.

- Should there be a main loop or should I use interrupts for clock signal and reading the signal lines ? I mean, if the clock signal can vary in frequency or must every clock pulse be equal in lenght...

- What would the function look like for converting the 4 bit values to real bytes.

- Where should the program write the bytes ? I can start by writing to RAM and monitor those variables using e8 emulator, but the end aim is to get the program out...

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

Hi Petri, I plan to use the Parallax Propeller instead of a PIC. The reason being that this chip can quickly be configured to talk via USB to a hyperterminal running on my laptop, and also the chip has 8 independent processors on it which can run true parallel processing ... one process for talking to the ECU/AUD, another process for USB comms to the laptop, another process maybe for driving a few status LEDs and a couple of input switches (reset/stop/...).

http://www.parallax.com/Default.aspx?tabid=407

It's programmed in Parallax's own language, 'SPIN' ... quite simple, very powerful.

The chip itself is cheap (about 20 bucks) and no special hardware is needed to program it - the programming is done via the USB connection to my laptop. This means relatively fast cycle time from writing code to running it on the chip.

I do not think that there are any strict requirements on AUDCK, apart from not clocking too fast. The beauty of the propeller chip is that a separate process can handle the clock, and run independently of all other processes ... there is no need to use interrupts at all ... in fact the chip does not even support interrupts!

A separate process can divide addresses into 4-bit chunks, and assemble 4-bit data chunks into bytes for transmission up the USB connection.

All the laptop has to do is capture the data from the hyperterminal window and save it to a file.

I'll post an update as soon as I build a propeller-based e10a and test it. I have a couple of development boards lying around in my shed, so I expect to get something together within a day or two ...

__________________


Guru

Status: Offline
Posts: 2338
Date:

So there is three projects ongoing with this ecu now:
Z1000 with pic
SV1000 with parallax
and busa with RSK7086

I tried to experiment with the code yesterday and still in a process of how to build the actual software.

I think I will start by processing one memory address just to test this approach.
-The timer control is easy, no problems there.
-The programming flow is easy, no problems there either
- I am currently stucked in the thinking process, dont know yet how to link the program execution into the timer pulses. Maybe just generate all the bits ready for executing one memory address read sequence and then do the conversions in the beginning and end.



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Ok gents, please do not laugh - rather remember that its 20years since I have written C. Anyway this is what I came up as a sketch idea - so your comments would he appreciated...

aud signalling
AUD_signalling_read_timing.JPG

EDIT - moved the coding concept idea to an attachment which is here:
http://macmadigan.no-ip.com/Public/ECU/aud_pgm_draft.txt



-- Edited by PetriK at 15:35, 2007-11-15

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

I think your basic plan is sound by I think you have over complicated it. Instead of going with an interrupt driven routine and SELECT..CASE, I would go with a very basic sequenced routine using a basic wait statement following the basic form

Set control, data
wait();
toggle AUDCK
wait();

repeat

Here is an example

-- Edited by RidgeRacer at 20:38, 2007-11-13

__________________


Guru

Status: Offline
Posts: 2338
Date:

Excellent - Thanks, much more simplier and even the syntax looks impecceable smile.gif)

Btw. they say in the office that I often overcomplicate things, so your suggestion is propably much better to start with.

There seems to be a clock speed setting in the patent which makes me a bit worried if it allows frequency which may vary - but this is a good starting point. It will take a couple of days to get the he H74HC245 in place and the sw up and running, but then we will see how it goes.

The other thing is that I do not really understand the AUD patent fully. I talks a lot about brancing, but very little about reading a memory address. Btw. downloading in Renesas vocabularity means: downloading the programcode from PC to the processor flash memory.





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

First attempt to read ECU via AUD: semi-success.

I connected power (+12v) to pins 16 (batt.) and 17 (+B) of the ECU.
I connected earth to pins 34,50,51 of the ECU.
I observed +5v at pin 11 (Vcc) of the ECU.

so far so good, no puffs of smoke, and the ECU seems OK

I connected a parallax propeller to the AUD lines and ran some code to probe a few addresses in ROM and in RAM, and watched the results come spewing out via a hyperterminal on my laptop connected (via USB) to the propeller circuit.

After setting the mode (to RAM Monitor mode), the propeller sends the spare bits (4 zeros, %0000), sends a command (%1000, read byte), sends an address (32 bits, 4 bits at a time), then converts over to watch the AUDATA lines. These are supposed to go to %0000 until the ECU is ready, then change to %0001 when the ECU is ready and hasn't encountered any problems.

At this point I observe the result %0101 (5) which indicates 'bus error'. Successive clock pulses continue to yield the same result (%0101).

According to the datasheet for the 7052, error %0101 occurs under the following conditions:
1. word access to address 4n+1 or 4n+3
2. longword access to address not equal to 4n
3. longword access to on-chip I/O 8-bit space
4. access to external space in single-chip mode

Since I'm only making byte accesses, conditions 1, 2, and 3 above can't be the cause of the bus error.

That only leaves condition 4, whatever condition 4 means.

So, I now need to (a) investigate what condition 4 means and figure out if my code is accessing external space while the chip is in single-chip mode, and (b) double-check my code for any obvious errors.

At least I'm getting something out of the ECU, and at least the bits I'm getting out align with a documented error condition.

I'll call it a partial success (the cup is half full).

Cheers,
MarkW

__________________


Guru

Status: Offline
Posts: 963
Date:

Condition 4 seems pretty straight forward. The CPU thinks your trying to access and address the bus controller considers not ROM, RAM, or I/O. Have you verified your output signals with a scope? If you don't have a scope maybe you could write a step mode into your propeller software so it executes one output cycle and then holds till you press a button or something. Then you could check the data lines with a simple volt meter.

What addresses where you trying to read?

Address 0000:0000 is supposed to be in ROM space. I think that would be an easy one to start with. Easy to check, the data lines should be zero all the time during the address portion.

Anyway good results for a first try.



__________________


Guru

Status: Offline
Posts: 2338
Date:

Wow - that is fast up and running - very good !

As we also know that the first rom contents from 0000 onwards are interrupt vectors (reset, error conditions etc). Where as RAM is 0xFFFFxxxx. I hope you get the same bus error for both ROM and RAM.

Additional information may be that I vaguely recall reading from the patent that the addressing scheme as well as a particular device on the bus can be selected with a command bit combination.

aud command processing

As you may have noticed, in case you get to read the rom, the first bytes are most likely to be repeated. This is e.g. the beginning of the EVO code:

EB0:00000000 off_0:        .long 0x000098D2 ! Reset
EB0:00000004 dword_4:    .long 0xFFFF9B00
EB0:00000008 off_8:        .long 0x000098D2 ! Reset
EB0:0000000C                 .long 0xFFFF9B00
EB0:00000010 off_10:      .long 0x000098CC ! Error
EB0:00000014                 .long 0x000098CC ! Error
EB0:00000018                 .long 0x000098CC ! Error
EB0:00000014                 .long 0x000098CC ! Error
EB0:00000018                 .long 0x000098CC ! Error



-- Edited by PetriK at 15:10, 2007-11-15

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:


Just out of curiosity what is the processor clock speed and AUDCK speed you are using. Parallax propeller can run up to 80mhz ? I have read that the AUD can run 1/2, 1/4 or 1/8 of 7052 clock speed, but those limitations may be related to the tracing functions....

EDIT - did some searching on internet and found this:
When an illegal address access or a bus timeout is detected, a bus error interrupt is generated

I.e. bus error can occur also if AUDCK speed is too low ?







-- Edited by PetriK at 19:06, 2007-11-15

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

Thanks for the tips,

I was making attempts at memory starting from 0000:0000 and also from FFFF:8000, getting similar results each time.

My AUDCK clock was set really slow (1kHz) ... I don't know if that's a factor or not, but I'll speed it up by a factor of thousand or so and see if it makes any difference. I deliberately set it slow so as to be sure that I was nowhere near any fraction of the 7052 speed.

As I don't have a scope, I'll try RR's idea of pausing execution while I probe the AUDATA lines with a meter, and step through the code ... to make sure the signals I'm sending are the same as what I think I'm sending.

Oh, and just a really silly question ... I always assume that bit0 is the LSB ... do Hitachi/Renesas use the same system? i.e. the LSB goes on AUDATA0, the 2ndLSB goes on AUDATA1 etc ... (I'm hoping I was just sending commands and addresses in backwards ... )



__________________


Veteran Member

Status: Offline
Posts: 80
Date:

I was browsing the datasheet for the 7052 again, and stumbled over section 24.3.11, AUD Timing.

It appears that some activities must have minimum durations, specified as a minimum number of AUDCK cycles ... specifically the AUDRST reset pulse must last for at least 5 AUDCK clock pulses, and AUDMD set up time is 5 clock pulses. I was previously simply toggling these lines without sending any clock pulses (Section 17 AUD says nothing about this) ...

I also have another question ... would I need to use 5v logic? If the 7052 is in single chip mode, it looks like PVcc is 5v ... my propeller output bit high is ~3.3v logic ... perhaps I need to build an interface to convert between the logic voltage levels?

EDIT: the datasheet specifies input high voltage for AUDRST & AUDMD between Vcc-0.5 and PVcc2+0.3 (i.e. between 4.5v and 5.3v), all other pins can be between 2.2v and PVcc+0.3.

So looks like I only really need to build an interface for the RST and MD lines. The other lines (AUDATA, AUDSYNC, AUDCK) should be OK at 3.3v since this exceeds the logic high minimum of 2.2v

Further, if AUDMD is not connected, it gets pulled up internally ... great smile.gif, for RAM Monitor mode this is what I want, so I think I will leave the AUDMD line unconnected. Either that, or just force it high with a resistor to PVcc2.

Then all I have to do is ensure that AUDRST high goes to 5v when not asserted. For now it will probably be faster just do this with an external switch rather than build an interface and try to control it in software? If it works, I'll build a proper interface later ...



-- Edited by bozo at 23:33, 2007-11-15

__________________


Guru

Status: Offline
Posts: 963
Date:

If you look at datasheet table 24.4 DC characteristics it says the HI level min input for AUDRST and AUDMD is Vcc -0.5 which would be 4.5V which your 3.3V I/O can not reach.

The other AUD inputs look to be HI equals anything > 2.2V so they should be OK.

I would be worried however that the 5V output of the AUD might be dangerous to your propeller inputs. Do you have a link to a data sheet for your propeller?

As for LSB vs MSB;

Referring to the timing diagram Petrik posted up thread which shows an example address of FFFF:C000 it shows

Addr----0 0 0 C F F F F
------------------------
AUDbit3 0 0 0 1 1 1 1 1
AUDbit2 0 0 0 1 1 1 1 1
AUDbit1 0 0 0 0 1 1 1 1
AUDbit0 0 0 0 0 1 1 1 1

Given that the hex C shows as 1100 and not 0011 I think its safe to assume bit 0 is lsb

-- Edited by RidgeRacer at 02:44, 2007-11-16

__________________


Veteran Member

Status: Offline
Posts: 80
Date:

Thanks RR, your reply came in while I was editing my last reply.
Looks like we both spotted the same thing.
The propeller can handle the 5v inputs, so long as the current isn't excessive.
I'll need to check this and see if I need a small resistor in series to limit current into the prop.
Cheers,

EDIT: here's a link to interfacing the propeller to 5v ...
it looks like I've been lucky to not toast the input pins ...
safely interfacing 5v to propeller

-- Edited by bozo at 00:08, 2007-11-16

__________________


Guru

Status: Offline
Posts: 2338
Date:


7052 hardware manual, page 840 (real page, not the PDF page number) / paragraph 24.3.11 Aud timing:

RAM monitor output data delay time = min 7ns, max 80ns
RAM monitor clock cycle = min 100ns
RAM monitor clock low pulse width = min 45ns
RAM monitor output data hold time = 5ns
RAM monitor SYNC setup time = 20ns

Maybe this gives us some guidance on timing the signals correctly ?


aud timing

AUD timingAUD timing




-- Edited by PetriK at 09:16, 2007-11-16

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

I modified the AUDRST connection (for 3.3v/5v working) and put some current-limiting 1k resistors in series with the AUDATA lines, and managed to pull out all the code from 0000:0000 to 0003:FFFF, and all the code from FFFF:8000 to FFFF:FFFF!

I pulled the code out using longword reads, and it stumbled with a bus error at FFFF:E000. So I changed to byte reads from FFFF:E000 to FFFF:FFFF and got all the code out.

Yahoo!

Next jobs are to see if I can write, and to try and disassemble the code.

Here's a sample from the RAM area:
FFFF8000,0400E227, FFFF8004,E4E61DA6, FFFF8008,14500040, FFFF800C,D8D0D707, FFFF8010,40091006, FFFF8014,B3B7AFDD, FFFF8018,0A000808, FFFF801C,89DFFF77, FFFF8020,00402081, FFFF8024,7F57C5BC, FFFF8028,118A4462, FFFF802C,9D775846, FFFF8030,00002B07, FFFF8034,BFBA0EEF, FFFF8038,26000A32, FFFF803C,BC750CDF, FFFF8040,40021059, FFFF8044,75A4ED9E, FFFF8048,4400E400, FFFF804C,ED22DD4D, FFFF8050,20022005, FFFF8054,FB3CBCDD, FFFF8058,20020002, FFFF805C,D777CF6F, FFFF8060,20008414, FFFF8064,1AF6DDEC, FFFF8068,68400110, FFFF806C,75AC593F, FFFF8070,90828040, FFFF8074,F7BB4CBD, FFFF8078,00210000, FFFF807C,6557D57A,

EDIT: the scheme here is [address],[data],[space]...
Cheers,
MarkW

-- Edited by bozo at 12:34, 2007-11-16

__________________


Veteran Member

Status: Offline
Posts: 80
Date:

oh, and here's a couple of samples from the ROM area ...

00000000,00400000, 00000004,0ABAFFFF, 00000008,00400000, 0000000C,0ABAFFFF, 00000010,65C20000, 00000014,65C20000, 00000018,65C20000, 0000001C,65C20000, 00000020,65C20000, 00000024,65C20000, 00000028,65C20000, 0000002C,06310000, 00000030,E8310000, 00000034,65C20000,


00039194,B52484F3, 00039198,FE94D654, 0003919C,9DE4BFB4, 000391A0,D5C53C35, 000391A4,E3867B26, 000391A8,CCE615B6, 000391AC,0B382797, 000391B0,0EC9E209, 000391B4,F35BADCA, 000391B8,EA6B116B, 000391BC,859B258B, 000391C0,84F363C3, 000391C4,D654B524, 000391C8,BFB4FE94, 000391CC,3C359DE4, 000391D0,7B26D5C5, 000391D4,15B6E386, 000391D8,2797CCE6, 000391DC,E2090B38, 000391E0,ADCA0EC9, 000391E4,116BF35B, 000391E8,258BEA6B, 000391EC,FFFF859B, 000391F0,FFFFFFFF, 000391F4,FFFFFFFF, 000391F8,FFFFFFFF, 000391FC,FFFFFFFF, 00039200,FFFFFFFF, 00039204,FFFFFFFF, 00039208,FFFFFFFF, 0003920C,FFFFFFFF, 00039210,FFFFFFFF, 00039214,FFFFFFFF,

looks like the code ends at 0003:91EF, because everything after 0003:91F0 is full of FFFFFFFF

cheers,
MarkW

__________________


Guru

Status: Offline
Posts: 2338
Date:


I will buy you beer, mate !!! We just need to agree logistics ...

Also no timing issues smile.gif ??? That is very good !

But back to the business - can you share your pgm ? I just bought the components for physical connection and hope to get time at home to install everything this weekend...

About the codes you pulled - those makes sense. First and Third are boot from rom, Second and Fourth are error handlers just alike to the EVO code and in line with manual.

In EVO code there is empty areas in between the code areas. Those are clearly visible in idapro. On your code the first bytes indicate that there is code ROM segment also at 0040:0000 onwards and even from 652C:0000 and 0ABA:FFFF onwards ... which you surely noticed. Maybe worth while editing the pgm so that in case of a bus error just moving to the next byte - or dword read until reaching FFFF:0000 -1.




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

I'll post my code after I clean it up a bit. Right now it looks like a dog's breakfast and I'm too embarrassed to post it.

Regarding the interrupt addresses, they don't make sense. Maybe they're not stored in sequence? e.g. 652C0000 might indicate 0000:652C and 0ABAFFFF might indicate FFFF:0ABA ?? I need to start studying the software datasheets now.

I did see a vast sea of FFFFFFFFs between two continents of code in the ROM area as it was all blurring past my eyes in the hyperterminal window...

I wrote the code to halt execution upon bus error, so I'm confident that all the data I pulled is correct. I'm not so confident that the 1s and 0s are in the right order though ... my code might be assembling the 4-bit nibbles in the wrong order or back-to-front? I still need to check this, as I've been entirely focussed for the last 2 days on sucking out data and I've not been too concerned about getting my LSBs and MSBs in the right place.

time now for a beer.gif


__________________


Guru

Status: Offline
Posts: 2338
Date:

Yes, in evo code 1st and 3rd were ROM addresses.  2nd and 4th were RAM addresses - but then 0000:0040 does not make really sense as the interrupt vectors contunue further if I remember correctly. Need to verify from the manual how long the interrupt vectors table is.

I am more concerned about being able to read addresses above 0003:0000 space... maybe worth while trying out to read some segments to which the interrupt table seems to point to ?

The EVO code looks like it was compiled from C - source. E.g. the variables are always at the end of the code segment (function/module segment) and linked to ram area. The way how the memory is built EB0, EB1, EB2 etc. means that there is a lot of unused space in between the code segments where there is no programmingcode. Perhaps also something to do with ROM->RAM mapping of SH2 ? (Used Idapro 5 with SH-4 / big endian and it dissassembled most of the code quite nicely and it was almost readable.)

In any case this is a big step now !

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Just checked the EVO Code - there is nothing exept ram (gray) and empty (black) above 0003:0000 smile.gif)). I did confuse EB11:00030000 and EB3:00003000.

Here is the idapro view to the code segments for all processor memory segments:
romram
ROM/CODE=BLUE, RAM=GRAY, EMPTY=BLACK

and here you are with a view to the memory segment addresses, this is also in hw manual.

memory segments


-- Edited by PetriK at 16:21, 2007-11-16

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Checked also the vector tables. In EVO code the first long word is a real jump address. In this the 0000:0040 or 0040:0000 really puzzles me. The first byte is supposedly program counter and second byte is stack pointer (SP i.e. @R15) to be loaded. I think that the EVO code is not really from a 7052 ?

Below the vector tables from hardware manual.  

vectors1

vectors2



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

Hi Petri, I've mailed my program to you since I don't have a site to host it & I can't figure out how to post the code here without losing the formatting etc. Please feel free to add it to your document store. Cheers, MarkW

__________________


Guru

Status: Offline
Posts: 963
Date:

Congrats on your success!!

I do think your byte order is off. I'd bet money that the data on these actually reads

00000000,00400000 = 0000:0400
00000004,0ABAFFFF = FFFF:ABA0
00000010,65C20000 = 0000:2C56

Again referring to the timing diagram up thread step 6 says read data H01234567 and the timing diagram shows the nibbles output 7 6 5 4 3 2 1 0

0400 is a good starting address. If you look at the end of the table in the previous post 0400 is the next byte after the last interrupt vector

Also the data sheet says RAM is located FFFF:8000 to FFFF:AFFF so a stack pointer of FFFF:ABA0 makes sense

 

-- Edited by RidgeRacer at 23:07, 2007-11-16

__________________


Veteran Member

Status: Offline
Posts: 80
Date:

Yes, you're absolutely right. Although my code read each nibble correctly, I place the least significant nibble where the most significant nibble should go, and so on. My bad.

On another note, any idea if there are freeware disassemblers out there? Otherwise I'll have to write a home-brew program to do the job.

__________________


Veteran Member

Status: Offline
Posts: 80
Date:

Latest developments:

(a) I rewrote my code to correctly get the nibbles in order, and it looks much better now ...
00000000,00000400, 00000004,FFFFABA0, 00000008,00000400, 0000000C,FFFFABA0, 00000010,00002C56, 00000014,00002C56, 00000018,00002C56, 0000001C,00002C56, 00000020,00002C56, 00000024,00002C56, 00000028,00002C56, 0000002C,00001360, 00000030,0000138E, 00000034,00002C56, 00000038,00002C56, 0000003C,00002C56,

(b) I added some code to send write commands to the ECU via the AUD. This had mixed results: When writing to either the ROM or to the RAM, the ECU responded with an "all OK" message (%0001) smile; but when I tried to read back from the ECU, only the bytes in RAM had changed ... the ROM bytes had not changed one bit cry

(c) I powered the ECU down, earthed its power input, and re-read the RAM. The addresses that I modified had returned to their previous values.smile

So ... there's something in there that's preventing the write to ROM from happening, even though the AUD is responding with an OK message
 confused

Perhaps once the ROM has been read via the AUD, we have to reprogram the ECU via the front door??


__________________


Guru

Status: Offline
Posts: 2338
Date:

The way I read the documentation it said that when downloading to the flash via AUD (i.e. from PC to ECU) you need to download a special program into the RAM area which takes care of writing to the flash.

There is a source code avail for the above, but I guess its really an overkill as the serial protocol and FDT provides a very good tool for flashing.

It will be interesting to see when you have the complete .bin downloaded to verify it to see if the checksum still matches.

I am still far away (days) from having the code implemented for reading the flash. Just spend quite a few hours with inttohexstr function just to be able to see the output on the LCD screen.






__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

Petrik is correct. The FLASH ROM is a very different animal than the RAM. The RAM is designed to be easily modified, thousands of times a second if need be. The FLASH on the other hand was designed to be semi permanent. Flashed once at the factory and then never again. It takes a very deliberate act to flash the ROM.

First it needs to be put in a programming mode. Second it can only program 0's so you must first Erase all the bits which sets them to 1's and then program the bits that need to be 0's And you can't erase single bytes. I believe on this CPU the smallest block you can erase is 128 bytes.

So as Petrik says you load a small loader program into RAM which you then run. While its running you watch a particular ram address which the loader will use to communicate with you, ask you for data, tell you to wait. etc.

The loader will put the CPU in program mode, erase the block, flash in the change, verify it and then ask you if you want to do another block.


On another topic you asked for a disassembler. IDApro is the only real way to go. It is an interactive disassembler. The difference between IDA and a freeware disassembler is like the difference between a bicycle and a ZX-12

If you can't find a 'free' copy of IDA on the net Private Message me and I'll point you in the right direction.

Also for the sake of future hackers who may read this later could you guys be a little more specific about what parallax hardware your using; Part number? and post any parts lists and/or schematics if you have them. Even if its just hand drawn on paper scan it or photograph it and send it to me and I'll draw up a proper schematic and post it.

Thanks

__________________


Guru

Status: Offline
Posts: 2338
Date:

The source code for writing from RAM to flash for other processors like H8 etc... can be found from Renesas homepage. It does not look complicated but does generate coplexity as the program must be first downloaded to ram if I recall correclty (otherwise timing from e.g. SIO or AUD input may be quite difficult). Anyhow FDT can be used very easily with a simple max232 circuit. That is described quite well on the busa thread on this board.

At this end the most complex part on AUD programming has been to relearn C and the SH7086 prosessor IO as a completely new animal. I think I am still adding too much complexity into the code just because of lack of experience. Anyway I think its about there and next its time to look into building the HW interface.

Here is a link to the latest in case you want to comment on it.

http://macmadigan.no-ip.com/Public/ECU/aud_pgm_draft2.txt



__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

I will post some propeller-specific diagrams as soon as I draw them up ...

Petri can you point me to the source code you're referring to for H8 writing from RAM to flash?

How do you force execution of the code that has been loaded into RAM? Is the program counter writable? ... or some other technique?

here's a pic of my propeller connection to the ECU ...



Cheers,
MarkW

__________________


Guru

Status: Offline
Posts: 2338
Date:

In your email copies for both ROM to RAM and RAM to ROM documents from Renesas.

Anyone reading this afterwards, those can be found from Renesas web site.





__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

Small progress... also at this end.

When hooking up the 74HC245 according to Renesas Specification to the AUD connector I do get output pulses in AUDDATA0,1,2,3 from sh7052.

On the other hand as the sh7086 (which is used to run the AUD flash read program) is set up to output on the AUDDATA0,1,2,3 I have a problem which can be felt as rising temperature on the sh7086 processor surface. Ouch...

More investigation is needed.






__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

Do you have a 3.3V to 5V conversion problem?

__________________


Guru

Status: Offline
Posts: 2338
Date:

Dont believe this to be related to voltage level conversions. Its a skills problem definately.

I had not connected the AUDRST which I found later from bozos code. After adding the AUDRST and fixing a bug in sw (if (AUDDATA0=0), instead of ==) I started to get timeout error 0011 when waiting for 0001

Now I get past the 0011 error, but still have a timing issue (or something). The memory byte reads are inconsistent. E.g. sometimes the 0x00000000 yields 0x00009000 sometimes 0x00009800. The software still may have some memory leaking problems, but also noticed that the output values are changing when measuring the output with a scope probe which should not affect this kind of signals. So it is possible that I have a signal level problem ??? But the original shematics from Renesas did not include any pull up or pull down resistors....

sh7086 -> 74HC245 <-> sh7052

...but at least something is happening... (even though today I already at certain moment decided to ask bozo to build one working unit and send it over smile.gif and those moments are likely to happen again)

Here is the latest software version which I am using to just browse 0x0000000, its fairly self explanatory.
http://macmadigan.no-ip.com/Public/ECU/aud_pgm_draft3.txt

And here is the schematics I am currently using as 74HC245 interface:

aud interface

-- Edited by PetriK at 18:50, 2007-11-21

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

I looked at your code and I think your missing a clockpulse() in your GetAUDData() function. If you look at the timing diagram...

AUD_signalling_read_timing.JPG

After you set AUDSYNC the next clock cycle is the sync (dummy?) cycle. The CPU doesn't start  returning valid data till the second cycle after AUDSYNC is set. In your GetAUDData() you set AUDSYNC and then start reading in the 8 nibbles. I think you need to add a clockpulse() between setting AUDSYNC and your nibble loop.

Also I am curious why you have the asymetrical wait timing in the clockpulse routine. You have it low 255 times longer than you have it hi. I understand that before/after clockpulse() while the AUDCK is idle hi is when your other code is running, setting the bits etc. and that is kind of an implied hi wait, but still 255/1 still seems kind of excessive. Have you looked at it on a scope? Is it close to a 50% duty cycle with those values?


__________________


Guru

Status: Offline
Posts: 963
Date:

Also there seems to be a discrepancy between your schematic and your software. I don't know if its just a documentation error or ????

The schematic list

auddata3 = PD11
auddata2 = PD10
auddata1 = PD9
auddata0 = PD8

The software lists

#define AUDDATA0 PD.DR.BIT.B8
#define AUDDATA1 PD.DR.BIT.B10
#define AUDDATA2 PD.DR.BIT.B12
#define AUDDATA3 PD.DR.BIT.B14

Am I missing something here?

__________________


Veteran Member

Status: Offline
Posts: 80
Date:

This is a rough schematic for my connection between a Parallax Propeller Proto-board and the ECU.

The proto-board contains everything needed (power supply, crystal, ...), a parallax plug simply connects to it for USB comms to my laptop.

Propeller Proto Board



I've had to place series resistors on the AUDATA lines to limit the current into the 3.3v propeller ports.

Also, since the propeller can't send 5v down the reset line, I've tied the line high with a resistor.

To send 1 or 0 on the AUDRST line, I preset the output of PortA/bit7 to zero,
then I simply toggle the direction bit associated with portA/bit7.

When it's an output, the AUDRST line is driven low.
When it's an input, the pin is highZ and the line is pulled high by the pullup resistor.

Is there any way to post formatted text (i.e. my source code) here? Each time I try all the indents are lost.

EDIT: actually I didn't connect pin 6 to the AUDMD pad ... since if it is left unconnected, it is pulled high internally, which is great, since that's what's needed for setting RAM Monitor Mode (and it saves me the expense of another 1k resistor biggrin)

-- Edited by bozo at 03:01, 2007-11-22

__________________


Guru

Status: Offline
Posts: 963
Date:

You can't beat the Propeller for price. Even with the accessory kit its still under $40. I should figure out a way to use those instead of the $200 BDM interface for the older 16 bit ECUs.

As for the formatted text unfortunately your out of luck. Even if you convert the text to html and post it in the advanced editor as an html block the board still removes the excess white space chars.

You'll have to host it somewhere and then post a link. If you can't host send it to me and I'll host it

__________________


Guru

Status: Offline
Posts: 2338
Date:

Thanks for RR about the feedback and schematic from bozo.. fixed the inAUDDATA reading order so error messages make more sense now. Also installed SIO subroutines.

Now after installing the SIO subroutines I again get 0011 timeout when waiting for 0001 ready bits before setting up AUDSYNC high to read the AUDDATA.

According to the manual that is an indication that the 7052 is not in RAM mode: "When AUDSYNC is high: When waiting for branch destination address output, AUDDATA pins constantly output 0011."

So either the 10k is not enough to pull the AUDRST high or that I have the AUDRST signalling incorrect. I vaguely recall the AUDRST signal voltage showing on scope screen lower than other signals. Looked at the propeller schematic and noticed that bozo use 1k, where as I use 10k as that was the value in the schematics from Renesas. If that is the case maybe I need to verify that the port used for AUDRST is a high current port.

Yes - I am also very tempted with the propeller kit...  What are the sw tools that is used with that (i.e. programming environment and programming language ?).


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Veteran Member

Status: Offline
Posts: 80
Date:

PetriK wrote:

Yes - I am also very tempted with the propeller kit... What are the sw tools that is used with that (i.e. programming environment and programming language ?).




Sorry if this is a bit off-topic. I am by no means a salesman for parallax. When I first bought a propeller demo board I was able to download some routines from the propeller library (object exchange), 'compile' them and run them on my chip within minutes. Since then I've been converted.

The chips are cheap and powerful. Want to talk USB back to a PC? - add in the serial comms object. Want to drive a feed into a TV? - add in the TV object. Yes, that's right ... the chip is so fast it will generate RF and you can use a TV as a monitor ... I'm using a small colour LCD 2.5" TV on one project at the moment.

The only downside is limited debugging capability (because there are 8 processors), but this has not proven to be as big a problem as it might seem. Just embed code to send params to the TV or up the USB to a hyperterminal window as the program runs in-cct. There is another downside in that the IDE won't run under OS X, but that doesn't bother me since I installed bootcamp and windoze on my macbook.

It can be programmed either in SPIN (language developed specifically for the prop.) or assembly, or both. SPIN is easy to learn, difficult to master.

I can get something up and running on the prop. in a fraction of the time it used to take me with a PIC. The development environment is free. The manuals are free. All objects in the object exchange are free. And I love stuff that's free. Especially if it's useful.

Check out the users forum ...

propeller forum

__________________


Guru

Status: Offline
Posts: 2338
Date:

Had a problem with the audrst signal. Found out with measuring the voltages from the 7052 AUD connector that it was below the voltage from other pins. Even though I had checked the board with a stereo magnifying glasses before hooking to the ECU I could not see it.

The rest is self explanatory:

Renesas RSKSH7086 based AUD read program
00000000,00000000,00000400
00000001,00000004,FFFFAFAF
00000002,00000008,00000400
00000003,0000000C,FFFFAFAF
00000004,00000010,00022B20
00000005,00000014,00022B20
00000006,00000018,00022B20
00000007,0000001C,00022B20
00000008,00000020,00022B20
00000009,00000024,00022B20
0000000A,00000028,00022B20
0000000B,0000002C,00066210
0000000C,00000030,00099210
0000000D,00000034,00022B20
0000000E,00000038,00022B20
0000000F,0000003C,00022B20

Here is the link to the software that was used:
http://macmadigan.no-ip.com/Public/ECU/aud_pgm_working1.txt

Regarding interface I removed the AUDRST 10K resistor, there is no need for that with RSK7086. Have updated the schematics below accordingly:
AUD_interface.JPG


ps. Without being experienced with C can you hint if there is a more educated way of putting the lsb and msb in righ order than building the lsb and msb in separate loops ?




-- Edited by PetriK at 18:14, 2007-11-22

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

Something about your results don't look correct. Maybe that is what you meant by self explanatory?

What are the odds that the interrupt address would all have matching digits and end in 0?

22B20
66210
99210

Also the valid addresses for ROM are 0000:0000 - 0003:FFFF 66210 and 99210 are out of bounds

As for an algorithm to get the data;

If the data being sent is 0x01234567 the nibbles will be sent as

7
6
5
4
3
2
1
0

If you look at the desired result it is actually the sum of

7 x 1
6 x 16
5 x 256
4 x 4096
3 x 65536
2 x 1048576
1 x 16777216
0 x 268435456

OR put another way the sum of

7 x (16^0)
6 x (16^1)
5 x (16^2)
4 x (16^3)
3 x (16^4)
2 x (16^5)
1 x (16^6)
0 x (16^7)

(^ means exponential as in 16^4 = 16 x 16 x 16 x 16)

An example routine using this idea would be

unsigned int result = 0;
char nibble = 0;
char n = 0;

for(n=0,n<8,n++)
{
clockpulse();
nibble += ((inAUDDATA3<<3));
nibble += ((inAUDDATA2<<2));
nibble += ((inAUDDATA1<<1));
nibble += ((inAUDDATA0<<0));

result += nibble * (16^n);

}

Also there should only be one clockpulse() after you set the AUDSYNC hi. Not one before and after.


 

-- Edited by RidgeRacer at 14:25, 2007-11-23

__________________


Guru

Status: Offline
Posts: 2338
Date:

Thanks, had completely forgotten the 16^n. Been too long doing only administration.

Yes, You are absolutely right - not all the figures there make much sense, but on the positive side the first and third are the same and the second and fourth are the same (particularly bearing in mind that the 2nd and 4th should be FFFFxxxx addresses). So getting there...

The timing is not at all critical as I have learnt. But the internal type conversions are very critical.

After inputting your function there I get very confusing results (in a process to move this to an s record format, but 8 last bytes are the important ones.)

S3040000000000000048
S3040000000400000780
S3040000000800000048
S3040000000C00000780
S304000000100000010E
S304000000140000010E
S304000000180000010E
S3040000001C0000010E
S304000000200000010E
S304000000240000010E
S304000000280000010E
S3040000002C0000011D
S3040000003000000130
S304000000340000010E
S304000000380000010E
S3040000003C0000010E
S50800000010


Looks like I am missing something in the type conversions...
//read out longword (8) 4bit nibbles of data requested
result=0;
for(counter=0;counter<8;counter++)
{
 nibble  = inAUDDATA3<<3;
 nibble += inAUDDATA2<<2;
 nibble += inAUDDATA1<<1;
 nibble += inAUDDATA0<<0;
 result += (nibble * (16^counter));
 clockpulse();
}

-- Edited by PetriK at 06:05, 2007-11-23

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

After sleeping few hours come to think about the hw interface again... as I remembered that there is a voltage difference between the two regulated Vcc:s.
- The 74HC245 is connected to the ECU +5.05V Vcc
- The RSK7086 has a separate +5V PSU running 5.19V
... and sometimes I do get -0.xxV difference on the data line voltage.

Then also noticed that the 74HC245 interface turns on the power indicator led when any of the AUDDATA lines is high. Then found this schematic which shows that there is a diode between input and Vcc:

74HC245 internal

Now started to think that some current limiting resistors to the non 74HC245 side of the interface are needed even though those are not originally part of the schematics from Renesas ?

While writing this also remembered words from a local hacker who has built the 74hc245 interface to his PIC processor (to hook up to his sh7052 based kawi ecu) wrote a couple of days ago that he had also problems with the interface until he put 3.3k pull down resistors to the interface on the PIC side.

AUD interface

-- Edited by PetriK at 08:08, 2007-11-23

-- Edited by PetriK at 09:26, 2007-11-23

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

OK - stabilized the interface with 10k pulldown resistors for sh7086 end and with a cap between Vss and Vcc to overcome the voltage fluctuations. Now the readings are constant. (Tested the interface without having it connected the ecu and noticed that got some inconcistent readings now and then even though everything should have read 0x00000000.)

Also took some time to understand (for me who has not used C for 20 yeards) that ^ is XOR not power of...

This is the output now, starting to look what it should look (if you read from left to right)....

S3040000000000400000
S304000000040AFAFFFF
S3040000000800400000
S3040000000C0AFAFFFF
S3040000001002B20000
S3040000001402B20000
S3040000001802B20000
S3040000001C02B20000
S3040000002002B20000
S3040000002402B20000
S3040000002802B20000
S3040000002C86210000
S3040000003069210000
S3040000003402B20000
S3040000003802B20000
S3040000003C02B20000
S50800000010

So its time to reverse the result from this function:

result=0;
for(counter=0;counter<8;counter++)
{
 result*=16;;
 nibble  = AUDDATA3<<3;
 nibble += AUDDATA2<<2;
 nibble += AUDDATA1<<1;
 nibble += AUDDATA0<<0;
 clockpulse();
 result +=nibble;
}

-- Edited by PetriK at 12:41, 2007-11-23

__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 2338
Date:

...and why does one often get the "englightement" just a minute after posting the "question" ....

S3040000000000000400
S30400000004FFFFAFA0
S3040000000800000400
S3040000000CFFFFAFA0
S3040000001000002B20
S3040000001400002B20
S3040000001800002B20
S3040000001C00002B20
S3040000002000002B20
S3040000002400002B20
S3040000002800002B20
S3040000002C00001268
S3040000003000001296
S3040000003400002B20
S3040000003800002B20
S3040000003C00002B20
S50800000010

result=0;
for(counter=0;counter<8;counter++)
{
 nibble  = inAUDDATA3<<3;
 nibble += inAUDDATA2<<2;
 nibble += inAUDDATA1<<1;
 nibble += inAUDDATA0<<0;
 result += (nibble<<(counter*4));
 clockpulse();
}

I am still slightly worried about the records 0x2C and 0x30 but at least those now point to the Flash area.

Here is the start of the RAM area:
S304FFFF000063408106
S304FFFF00042BE0B010
S304FFFF00088B010000
S304FFFF000C32338901
S304FFFF00100009B0E2
S304FFFF00140009E214
S304FFFF00182410000B
S304FFFF001C2410000B
S304FFFF002063402338
S304FFFF002400099068
S304FFFF00280009B04C
S304FFFF002C63408105
S304FFFF0030323309CD
S304FFFF003489030000
S304FFFF00388903E100
S304FFFF003C23201B36
S50800000010


__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom



Guru

Status: Offline
Posts: 963
Date:

PetriK wrote:


Also took some time to understand (for me who has not used C for 20 yeards) that ^ is XOR not power of...





OK, I feel like an idiot. They say the mind is the first thing to go :ashamed
I don't know why I suddenly thought you were coding in Excel or BASIC. Hope my leading you off in the wrong direction didn't waste too much of your time. It looks like you figured it out...

result += (nibble<<(counter*4));

That is a clever way to do the same thing.

Serves me right for trying to sneak in some posts on the livingroom laptop when I was supposed to be playing host to my Thanksgiving holiday guests and family.

Anyway your output looks good now.




 



__________________


Guru

Status: Offline
Posts: 2338
Date:

RR, your support on this project is worth of gold or titanium if that is more valuable. Thinking hard is what keeps the mind going...

Thanksgiving... had forgotten that. We used to have it too when we lived in UK. It is really a nice custom to sit down with family.

The S-record generator is now ready, the test files can be read into FDT. I think that I am soon ready to give a proceed for reading the full contents as soon as I find a proper way to log the file from a terminal window. The software would not be at this level without your initial concept and confidence gained from bozos messages about this stuff working.




__________________

When asking a question, you can also consider posting it to facebook:

http://www.facebook.com/ecueditorcom

1 2 3 4  >  Last»  | Page of 4  sorted by
 
Quick Reply

Please log in to post quick replies.

Tweet this page Post to Digg Post to Del.icio.us


Create your own FREE Forum
Report Abuse
Powered by ActiveBoard