3_7 funcard fix here

[slick]

Hi all,
This might sound silly. After reading about what everyone has said, To those who contributed to this thread, Be it a negative or positive response, its been very interesting.
I too would like to try and program. I have a card,umm looks like Rom 10. My first question is "can i use the cas 3 plus" to emulate the hardware required to begin programing.? I Also have a book on numbering systems,computer architecture,with assembly language.To add to this a guide to Avr Development, Avr studio 4 is there anything else i require
to Help me get started.

[TheCoder]

Originally Posted by PaddyBhoy

the card does respond though

21 is the request from the box,
12 is the reponse from the card

As Tesla and TheCoder have mentioned we have to look at how the card deals with the requests that others that are not effected do different,something has changed but it's not the IFS because the card responds.Something in the source is putting the card out of sync

But you already know the problem isn't the actual IFS but something before the IFS. The IFS is simply a result of the box resetting the CAM slot (and thus the card). From whats been said earlier you also know that after a reset (before the IFS) the card sends out its ATR at a much lower baud rate which the logger doesn't see.

The problem with the logger is that its not a particularly good tool for logging error conditions as its internal programming filters out things that dont make sense. All you see is good communications packets.

So, all you can infer from the present log is that there are repeated IFS attempts which likely means that the card is being reset prior to those IFS attempts. Any problem is obviously occuring before the reset and thus before the IFS attempts.

[G77]

is it a change in baud rate?

ie, the box wants a baud rate from the card which is different from what its set to send at?

[TheCoder]

Originally Posted by timetrex

but if the card has been programmed to respond at a certain rate,
the box is waiting for a response doesnt get one effectively a timeout of some sort and rensends another/same command.

aha, your starting to get warmer !

Not there yet but definately moving in the right direction. Forget the individual commands and look at the basic data transmission system !

[PaddyBhoy]

Originally Posted by timetrex

By the face of things the card does respond but it aint responding with the right info.

Been looking at the hex files and as the coder suggested the rst as well since its working.

THe rst hex file seems a lot cleaner than the last fixes...

+00000000: C007 RJMP PC+0x0008 Relative jump
+00000001: 9518 RETI Interrupt return
+00000002: 9518 RETI Interrupt return
+00000003: FFFF ??? Data or unknown opcode
+00000004: FFFF ??? Data or unknown opcode
+00000005: FFFF ??? Data or unknown opcode
+00000006: FFFF ??? Data or unknown opcode
+00000007: C0D8 RJMP PC+0x00D9 Relative jump
+00000008: 9A47 SBI 0x08,7 Set bit in I/O register
+00000009: 94F8 CLI Global Interrupt Disable
+0000000A: 2700 CLR R16 Clear Register
+0000000B: BF0B OUT 0x3B,R16 Out to I/O location
+0000000C: BF09 OUT 0x39,R16 Out to I/O location
+0000000D: BF05 OUT 0x35,R16 Out to I/O location
+0000000E: B90D OUT 0x0D,R16 Out to I/O location
+0000000F: BB05 OUT 0x15,R16 Out to I/O location
+00000010: BF0E OUT 0x3E,R16 Out to I/O location
+00000011: BB01 OUT 0x11,R16 Out to I/O location

where as compared to this

00000000: C010 RJMP PC+0x0011 Relative jump
+00000001: 9518 RETI Interrupt return
+00000002: 9518 RETI Interrupt return
+00000003: FFFF ??? Data or unknown opcode
+00000004: FFFF ??? Data or unknown opcode
+00000005: FFFF ??? Data or unknown opcode
+00000006: FFFF ??? Data or unknown opcode
+00000007: 930F PUSH R16 Push register on stack
+00000008: 9BB6 SBIS 0x16,6 Skip if bit in I/O register set
+00000009: C004 RJMP PC+0x0005 Relative jump
+0000000A: EE0F LDI R16,0xEF Load immediate
+0000000B: BF02 OUT 0x32,R16 Out to I/O location
+0000000C: 910F POP R16 Pop register from stack
+0000000D: 9518 RETI Interrupt return
+0000000E: E000 LDI R16,0x00 Load immediate
+0000000F: BF03 OUT 0x33,R16 Out to I/O location
+00000010: C07A RJMP PC+0x007B Relative jump
+00000011: 9A47 SBI 0x08,7 Set bit in I/O register
+00000012: 2700 CLR R16 Clear Register
+00000013: BF0B OUT 0x3B,R16 Out to I/O location
+00000014: BF05 OUT 0x35,R16 Out to I/O location
+00000015: E000 LDI R16,0x00 Load immediate
+00000016: BF09 OUT 0x39,R16 Out to I/O location
+00000017: 9AC2 SBI 0x18,2 Set bit in I/O register
+00000018: 9ABA SBI 0x17,2 Set bit in I/O register
+00000019: E0D0 LDI R29,0x00 Load immediate
+0000001A: E6C0 LDI R28,0x60 Load immediate

spot the difference?

i do the second hex seems to want to run a hell of a lot more code to get to the same place as the first

[PaddyBhoy]

Originally Posted by TheCoder

But you already know the problem isn't the actual IFS but something before the IFS. The IFS is simply a result of the box resetting the CAM slot (and thus the card). From whats been said earlier you also know that after a reset (before the IFS) the card sends out its ATR at a much lower baud rate which the logger doesn't see.

The problem with the logger is that its not a particularly good tool for logging error conditions as its internal programming filters out things that dont make sense. All you see is good communications packets.

So, all you can infer from the present log is that there are repeated IFS attempts which likely means that the card is being reset prior to those IFS attempts. Any problem is obviously occuring before the reset and thus before the IFS attempts.

ah i was under the assumtion that the IFS request was the first thing in the chain, time to rethink my thoery.Thanks for taking the time to explain this as i would have been chasing shadows.As i've said before please forgive anything thats sounds complete ****e as i only picked this up last night

[TheCoder]

Quick lesson in how single wire I/O operates at the physical (electrical level)

Both box and card contain both a serial transmitter and receiver device connected to the same physical wire.

Now, oviously, there is a conflict here because if both box and card start to transmit at the same time then you have the possibility of an electrical "short" circuit (when one device is transmitting logic 1 whilst the other is, at the same time, transmitting a logic 0).

To remove the possibility of this electrical conflict both devices use whats called an open-collector I/O port. This means the port is capable only of driving to a logic 0 state. When the I/O tries to drive to a logic 1 state there is no output. In order for there to be any logic 1 on the wire a system called passive logic high is used. This basically means that a fairly high value resistor is connected from the I/O wire to a voltage supply so that when no device is driving the line it "floats" to a logic 1 condition.

So, now you have a system where either the box or the card can drag the I/O line to logic 0 only. If either device outputs a logic 0 then the line will be at logic 0. If neither device outputs a logic 0 then the line will passively rise to the loogic 1 level. Thus no possibility of an electrical "short" !

ok, thats the basic electrical protocol sorted.

Now, on top of that you effectively have a master/slave software protocol where the stb is the master device and the card is the slave. The card can only output data when asked to do so by the master (the ATR is a special form of request that involve another I/O line called the reset pin).

So, now you have -
Box request (21 type packet)
Card reply (12 type packet)

The card cannot ever reply until its queried !

To keep things ticking along, both box and card will expect things to occur within certain timing tolerances. For instance the box will wait for a predefined period after sending a query before assuming the card isn't going to reply (timeout). The box will also wait for another predfined timeout after seeing a response before sending another query. There are quite a few different combinations of timeout for various conditions. Most of these timeouts are handled by the box. The card really doesn't worry about them too much - it just has to respond within the correct timeframe.

ps. This is just a background in the low level operation of the protocol. Its not meant to indicate where the fault lies but it may help you to understand the functioning of the funcard program !!!

[timetrex]

Looking at both those hexes and thinking about how data is communicated it seems that when the bit is in the register and set, it is quicky outputed all at once/packets, where as the other one isnt....

might go and play some xbox now cause I need just ot have some time to think abot this and hopefully it will just pop into my head while playing about.

[TheCoder]

Question : How does the funcard actually aquire the serial data and turn it into data packets it can interpret ?

[PaddyBhoy]

Originally Posted by TheCoder

Quick lesson in how single wire I/O operates at the physical (electrical level)

Both box and card contain both a serial transmitter and receiver device connected to the same physical wire.

Now, oviously, there is a conflict here because if both box and card start to transmit at the same time then you have the possibility of an electrical "short" circuit (when one device is transmitting logic 1 whilst the other is, at the same time, transmitting a logic 0).

To remove the possibility of this electrical conflict both devices use whats called an open-collector I/O port. This means the port is capable only of driving to a logic 0 state. When the I/O tries to drive to a logic 1 state there is no output. In order for there to be any logic 1 on the wire a system called passive logic high is used. This basically means that a fairly high value resistor is connected from the I/O wire to a voltage supply so that when no device is driving the line it "floats" to a logic 1 condition.

So, now you have a system where either the box or the card can drag the I/O line to logic 0 only. If either device outputs a logic 0 then the line will be at logic 0. If neither device outputs a logic 0 then the line will passively rise to the loogic 1 level. Thus no possibility of an electrical "short" !

ok, thats the basic electrical protocol sorted.

Now, on top of that you effectively have a master/slave software protocol where the stb is the master device and the card is the slave. The card can only output data when asked to do so by the master (the ATR is a special form of request that involve another I/O line called the reset pin).

So, now you have -
Box request (21 type packet)
Card reply (12 type packet)

The card cannot ever reply until its queried !

To keep things ticking along, both box and card will expect things to occur within certain timing tolerances. For instance the box will wait for a predefined period after sending a query before assuming the card isn't going to reply (timeout). The box will also wait for another predfined timeout after seeing a response before sending another query. There are quite a few different combinations of timeout for various conditions. Most of these timeouts are handled by the box. The card really doesn't worry about them too much - it just has to respond within the correct timeframe.

ps. This is just a background in the low level operation of the protocol. Its not meant to indicate where the fault lies but it may help you to understand the functioning of the funcard program !!!

things are starting to become clearer, although it could well be down to the stella.I will jump on this tomorrow once i have a clear head. Thank you TheCoder and tesla your help has been valuable in helping me understand this