Coldfire V1 SPI with Ublox Neo 5Q

[David_UCT]

I am working on a simple GPS implementation using a MCF51JM128 and a UBLOX neo 5q selected for its SPI capability. 

Currently the system is temperamental in that a system reset will result in either the correct data being received via the SPI port, that is a, NMEA bit stream.  Or I will receive periodic garbage in the same period as the NMEA stream.  The garbage is always the same there are about 4 variations and each is recognisable.  Further this cannot simply be a matter of selection of protocals as there are only 2 available protocals on the ublox.

I have attached a filet showing the current setup of the SPI wire connections.  The GPS chip is connected via SPI2 and uses the FIFO mode.

The following links are the code I have written for the SPI2 FIFO.  They are displayed on slexy code viewer so that the code is easier to read.  If anyone would specifically like files please ask.

SPI Functions: http://slexy.org/view/s2oGSG8wwF

Main: http://slexy.org/view/s21XrHBONN

My Question finally is firstly have I missed something in terms of the hardware connections?  And second is there a common problem that could cause the corruption data in the manner that I have described.

[DaviddeBruyn]

Hi,

I have exactly the same problem! I had to write my own SPI software routine to solve it, but now its erratic again!

By the way, if you examine the data, it looks like its slipping bits...

Did you ever solve your problem? If so, please could you let me know.

Thanks

[DaviddeBruyn]

Ok,

I have managed to fix the problem, but I still don't know what the root cause is.

Once I noticed it was bit slipping, I implemented a sync function which syncronised the input.

It worked first time!

Ublox has also very bad support for SPI in their docs. I think its because there is a problem with their shift register implementation. It doesn't seem to reset on Chip Select, which is why once you have bad data, its always bad.

They have also got a very low data rate (25kHz) imposed limit, but I was able to push it much higher by just syncing the input.

Send me a PM if you want to know how I synced it. Its very short and easy to implement.

Ublox modules are great, but their support it shocking!

[David_UCT]

Hi David

Thanks for your reply, it would be great if you could show me how you wrote that synchronisation function!  I ran out of time to deal with the problem and had to move onto other work.

Thanks

[David_UCT · Accepted solution]

For anyone else that encounters this problem the issue is essentially that because the UBLOX shift register does not clear properly when enabling an SPI transmission with the module the data is shifted by the number of bits that were not cleared from the shift register. 

To fix this you must write a program that analysis the input data to work out how many bits the data has been shifted, and then you must shift all your incoming SPI data by that amount for that transmission.

[AntiGeri]

Hi David,

Reading the forum topics on SPI, I have just came across your posting.

I took a look at the schem. you posted.

I dont know if the schematic is incorrect, or the module pins are 

swapped on the symbol, but checking the spi data lines shows, that the

coldfire MOSI pin is connected to the module MISO pin, and the other ones also,

which means that the master-slave SPI link looks like:

-Coldfire Master Out and Slave in pin is connected to GPS Master In and Slave Out,

-Coldfire Master In and Slave Out pin is connected to GPS Master Out and Slave In,

to clarify:

-MISO: on the master (CF), it is an output, and on the slave(GPS) is an input

-MOSI: the other way around.

Either the schematic is wrong, or the circuit setup shouldn't work...

Best regards.

[David_UCT]

Sorry I have a bunch of iterations of that schematic.  The schematic is wrong, the hardware is connected correctly and functions correctly.

Thanks

Dave Wright