Trouble using ALFAT OEM's SPI interface with a DsPic

Hi !

I am new to ALFAT and I am trying to set up a communication between my DsPic (33ep512mu810) and the ALFAT OEM using the SPI interface.
I think the problem comes from the wiring circuit: not sure how to set the SPI_MOSI high at power-up ?
Through Matlab Simulink’s SPI block I’m able to set the SPI_SSEL high and then the reset pin high to launch reset.

I would be really grateful for any help on the matter !

1 Like

hi, and welcome

to ensure lines are held high at power up, until driven low by the microcontroller, you just need to add a pull-up resistor on that line.

Hello, thank you ! I will try this today.

I also have a question regarding the commands sent to the ALFAT. I read on the website that “traditional” Read/Write commands are meant for writing/reading inside a file, whereas the SPI write/read frame is specific to sending commands to the ALFAT.
However, I am using Simulink and more specifically MPLAB Device Blocks to flash my DsPic and set up the communication with the ALFAT. The SPI block only offers read/write commands. I was wondering if I would therefore be able to send the commands directly (as in sending byte by byte but the way I was able to when using UART), or if it is obligatory to use the frames, which would complicate things a bit.
Is it mandatory to use a full C program, even for a simple application?

I’m not an ALFAT expert by any stretch (I can spell it right - most times I can spell it :slight_smile: ). But there’s absolutely no need to use a C program - whatever you use however needs to communicate appropriately to the device (this is no different to any two hardware devices and their interfacing, really).

Frames. Explaining this is somewhat hard. A frame in it’s simplest is a set of bytes that always includes three bytes at the start as well as the actual payload. If you look in the SPI frame section of the manual, then the first example command is split over two frames (F1 and F2) and happen to contain the command “@ M:\TEST” (** note to GHI the frame and the text above it don’t match, the text says “M:\TEST\T”. Fix one or the other). I’m sure once you connect things up and start working with it you’ll quickly grasp what it means in operation (again, not that I’ve used it but I have faith in you :slight_smile: )

1 Like

went looking for helpful references for you. Here’s an SPI example that you might find useful to understand what is being written and when

https://www.ghielectronics.com/community/codeshare/entry/966

There are also downloads available at https://www.ghielectronics.com/support/file-system that might also be of use.

Thank you for your answers !

Yes I found that example too, but I was somehow confused when it came to the Read Frame yesterday. After a re-read I think I do get a better sense of it !
I will try this when all is set up, hoping it works out !

1 Like

Me again !

Checked all the pins thanks to an oscilloscope, so everything seems right now when it comes to the wiring.
I can’t seem to read the banner string after reset though, but I think it might be linked to the Read Frame ? I have yet to make it work.

On an entirely different note: when it comes to the UART interface, I was wondering how high the baud rate can go ? I was able to set it and make the ALFAT work at 921 600 baud yesterday. But I was wondering if it could go as high as 1 843 200 baud or even 3 686 400 baud ?

Additional question (sorry ! I’m really having trouble making this work): if I have understood this correctly, I have to use a Read Frame to read the banner string after reset (and is the banner then the full “\n GHI electronics, LLC…” or just “!00” ?)

If so, is it indeed something such as:
0x02 (Frame type)
0x03
0x00
=> Read the following six bytes ? (like on page 20 of the user manual ?)
I could really use some examples of frames…

@ Ava R. -

To read banner, 3 bytes header frame should be “0x02 0x49 0x00”, and next 73 bytes of payload and all of these bytes should be 0x00.

But that is hard code. To read data through SPI,

    1. Send 0x02
    1. Send low byte of size want to read
    1. Send high byte of size want to read
    1. Read the response. There will be 3 bytes response. Ignore first bytes, second and third byte will be available size from ALFAT.
    1. Send payload with amount is the same as you got from byte 2nd and 3rd at step 4.

Usually at step 4, you will get (0x00 0x49 0x00) (73 bytes). But somehow, if you got less than 73, like 69 bytes, you have to send 69 bytes payload. To read rest 4 bytes, you have to send Start Read Frame again, meaning repeat step 1 -> 5 again.

@ Dat -

[quote]
But I was wondering if it could go as high as 1 843 200 baud or even 3 686 400 baud[/quote]

We have tested at 3Mbs.

Hello ! Thank you for you answer !

Right now I am sending the bytes from the MCU and observing the answer from ALFAT on the oscilloscope, just to see if I do get an answer.
I sent the following bytes: 0x02 , 0x03 (since we want to read a 3 byte answer ?), 0x00.
Then I try reading a response as you said.
However the display on the oscilloscope is clear: 3 bytes [em]are [/em]sent, but the MISO line stays flat whatever happens. I really don’t know what the issue can be ? It is as if ALFAT doesn’t understand the bytes sent to it…

Here are some screens from the oscilloscope to make it clearer !
In yellow, it is Slave Select, red corresponds to Reset, blue to MOSI and green to MISO.
The second picture is a close-up. As you can see, we set MOSI and SS to 1 then did the reset. Afterwards we send the 3 bytes to the ALFAT, but nothing happens…

Thank you for the answer about UART !

@ Ava R. -

what frequency are you using please?

I wasn’t sure which one to use (the manual only tells not to go over 24 Mhz), so right now it is at 11.667 Mhz.
Could the problem come from there ?

Just tested with lower frequencies, but the situation doesn’t seem to change

you are talking about the SPI frequency, right? How about you try in the 200KHz range?

Yes, the SPI clock frequency.
I just tried 218.75 Khz and even 136.72 Khz which is the lowest valued offered but the MISO signal still stays flat, like it is on the pictures I posted. There really doesn’t seem to be any response from the ALFAT.

Here is the current configuration of the SPI block (with the actions to reset and send the read frame)

Can you capture the comms on MISO/MOSI/SCK/SSEL from your oscilloscope/logic analyser?

Here is what appears on the oscilloscope with the current configuration (displayed on the previous post), with SSEL/SCK/MOSI/MISO