Xgate CPU and memory

Hello,

I would like to understand how the access ram works. For example, the Xgate write the variable test (test=0x50). At the same time the CPU read the variable test (if test==0x40 .)

What happens? Could this operation take place?

Thank you for help

Regards Start a New Thread

--- In 6..., "Pascal" wrote:
> I would like to understand how the access ram works. For example,
> the Xgate write the variable test (test=0x50). At the same time the
> CPU read the variable test (if test==0x40 .)
> What happens? Could this operation take place?

Good Q. AFAIK, they cannot access at *exactly* the same time because
they use have a time share of the bus. I think they function out of
sync so that one part of the bus cycle is for XGate, and another part
for S12X access. Start a New Thread

The accesses are serialized and therefore any order may happen. So the
XGATE may read the old value, the new one, or if HC12 needs several
accesses to update the variable (read modify write accesses, longs,
several variables) anything in between too.
The HC12 access to the RAM actually has a higher priority than the
XGATE, the XGATE will wait one additional cycle.

Note that there are special synchronization semaphores supported to
protect concurrent accesses like this, the XGATE has special assembly
instructions for it and the HC12 accesses those semaphores via memory
mapped registers.
Anyway, concurrent access problems are not new with the XGATE, they can
happen with interrupts on the HC12 on its own, especially as the HCS12X
has multiple interrupt levels.

Daniel

Jefferson Smith wrote:
> --- In 6..., "Pascal" wrote:
>
>> I would like to understand how the access ram works. For example,
>> the Xgate write the variable test (test=0x50). At the same time the
>> CPU read the variable test (if test==0x40 .)
>> What happens? Could this operation take place?
>>
>
> Good Q. AFAIK, they cannot access at *exactly* the same time because
> they use have a time share of the bus. I think they function out of
> sync so that one part of the bus cycle is for XGate, and another part
> for S12X access.
>
> Yahoo! Groups Links
> Start a New Thread

--- In 6..., Daniel Friederich wrote:
>
> The accesses are serialized and therefore any order may happen.

Thanks Daniel, could you refer us to a good document on the
fundamentals of the bus sharing? Start a New Thread

Did you check the data sheet for your device?
(for a XDP512, for example
http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S12XDP512V2.pdf)

The chapter "17.4.4 Chip Bus Control" lists the priorities the different
bus masters have.
Not sure if it is what you look out for.

Daniel

Jefferson Smith wrote:
> --- In 6..., Daniel Friederich wrote:
>
>> The accesses are serialized and therefore any order may happen.
>>
>
> Thanks Daniel, could you refer us to a good document on the
> fundamentals of the bus sharing?
>
> Start a New Thread

Hello.

I have a question. I've been trying to connect an sd card to a hcs12x MCU.
The card does initialize , but i can not get a data token when i try to
read. Does anyone have any ideas how to solve this? (the card worked fine on
another MCU).

Thanks,

Victor Start a New Thread

When you say it initialized, have you read the CID or CSD, and it fails reading
a sector?
P

Victor Adrian Prisacariu wrote:
> Hello.
>
> I have a question. I've been trying to connect an sd card to a hcs12x MCU.
> The card does initialize , but i can not get a data token when i try to
> read. Does anyone have any ideas how to solve this? (the card worked fine on
> another MCU).
>
> Thanks,
>
> Victor
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.9/622 - Release Date: 1/10/2007 2:52 PM Start a New Thread

Yes. That is the problem.

From: 6... [mailto:6...] On Behalf Of
Peter Lissenburg
Sent: 11 ianuarie 2007 12:10
To: 6...
Subject: Re: [68HC12] Question SD CARD

When you say it initialized, have you read the CID or CSD, and it fails
reading
a sector?
P

Victor Adrian Prisacariu wrote:
> Hello.
>
> I have a question. I've been trying to connect an sd card to a hcs12x MCU.
> The card does initialize , but i can not get a data token when i try to
> read. Does anyone have any ideas how to solve this? (the card worked fine
on
> another MCU).
>
> Thanks,
>
> Victor
>
>
> ----------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.16.9/622 - Release Date: 1/10/2007
2:52 PM Start a New Thread

I have not worked on this for a while, but I will be soon. From memory, I did
find some cards that would work OK in a PC card reader, and yet behave this way
in SPI mode. My explanation at the time was that some manufacturers did not
implement the SPI mode (it was some years ago). But I doubt that is the case now.
Looking at my code, I send the "READ_SINGLE_BLOCK" and an address, with 0xff as
the dummy CRC.
Then poll the SPI port for a non 0xff response. If the non 0xff response is
0x00, then the code continues to poll waiting for the 0xfe.
Once this arrives, the data is read out in a loop.
By poll, I mean sending a dummy character, (0xff) and checking the character
returned, continuously (with a time out).
What part of this procedure is not working for you?
Or is my process different to your?
Pete

Victor Adrian Prisacariu wrote:
> Yes. That is the problem.
>
> From: 6...

















'



























Start a New Thread

I am pooling (sending 0xFF) till I get 0x00 and then till i get 0xFE. The
problem is that 0xFE doesn't arrive. And the same card worked perfectly with
a different MCU (PIC). Also the same software (I changed only the SPI
functions (lowest level)).

Could it be because I'm not using SPI correctly ? I use rising edge, MSD
first, 333kHz (for initialization) and 4Mhz after that. Also the function
for reading SPI is:

SPI1DR = myData;

While ((SPI1SR & 128)==0) {}

Return SP1DR;

Is this the correct way of using this card on a hcs12x ?

Of course to initialize it I by sending ~80 SCLK then CMD0_GO_IDLE_STATE,
CMD1_SEND_OP_COND and finally CMD16_SET_BLOCKLEN. All these work perfectly.

And to read one card sector I use:

BOOL CardReadSector(DWORD sectorNr)

{

WORD i;

SectorInBuffer = sectorNr; //using this for buffering (to
increase FAT operation speed)

sectorNr <<= 9;

convert.dword = sectorNr;

CardCommand(CMD17_READ_SINGLE_BLOCK,convert.byte[3],convert.byte[2],convert.
byte[1],convert.byte[0],0xFF);

if (CardResponse(0x00) == FALSE)

return FALSE;

if (CardResponse(0xFE) == FALSE)

return FALSE; //<- DOES NOT GET PAST THIS

for (i=0;i<512;i++)

Sector[i] = SPI(0xFF);

//no need for CRC

SPI(0xFF);

SPI(0xFF);

return TRUE;

}

BYTE CardResponse(BYTE response)

{

WORD count = 0xFFFF;

while(SPI(0xFF) != response && --count > 0);

if (count==0)

return FALSE;

else

return TRUE;

}

Victor

From: 6... [mailto:6...] On Behalf Of
Peter Lissenburg
Sent: 11 ianuarie 2007 13:01
To: 6...
Subject: Re: [68HC12] Question SD CARD

I have not worked on this for a while, but I will be soon. From memory, I
did
find some cards that would work OK in a PC card reader, and yet behave this
way
in SPI mode. My explanation at the time was that some manufacturers did not
implement the SPI mode (it was some years ago). But I doubt that is the case
now.
Looking at my code, I send the "READ_SINGLE_BLOCK" and an address, with 0xff
as
the dummy CRC.
Then poll the SPI port for a non 0xff response. If the non 0xff response is
0x00, then the code continues to poll waiting for the 0xfe.
Once this arrives, the data is read out in a loop.
By poll, I mean sending a dummy character, (0xff) and checking the character

returned, continuously (with a time out).
What part of this procedure is not working for you?
Or is my process different to your?
Pete

Victor Adrian Prisacariu wrote:
> Yes. That is the problem.
>
> From: 6...




















'






























Start a New Thread