Problem with Flowcode SPI macro with accelerometer component

[Mathy]

Nothing to do, I have nothing who moves.

I tried to reload my program with SDCARD in hardware SPI2 and all works fine.

I don't understand

[Mathy]

Hello Benj,

I tried again today with an Tektronix TDS2014B scope.
I tried your program with your pin connection ( CS on RB5 ).
I tried with all your files ( .FCD, CAL.c and ACCEL.c ).

It is still don't work. The SPI lines doesn't move.

With the same board, I loaded a simple program who writes on the SDCARD on hardware SPI 2 and it works, I can see on my screen beautifull signal and I can read the DATA on my computer.

Are you sure you tried with the same MCU family ?
Is it possible to have your generated .hex who is working for you ?

You can understand that I am surprised that it works with you while everything works with me except the accelerometer in SPI.

Thank you for your time,

Mathy

[Benj]

Hello Mathy,

Here is my hex file. I will have another look for you if this fails.

[Mathy]

Hello Benj,

Thank you for the hex file but I have exactly the same problem.
I can't see anything on the screen.

Loading the hex file who writes on SDCARD on the same hardware SPI peripheral on the same board give me good result.
I can capture the SDO line with my scope.

With your hex file, I have a level low.

Thank you for your help

[Mathy]

Hello Benj,

Have you had time to look at my problem?

I had an idea this night :
Maybe I compiled with BoostC and you with Hitech 9.80. But no, after trying this possibility, the compilation does not finish. Too many error with the file CAL.c

[Mathy]

Hi !

Any news ?

[Benj]

Hello,

I tried using BoostC. We are updating to v5.5 in the next couple of days. Please can you wait for this release and then see how you get on. As I say it seems to be working fine on the hardware here so O'm really not sure why it is not working for you.

[Mathy]

Hi Benj,

I don't know how you did your test because the .fcf or the .hex file you gave me don't work and can't work.
I tested it on two different board with always the same MCU reference ( 18f26k22 ).

As i said many times, none of the SPI lines including the CS line moved.
I made some tests few minutes ago and I found something.

The only way to have something who moves on my scope is to edit the define macro to change from :

#if (%a_BUS == 0) //SPI COMPONENT DEFINES

#define %a_CS_PIN %k
#define %a_CS_PORT port%j
#define %a_CS_TRIS tris%j

to


#if (%a_BUS == 0) //SPI COMPONENT DEFINES

#define %a_CS_PIN 5
#define %a_CS_PORT porta
#define %a_CS_TRIS trisa

Now, I can see my CS line moving BUT ONLY with the initialise macro.
This macro works. I can read a return value = 0, so the accelerometer is well initialized.
During the initialise period, I can see the SDO, SCK and SDI line on my screen.

BUT, it is the only macro who is working. The two others do nothing.
The CS line and SPI, SDO and SCK, nothing move.

With all the tests I made, I'm pretty sure that It is a problem from Flowcode.
Im waiting since a long time now and I don't see how Flowcode 5.5 will fix this problem.

Thank you for looking again. You will see in the attached file the program who is working with CS at port A5.
You will see that something happening with the init macro and then nothing with the others.

Have a nice day,

Mathy

[Mathy]

Hi,

I just tested the new flowcode release but without success.
I have exactly the same problem.

It it possible to fix this problem.
I think I posted all you need in my previous post.

Thank you

[Mathy]

Can you seriously take care of my problem ?

[Mathy]

Help heelllppp HHHHHHHHHHEEEEEEEEELLLLLLPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP !

Can you really make some test and fix your macro ?
Or tell me if I have to put Flowcode in the trash ?

[Benj]

Hello,

Can you seriously take care of my problem ?

I have already rigged up the hardware and replicated your setup and it worked fine for me, not really sure what else I can do to help...

Can you really make some test and fix your macro ?

We try and help those that help themselves, can you tell us what you have tried to overcome this problem. Changes or attempts to understand component C code, testing on other devices, testing using 3rd party simulation software, changing pin connections, creating simple test applications, using the SPI component rather then the accelerometer component etc...

Or tell me if I have to put Flowcode in the trash ?

Putting Flowcode in the trash isn't really going to help solve the problem unless your microcontroller has a sense of irony, which i'm sure some of them do, ghost in the machine and all that

Are you testing using a single microcontroller on a single board or do you have a couple of boards to test with. If there is only one then there could be an issue with the hardware in which case maybe worth making a second test rig as a sanity check. If you have multiple boards then could it be something your doing wrong on the board?

[Mathy]

Hi,

I don't know how you replicated my hardware because the hex file you gave me don't work on real hardware with the accelerometer.
Tested with 18F26k22, 18f25k22 and now with 18LF25k22
If you had read all my answers, you would have understood that I have tested on several hardware with simple programs, just the SPI component or the SDCARD component who works very well.
Recently, I tested with the RF component too and all is perfect, with hardware or software SPI. So I think all my hardware are good.
I don't know how I can be more clear.
My English may be so bad that you don't understand my words.

I found something last night, the program is waiting after the RDY/INT pin
If I pull this line high, I can see on my scope the SPI bus !

So I removed the RDY/INT pin detection in your code and now, I can see the spi bus without this workaround.
I changed the initialisation code to set 0x84 to the 0x21 register instead of 0xC4 to update the accelerometer data continuously.
But it still don't work.

Now, as I can read the SPI line, I see that your update_XYZ macro send those values :

0x29,0x55,0x29,0x55,0x2B,0x55,0x2B,0x55,0x2D,0x55,0x2D,0x55

I don't understand why 0x55 is sent but I can find in your read_register macro this code :

#if (%a_BUS == 0) //SPI TRANSACTION
Retval = %a_SPI_Master_Byte(0x55);

I don't understand C code, particularly with all the "%" and I don't understand why you send 0x55 ?
What is it for ?
I don't see anything in the datasheet for that.
And I don't know why the register is sent twice ? ( maybe my very cheap logic analyser ).

Can you have a look at this ?

Thanks

[Mathy]

I just did an other test.
When sending by the simple SPI macro the value 0x28,0x29,0x2A,0x2B,0x2C,0x2D to my logic analyzer, those values seems to be well recognized.
So I think there is a problem with the flowcode macro.

[Mathy]

Hi,

I think there is a problem in your init_transaction code.
I made this change and now it works very well.

Code: Select all

	#if (%a_BUS == 0)									//SPI TRANSACTION

		FC_CAL_Bit_Low(%a_CS_PORT, %a_CS_PIN);

		if(multiple)
			reg = reg | 0x40;
		if (mode)
			// reg = reg | 0x01;
            reg = reg | 128;

I change your 0x01 code by 128 or 0x80 to set the D7 bit to indicate a read.

I really don't understand how you could say that it worked for you.