QSPI - offset after reset?

[mjbcswitzerland]

Hi All

Who has more experience with the QSPI and can explain the following?

I have an MC5213 and am using the QSPI to read in inputs via a shift register chain.

I initialise the QSPI for 10MHz master mode and read in one byte of 8 bits when starting to get some ID bits at the start of the shift register chain.

After that the shift register chain is read periodically by performing 2 x 13 bit reads.

This works fine.

Now I reset the board (not powerup, but by asserting RSTI). Using a logic analyser I see that the operation is identical and the data being received from the shift register chain is identical. However the data in the QSPI buffers is shiften by about 4 or 5 bits - and not always the same shift (therefore can also not be compensated).

So summerising:

After a power on reset it works perfectly every time. On a RSTI reset the data is shifted in the QSPI registers. Don't forget the data CS, CLK, DIN are identical, confirmed using logic analyser.

So what's going on? All data bits are there but offset...and why only after a reset but not power on. It is as if the RSTI is not performing the same reset as when removing power.

By the way. If I remove the initial 8 bit transfer performed once after startup the problem doesn't occur ()as far as I can remember), indicating that the offset may have something to do with moving from 8 bit to 13 bit buffer mode but it is also not totally stable.

So what is the reason???

Regards

Mark Butcher

www.mjbc.ch

[J2MEJediMaster]

I'm not familiar with the QSPI, but I'll take a shot at this. It sounds like when the powered reset (RSTI) occurs, some cruft in the registers configures the device to apply an extra shift to the bits. When the processor is reset, does it execute the same initialization code? If the answer to that is no, then you should probably ensure that it does. If the answer is yes, then there's something missing in your initialization code. Have you examined the bits on all of the registers when the processor comes out of reset, versus when the processor comes out of power-up? Perhaps certain bits, although they may not seem applicable to your code, might need to be forced to zeros or ones. Just an old hacker's thought on your problem.

---Tom

[mjbcswitzerland]

Hi Tom

As far as I know there are no uninitialised bits after a reset.

I haven't done any further study in the meantime since at the moment I can simply assure that the board is powered up rather than reset - later it will of course become an issue again as the product leave the first bench testing phase.

I will dump the registers after a power up and after a reset to see whether I spot anything.

Cheers

Mark

[mjbcswitzerland]

Hi Tom

I have now performed the test. The SPI control registers are copied to an array on startup for checking later and the present SPI contents can be read when desired.

Here are the results.

1. Power up.

Input states: 0x007ffc7c

QSPI original registers
0x0104 0x0404 0x0000 0x0000 0x0000 0x0000

QSPI registers now
0xb704 0x0000 0x0110 0x0001 0x0012 0x0000

2. After a RSTI reset

Input states: 0x03c1fff1

QSPI original registers
0x0104 0x0404 0x0000 0x0000 0x0000 0x0000

QSPI registers now
0xb704 0x0000 0x0110 0x0001 0x0012 0x0000

Registers are QMR QDLYR QWR QIR QAR QDR

The result shows that the resister contents are identical - after a reset and after configuration. Input state displays the value received from the shift register chain in each case. Here it is seen (remembering that only 26 bits are read in and so the 6 MSBits are '0' and not used) that the 26 bits of data are the same but in the second case (after RSTI reset) are shifted by 6 bits to the right.

I repeat that the data arriving from the shift register chain is identical in each case (confirmed with logic analyser) and this shows that the shift is in the QSPI input buffer.

The questions are still:
- Why is this happening?
- How can it be avoided / corrected?

Any ideas??

Regards

Mark
www.mjbc.ch

[J2MEJediMaster]

OK, I don't know what's going on here, and I'm sorry you had to go through the trouble of dumping those registers. Groping at straws, I searched the Freescale web site for FAQs and this is what I found that makes the most sense. It may not be applicable to your situation, but I thought I'd point it out. It seems you have to back off on using the QSPI until it says it's completed an operation. It's possible that the device might still be busy (or thinks it is) coming out of a reset.

Here's the FAQ link.

Hope this helps,

---Tom

[mjbcswitzerland]

Hi Tom

I have read through a load of FAQs but haven't found anything related. Which specific FAQ are you refering to?

The only thing which I saw was a functional limit of 500k for an SPI although it can run upto 12MHz. There was no reference as to which processor or SPI it was talking about so this is probably nothing useful. I have no problem with an EEPROM file system over SPI, just with the 8 bit read followed by 2x13 bit polling.

"It seems you have to back off on using the QSPI until it says it's completed an operation"
Can you say how this can be checked? Presently I'm doing a single 8 bit transfer very quickly after reset and then I start polling with QSPI after a delay of 1s (polling rate only 4 times a second).

Thanks

Mark

[J2MEJediMaster]

Well, I had to link to the doc in question on my previous post, but on trying it, I wound up nowhere, even though the page reference and my link are the same. To save you more hassle I'm just going to post the contents of the FAQ here:

Question. When using the QSPI on MC68HC16 and MC68300 microcontrollers, does the setting of the SPIF bit indicate that the current transmission has completed?

Answer.

No. The SPIF bit indicates that the last byte in the QSPI transmit RAM has been loaded into the QSPI shifter. The setting of the SPIF bit indicates to the CPU that new data can be written to the QSPI transmit RAM

In some cases, programmers have cleared the SPE bit with their software as soon as the SPIF bit sets. This will truncate the last transmission of the QSPI.

The proper method to disable the QSPI is to monitor the SPE bit. This bit will automatically clear itself. When this bit clears, the current transmission plus a programmable delay time will be finished and there will not be a problem with changing the function of the QSPI or starting another transmission.

Once again, the QSPI will be active until the SPE bit self clears. No attempt should be made to reprogram the QSPI registers or transmit / receive RAM until the SPE bit self clears.

[mjbcswitzerland]

Hi Tom

Thanks - that forced me to get down to detailed work again.

I am not sure that the FAQ is relevant to the ColdFire QSPI because I can not find the SPE bit in question. What I did however do was:
1. Built a long delay after the first transfer to ensure that nothing was taking place before something was ready. This didn't seem to have any effect and resets still caused the shift to occur.
2. I rebuilt everything using SPI interrupts so that I didn't have to poll the SPIF flag on the first read. This again didn't change the characteristics.
3. I then removed the first read to confirm that it was stable in the normal mode (using SPI interrupts and polling shift register inputs via the interrupt every 700us). It was, so I returned my attention to the first read again.
4. I then made a change in the way that the first byte (actually a 16 bit transfer) was read. It was being read with CPHA at '0' and the phase was changed to '1' before the fast polling started. I changed the phase (so that there was no difference) and the problem has gone.

I conclude that it had something to do with the phase change, however I can not explain why it only produced a shift after a RSTI reset (but not every time as I found - it tended to happen more frequently when the RSTI '0' was longer - 1 to 2s).

Therefore it is probably that the problem has been resolved - I avoid the phase change, which is unnecessary anyway.

Since I know that if I miss out the first read (required to read a few configuration bits in the shift register chain immediately after reset) there is never a problem. There is also the possibility of bit banging them over GPIO before converting to QSPI operation. But I have just tested a lot with short and long RSTI resets and haven't seen the issue since the CHPA modification, so it does look to be stable.

Very strange but if it works its best not to touch it again.

Regards

Mark

PS. I have another strange but urgent issue at the following. Maybe you missed it?
http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&message.id=672
It is for a different project (M52235) which should start in 2 weeks time but we haven't been able to prove that it is possible. PLL issue which is also being very stubborn...

(Alban highlighted link)

Message Edited by Alban on 2006-08-31 05:29 PM