uALFAT USB using I2C

[gerald1945]

I'm trying to run a uALFAT USB module in an embedded system with a PIC16C77 processor using I2C. The system is programmed in assembler. I tried to send the J command initially which was acknowledged but the command response I read back is erroneous. I'm assuming at power on, the on-board reset circuitry resets the module.
What is the first thing the module does? Does it place in its FIFO a string which I'll have to read out before attempting to send any commands?
It also appears that the I2C implementation does not correspond to the Phillips standard which would require I send a register address after the device read address.
I have tried almost every combination I can think of but with no success. The latest test was to read out the FIFO until I get a 0xff which should indicate the buffer is empty but this doesn't appear to work and the DATAREADY line stays high.
I have double checked my connections and they appear OK
I am losing significant development time over this and any advice/help would be gratefully accepted

[SupportAdmin]

uALFAT send a banner on power up that you must read. You should do that anyway since DATARDY pin is high

[gerald1945]

How long is the banner ?  I've tried reading initially until I get an 0xff and then check dataready but that doesn't appear to work.

[gerald1945]

I've written a routine which simply reads data back from the USB module until dataready goes low but it never does ?

[SupportAdmin]

Then uALFAT is not really in I2C mode! Make sure you set the pins for I2C mode and reset uALFAT on power up then keep reading the banner till you get back 0xFF. The banner will say GHI Electronics..........

[gerald1945]

I definately have pin 5 (SPI CLK) tied to ground and pin 8 (SPI SEL#) tied to +3.3v.  I've modified my system to allow a reset line to the module and put a long delay on it ( quarter of a second) before releasing it.  But I still get garbage back when i read the FIFO.  The module is acknowleging the read address and every byte I read back but they don't make any sense at all.

[gerald1945]

The I2C connections seem OK. When I send something to the module it acknowledges it.  The problem only seems to be trying to read responses.
I send a start command then the read address (0xa5) which is acknowledged. Then I read bytes and acknowledge each one. I would not send an ack to the last byte but I haven't got that far yet.
I've put a long reset on the module after power up to see if that clears the problem but it still persists.
Would it be sensible for me to purchase the ALFAT development board which would allow me to check out the modules and find out the firmware version.

[SupportAdmin]

We do not offer a development board. What product are you referring to?

Try to read only one byte in each transaction to see if this will work for you.

Do you have latest 3.0 firmware installed? If you are not sure the it will really help you to get started with UART/RS232 connection to your PC then you can manually try uALFAT out. Once all is good and latest firmware is loaded then switch to I2C

[gerald1945]

I was referring to the uPICFAT which is a sort of development board and which would allow me to check out the modules I have and download the latest version of the firmware.

As I am using the modules in an embedded systerm, there is no other way I can see to determine the firmware version as I can at present only communicate via I2C which is giving problems.

[SupportAdmin]

I was referring to the uPICFAT which is a sort of development board and which would allow me to check out the modules I have and download the latest version of the firmware.

This is a discontinued product plus it will not help since it uses SPI

As I am using the modules in an embedded systerm, there is no other way I can see to determine the firmware version as I can at present only communicate via I2C which is giving problems.

Since we are stuck, the only way to move forward is to use UART to get things started.

[gerald1945]

I am basically stuck with using I2C as it is already implemented on my board.
I rewrote my routine to read back bytes after power up by reading back individual bytes rather than assuming your FIFO would roll over to the next byte.
The bytes I received were :-
cr sp G H I sp Electronics,LLC cr followed what appears to be garbage but the routing did eventuallly find a 0xff.
Why do I get the carriage return and space prior to your banner?
My I2C routines are clearly working  but only if I read individual bytes back.  This is not a real problem with the instrument I'm developing but does question how you've implemented the I2C structure in the module.

[SupportAdmin]

uALFAT should work with multi-byte transfers but for now stick with one byte till you can read back the version number.

Since you have the banner, try now to get the version number using the V command. Make sure you have the latest firmware on it. See version log for 3.xx on this page http://www.ghielectronics.com/product/1

[gerald1945]

When I read the version number back using V <cr> , I get :-
Boot sp Loader sp  2.05 <cr> sp sp sp uALFAT(TM) sp 2.12 <cr> sp 0 0 <CR>  0xff
Again I've used seperate byte read back.

From this I presume I've got version 2.12 of the firmware.

If I need to update the firmware what is the quickest and simplest for me to implement ?  I cannot use the existing board as it is a dedicated unit.

[SupportAdmin]

As described in manual, put the new firmware on a media and then send update command. uALFAT will read the file and update itself.

[gerald1945]

Does this mean I can  upload the latest firmware and plug it into my dedicated system and send a U command to it?

[gerald1945]

What command do I send to do this?  The U command will clear a stick plugged in, so it would not read anything from it.
I can download the latest version of the firmware over the net but if I plug that stick into my system, what command do I use?

[SupportAdmin]

Please read the manual and look for "update firmware" command!

[gerald1945]

I've downloaded the latest version of the firmware and loaded into the module (I think) but now I cannot get the V command to work. When i do a test by testing both the ready and busy lines, the busy line clears but even when I read 0xff back from the FIFO, the ready line still stays high ?

I still get the problem that when I read the banner, I get the correct values but after the carriage return, I see 21 minus signs and other stuff which doesn't make any sense.

[gerald1945]

The firmware seems to have updated as I now get version 3.12 back when I read the banner back.
I then try to detect a stick by sending J followed by a <cr>. Both bytes are acknowledged but when I attempt to read a response back, the data ready line is always low and a read simple gives me 0xff. I've put in a 1 millisecond delay before attempting to read the data back but to no avail. Before I send the J command, I test the busy line until it is low which works.
Any thoughts?

[gerald1945]

To add to my last posting, I've sent the firmware update command which doesn't require a response and which has worked. When I send a command which does require a response, I get nothing back.  The dataready line stays low and I can read nothing back except 0xff.

I've put in delays and loops but to no avail. Do I need to send each byte individually by sending a command character, stopping and then sending the <cr> as a second character ?

[SupportAdmin]

Always start with version command

[gerald1945]

I can now read the banner and then the version. Both read back correctly. I then send the J command which is accepted. I then test the ready line which never seems to go low. I'm using an In Circuit Emulator and if I put a breakpoint after then J command, the system halts at the breakpoint. if I then continue the program, I get the correct response back.
What order of delay does the J command require before a response is ready to read ?

[gerald1945]

I made a mistake in my last post. The data line never appears to go high to indicate that data is ready to read.

[SupportAdmin]

Lets keep on V command, do not do anything else till you can read the version 10 times in a row with no errors and you see DATARDY line going high after you send V ans then it goes low after you read the response. Also, reading data while DATARDY is low will result in 0xFF

[gerald1945]

Everything seems to be sorted now - I missed an assembler instruction from my routines. I can now reliably detect a stick and initialise it.

One more question.
When I write data to a file of several hundred bytes, do I open the file for write, then write the first 100 bytes then flush it. For the next 100 bytes, do I just write again or open the file for append and then write the next block ?