Problems with uM-FPU v 3.1

[papaof2]

This is my first time using the uM-FPU. I have an EM-406 GPS connected to SERIN of the uM-FPU and have adapted the GPSdemo.bas program from MicroMega to work (some of their original definitions are no longer available, such as SWAP, SIN, ATAN).

The problem is the instability of the PICAXE<->FPU combination. On startup, the FPU chip is identified and the version displayed (most of the time). However, it may or may not display the messages from the GPS - sometimes the code fails waiting for the first message, but it has received and displayed up to 69 messages before everything locks up (must hit reset to download to the PICAXE). The lockup occurs with either sertxd and using the PC to monitor the outputs or with an on-board LCD driven by serout.

The PICAXE 28X2 is on an AXE022 board; the uM-FPU is on a breadboard with the GPS, 3.3 volt regulator, level shifter (GPS serial output is 2.8 volts). The I2C leads are about 2 inches long and are twisted. There is a 100nF cap across the power pins of the uM-FPU.

Power is from a wall-wart with 4.46 volts output.

The code is running in slot 1 of the 28X2.

I would appreciate any ideas.

John

 

[Andrew Cowan]

Have you got the 4K7 pullups on the I2C lines?

A

 

[papaof2]

Have you got the 4K7 pullups on the I2C lines?

Yes, they are on the AXE022 board.

John

 

[BeanieBots]

Can't remember the minimum voltage for the uFPU but check it is happy at that voltage.
The 2.8v on the serial is very low if that is the logic high and not the DC average. Might not be enough to reliably set a PICAXE input logic level.

The uFPU is VERY power hungry when processing. Decoupling REALLY IS ESSENTIAL when using it. I'd suggest 1uF as well as the usual 100nF to be dedicated to this chip.

 

[papaof2]

The level converter takes the 2.8volt serial of the GPS to 4+ volts That should work, as the uM-FPU datasheet shows using a MAX232 to interface to RS232 levels

Not sure if I have a 1uF cap, but will try a 10uF - and re-read the datasheet in case I missed something in the setup.

Thanks,
John

 

[BeanieBots]

i'me sure you already know but don't forget that the MAX232 inverts the signals. Besides that, I'm not sure what else to suggest. I've only ever used it for sums and and the 12-bit ADC with FFT, never had any issues with those aspects besides my own stupidity.

Setup is not simple so well worth double checking.

 

[papaof2]

I'm not using a MAX232 - that's just for reference that the uM-FPU serial levels are TTL (it needs a MAX232 to talk to a PC).

I pulled the datasheet and verified the wiring (again). I also checked I2C communication with a 24LC256 EEPROM - it reads and write fine every time.

I may move the uM-FPU to a different row of holes on the breadboard tomorrow (although the breadboard is new for this project).

At least I can still reliably read the GPS via hserin on the 28X2...

John

 

[LarryGrad]

Hi John.

I am currently working on a project that involves the Micromega FPU and a 20x2 Picaxe.

I ran into a similar problem as you described. My read/write via I2C worked fine if I just did one read/write (FCALL then get result). But if I put it into a loop to read/write quickly the I2C bus went wacky (as viewed with a logic analyzer). When I slowed down the frequency of read/write or did just one read/write it worked fine. I am running at 64m and HI2CSetup is at fast_64. Moving it to slow_64 did not help me.

A few ideas: Make sure you wait for the status byte to be returned after issuing a command to the FPU, like:
fpu_wait:
readi2c 0, (statusByte) ' wait for ready status
if statusByte <> 0 then fpu_wait
return

Did you set the I2C as default within the FPU IDE? Or are you relying upon the CS and MCLR lines to set that? I set mine within the IDE to ignore , and MCLR to +5v and pin CS to GND. Go to the "Function" menu, then "Set Parameters". You will see the I2C setting there.

If all else fails, you can contact Cam at Micromega via their forum http://tech.groups.yahoo.com/group/uMFPU/ . Cam is always a great help.

Good luck with your project.

 

[papaof2]

I'm using the MicroMega sample GPS code, which uses I2C. Their code has the fpu_wait loop.
It may be an unreasonable expectation, but I expect the manufacturer's sample code to work ;-)

Local time is now 1:15AM, so I'll wait 'til tomorrow to get back to the project.

John

 

[papaof2]

I found the problem.

The uM-FPU code is running in slot 1 and is triggered from code in slot 0.

Remember that your variables and pin setings are carried between slots - and so are any background processes. The slot 0 code had a line left from previous testing:
servo B.4, 150 'center servo
Having servo running in the background apparently interferes with I2C timing.

Commenting out the servo line in the slot 0 code allows the slot 1 code to run with no problems - at least for 2500 NMEA messages, at which point I stopped the test ;-)

John