Another Mode 3 Question

[toliphint]

With the much appreciated help here, Mode 3 is working perfectly, albeit not as fast as would like but can live with it. But just when I think I understand things, another curve.
'7730, $8d, TPro RT v5 - Is it possible to make a Mode 3 request to read a memory mapped i/o address (eg. 1-byte 0x4008); and if so, how would it be entered in the transmit string? "0x40 0x08" does not work because replacing a working address with the above yields no data. This appears to be a CPU status register so it has data.

Is a different format required for addresses between 0x3000 and 0x6FFF or do I just forget it as not doable? Thanks!

[robertisaar]

most registers read just fine in my experience....

4008, that is the SCI error/status flag register, IIRC.... i would expect that to read as 0 at all times unless some kind of comm issue is happening.

[toliphint]

most registers read just fine in my experience....

4008, that is the SCI error/status flag register, IIRC.... i would expect that to read as 0 at all times unless some kind of comm issue is happening.

You're correct -- it's the Transmit/Receive Status Register as shown below.

Code: Select all

L4008 = 0x4008  ;CPU TX/RX STATUS REG,(8192 BAUD SCI)
;---------------------------------------------------
; b7, [1 = Transmit Register NOT Empty – Go Transmit via SR at LEB9B]
; b6, [1 = Transmit DONE]
; b5, [1 = Receive Register is FULL – Get data via SR at LEA25]
; b4, [May be set bu the ECM, but not used in the code]
; b3, [1 = per Usage = Some type of SCI Read/Write Error]
; b2, [1 = per Usage = Some type of SCI Read/Write Error]
; b1, [1 = per Usage = Some type of SCI Read/Write Error]
; b0, [1 = COUNTER Interrupt Set = Execute 6.25ms ISR from the Hardware Interrupt Handler

And, I'm with you that it should not be an issue to read it, but it is. Here's why. With a working Mode 3 request where the first address in the request string is replaced with 0x4008, there is no data received for any of the requested addresses. For example:

• This provides data----: 0xF4 0x5C 0x03 0x00 0xA2 0x00 0x45 0x00 0xA4
  This provides NO Data: 0xF4 0x5C 0x03 0x40 0x08 0x00 0x45 0x00 0xA4

And that's no data for any of the addresses!

Something ain't right! Have created numerous Mode 3 requests with 0x4008 (and even 0x4007) and all the same -- no data.

All ideas appreciated. Is this a TPro bug? Likely not -- just searching for answers.

[dex]

I suspect the problem is that any address in the 0x4xxx range is getting treated as a call for a word of data (for example in the $74 code any data between the addresses 0x3000 and 0x6FFF is treated as a 16 bit data request).

So instead of the SCI status register the ecu is giving you whatever data is at 0x0008 (and probably also 0x0009 instead of the next address you requested at 0x0045 ).

[robertisaar]

you know, that is a distinct possibility.... in which case, you would need to buffer teh register to a RAM byte, then transmit that. good thing 8D has a LOT of free RAM before the stack, IIRC.

[toliphint]

I suspect the problem is that any address in the 0x4xxx range is getting treated as a call for a word of data (for example in the $74 code any data between the addresses 0x3000 and 0x6FFF is treated as a 16 bit data request).

So instead of the SCI status register the ecu is giving you whatever data is at 0x0008 (and probably also 0x0009 instead of the next address you requested at 0x0045 ).

you know, that is a distinct possibility.... in which case, you would need to buffer teh register to a RAM byte, then transmit that. good thing 8D has a LOT of free RAM before the stack, IIRC.

Thanks guys. Couple of things:
1. Once 0x4008 is entered into the transmit stream, no data at all comes back. I mean it's like DA is NOT Connected. That seems strange and indicative of something being in a state that TPro does not like. Otherwise, would just get erroneous data as suggested. But that's not happening.
2. If true regarding 0x3000 to 0x6FFF, is the 0x4008 byte retrievable without recompiling? If so, how would I do that?

[dex]

How is the request checksum being handled? I ask because it's not shown in the examples you give.

[toliphint]

How is the request checksum being handled? I ask because it's not shown in the examples you give.

Checksum is 2's complement computed by TPro. I also tried placing it at the end of the xmit string and selecting None for Checksum -- both fail.

But you may be right in that 0x0008 is being reported because that is an error word that appears to not be used in $8d on the '773o. All that's being reported is 0 -- which would occur given no errors or not used.

So assuming 0x0008 is being reported for 0x4008, what can I do to get data from 0x4008? Someone was obviously smart enough to map addresses for Mode 1 data where 2-byte requests are made, like:
.word 0x30E4 ; 45. INJECTOR PULSE WIDTH (MSB),
.word 0x30E5 ; 46. INJECTOR PULSE WIDTH (LSB),

But then again 0x4008 is only 1 byte, not 2.

I'm really confused. Surely there's a solution to this without writing code and recompiling -- not something I want to do right now.

Help please!

[dex]

I have briefly looked at the $8D ANHT code and it is the same as the $74 code with any data between the addresses 0x3000 and 0x6FFF being treated as a 16 bit data request. You could therefore alter the byte at 0xEC1A (0xEC22 for the $8D AUJP) from 0x6F to 0x3F to limit word sized data requests to 0x3000 to 0x3FFF.

A note of caution though, this code modification will affect any one that uses the address range 0x4000 to 0x6FFF for a 16 bit data request and prevent that request.

[toliphint]

I have briefly looked at the $8D ANHT code and it is the same as the $74 code with any data between the addresses 0x3000 and 0x6FFF being treated as a 16 bit data request. You could therefore alter the byte at 0xEC1A (0xEC22 for the $8D AUJP) from 0x6F to 0x3F to limit word sized data requests to 0x3000 to 0x3FFF.

A note of caution though, this code modification will affect any one that uses the address range 0x4000 to 0x6FFF for a 16 bit data request and prevent that request.

Understand changing the byte from 6F to 3F (appears to be 0x6C22 in hex editor while 0xEC22 in the .LST file -- is that the same address?). And regarding the caution: Given the change is in the transmit interrupt handler and will only be temporary while doing the Mode 3 request for 0x4008, would it be correct that while the 6F/3F change is in effect, everything will function as before as long as I do not make a request to transmit 16 bit data above 0x3FFF?
Long question but just want to make sure nothing else will change to alter code functionality while requesting 0x4008.

[dex]

appears to be 0x6C22 in hex editor while 0xEC22 in the .LST file -- is that the same address?

Yes, if you are using a 32k bin file.

Given the change is in the transmit interrupt handler and will only be temporary while doing the Mode 3 request for 0x4008, would it be correct that while the 6F/3F change is in effect, everything will function as before as long as I do not make a request to transmit 16 bit data above 0x3FFF?

I do not understand what you mean by 'temporary'. If you change the 0x6F to 0x3F and something makes a request for 16 bit data using the address range 0x4000 to 0x6FFF then it will be treated as a request for 8 bit data.

[toliphint]

do not understand what you mean by 'temporary'. If you change the 0x6F to 0x3F and something makes a request for 16 bit data using the address range 0x4000 to 0x6FFF then it will be treated as a request for 8 bit data.

Sorry if I wasn't clear. I plan to change the byte and run a short Mode 3 test to request 0x4008 only -- nothing else. Then the byte will changed back after 0x4008 is logged and will return to normal Mode 1. So just double checking to ensure that if nothing else is requested the code will act exactly as before the change. I seem to recall that the 7730/$8d does not make any transmissions that are not requested. Maybe I'm making this more complicated that it is. Just don't want the Mode 3 data to be screwed up because of something not anticipated or understood.

[dex]

If you change the 0x6F to 0x3F and something makes a request for 16 bit data using the address range 0x4000 to 0x6FFF then it will be treated as a request for 8 bit data. I cannot say if this will or will not happen as I am not familiar with the $8D ecu and do not know what communications will be possibly going on.

[toliphint]

Well thanks for the help but nothing solved. Just can't believe this can be that complicated. Here are the consistent logged results:

Send: F4 5C 03 40 08 00 58 00 95 78
(78=C/Sum)
With 6F changed to 3F at 0x6C22:
L4008 = 0 ([EDITED from L0048 to L4008]
RPM (L0058) and TPS% (L0095) reported OK
Here, 0x4008 cannot be being reported because it contains xmit and receive statue bits.

With 6F unchanged:
L0048 = 0
RPM (L0058) = 3200
TPS% (L0095) = 0
Here, it's as if TPro is confused and does not know what to do. Values do not change.

Appreciate all the help, but will try another site where I can post up the adx file and see if someone can make sense of this.

[dex]

I am guessing you mean L4008 not L0048.

You may not be seeing any data because I have a feeling that when the SCSR register is read the bits are cleared. This is because in the $74 code I can see where the register is read but nothing is done with the data which is kind of typical for clearing a register.

[toliphint]

I am guessing you mean L4008 not L0048.

You may not be seeing any data because I have a feeling that when the SCSR register is read the bits are cleared. This is because in the $74 code I can see where the register is read but nothing is done with the data which is kind of typical for clearing a register.

Yea, meant L4008, not L0048. Fat fingers, but now edited and corrected. Understand the possibility of clearing xmit/receive registers, but still don't understand why when 4008 is placed in the Mode 3 transmit string, RPM and TPS% are NOT reported correctly (see test with 6F). That seems to say that TPro is confused and doesn't know what to do even though it's sampling data because can see the sampling rate in Hz in the window to the left of DA connected. I'll keep plugging away trying different things. Thanks!

[dex]

When changing the 0x6F to 0x3F are you updating the bin checksum or setting the engineering mode checksum bypass?

[toliphint]

When changing the 0x6F to 0x3F are you updating the bin checksum or setting the engineering mode checksum bypass?

Dang, chip code mask at 0x8008 is 8D instaed of AA. Will that make a difference? If so would be interested in knowing details. Thanks!

[toliphint]

Finally!!! It works with 3F and AA. Not sure I believe the 4008 data yet, but at least it's functioning.

Decided to dive into the transmit handler 0x3000-0x6FFF code and discovered 0x4008 will never work with 6F. Will always be reading 0x0008 data as you previously stated. This is because the address of the data to be transmitted is subjected to an 'anda 0x01', and then 2 bytes from the 'anded' address are placed into Accum D. That means the addresses provided for a 2-byte xmit in the 3000-6fff range MUST be either 0x00yy or 0x01yy, which are the ONLY allowable MSB addresses for the requested data. Anything else will point to an invalid address (eg - 43yy will be 'anded' to 0 -- oops!). And address MSB of 00 or 01 is exactly what's seen in the Mode 1 DDS.

For example, in the DDS:
.word 0x30E4 ; 45. INJECTOR PULSE WIDTH (MSB),
.word 0x30E5 ; 46. INJECTOR PULSE WIDTH (LSB),

And then the actual variable declaration, which is 0x30E4 – 0x3000 = 0x00E4:
L00E4 = 0x00E4 ; BPW

Now wondering why did not get a code or Limp mode with 8D with an invalid checksum. Any ideas?

Thanks again!

[dex]

I do not know the code well enough so I am afraid I have no idea why an invalid checksum in the $8D did not throw a code or go into limp home mode. Hopefully some one else may know and will chime in.