Interfacing uCAM-TTL with Cortex-M3 (LPC1768)

[mkir]

Hello. I've recently bought the uCAM-TTL module and I've been trying to get a picture from it with the help of a development board based on NXP's LPC1768 processor. I'm using Keil's uVision IDE and the language is C. So far I've managed to get an ACK and a SYNC from the camera as well as send an ACK back from the MCU. But that's all I can do for now. Whenever I issue an INIT command, I consistently get a NACK back (of the "Command Header Error" type - e.g. AA0F0009F000). I've even tried with a delay and a RESET command instead of an ACK (as mentioned in this thread) but the response from the camera is the same. More precisely, I have noticed two kinds of behavior: i) If I turn the camera off and then on again, the program seems to hang after the "INIT command sent" statement (please see attached code). ii) If I reload the program to the MCU flash, the program continues past the "INIT command sent", eventually returning the "NACK for INIT received" statement. What I'm really troubled about is the fact that the method I'm using is the same as in the SYNC process (send a HEX command by writing to the Tx buffer of the UART and then read the response from the Rx buffer) but the result is always a NACK. On one hand, I do get a response from the camera which is a good thing. On the other...the response is always negative. Warning you in advance about my elementary C skills, could it be something in my code that I overlook? Could it be something else? Thank you very much in advance for any reply as getting an image from the camera is an important step of my MSC thesis and one I cannot do without!

Best regards,

Manolis

ps I think accidentally pressed "Enter" before finishing the post... Attached files uCam.txt (3.5 KB)

[ESPsupport]

I can't quite follow your code.

Have you tried comparing what you are seeing to the data sent and received from the uCam demo program?

What is it you are receiving that you are considering to be a NAK?

Are you sre you are giving sufficient time for the 6 byte responses to 'accumulate'?

[mkir]

I guess you' re right about my code since I made some assumptions regarding the MCU, that you might not be familiar with. Sorry about that so let me explain it a bit more.

First of all, there is another C file that I use in my project to initialize the UART. I do this with 57600, 8N1, assuming the camera autodetects this baudrate (and I think it does, since it sends back an ACK). Furthermore, the 1768 UART has a 16 byte long FIFO which I also enable during the initialization process. So, if I'm not mistaken, the timing for the transmission and reception is taken care of automatically (by the MCU, as long as I have enabled the FIFO). I'm not absolutely sure if this is so but I think that once I write something to the Tx buffer (LPC_UART0->THR of my code), it's the FIFO's responsibility to send it according to the selected baudrate. Similarly, whenever I read the Rx buffer (LPC_UART0->RBR), if there's something new inside, it's copied in the buf[] array. Hope this clears up a little the initial configuration I make before trying to communicate with the camera.

Trying to answer your question now, my main program is as simple as this:

int main(void) { SystemInit();UART0_Init(); while (1) { uCamSync(); uCamInit();

}

}
Whenever uCamSync is executed, what I see in the Terminal (I'm using Bray's terminal) is:

ACK received

SYNC received

Sending out ACK command

SYNC complete after x attempts

where x is almost always 7.

So the communication goes as planned and I assume the camera is synchronized after this.

But then uCamInit

is executed and as I've written I get one of two responses:

i) Either the program freezes after the "Sending out INIT command" statement, which makes me assume that the command is sent but the camera is not responding - there is nothing in the Rx buffer to be read.

ii) The program goes beyond the "Sending out INIT command" and reads the Rx buffer as intended, which, however, contains a NAK.

The way I find out that it is indeed a NAK is through the chartohex

function you can see in my code. What this does, is convert the received characters to their hex equivalent just for convenience. So whenever I get the second response (program goes beyond "Sending out..." etc), what chartohex returns is something like AA0F0002F000

. Whenever I reload the program, the only thing that changes is the NAK counter (it's incremented).

And another really strange thing I've noticed is that for my program to work, I have to make the connections according to the datasheet (that is, pin 4 of the camera which is Tx goes to P0.3 of the LPC1768 which is Rx and pin 5 (Rx) of the camera goes to P0.2 (Tx) of the MCU).

BUT for the uCam software to work, I have to reverse the connections otherwise I get the message:

Sync [AA 0D 00 00 00 00] Response missingSync failed, is uCam connected?

This is something I really can't explain. If I try reversing the connection and execute my program, it never starts.

Well sorry for the long response but I tried to explain exactly what's going on. Should you need any more information about my configuration in general, I'll be more than glad to provide it!

Best regards,

Manolis

[ESPsupport]

When you send the ACK command you do it using
UART0_SendByte(ACK[i]);

Whereas to send the 'other' commands you use

while (!(LPC_UART0->LSR & 0x20));
LPC_UART0->THR = SYNC[k];

Since you are geting the error for the next command after the ACK is sent I'm wondering if UART0_SendByte is doing something funny (or the compiler is doing something funny and trying to 'translate' a char into a byte, if you know what I mean

[mkir]

The UART0_SendByte and the implementation with the While are essentially the same. I mean the UART0_SendByte is this function:

int UART0_SendByte (uint8_t ucData){while (!(LPC_UART0->LSR & 0x20)); return (LPC_UART0->THR = ucData);}
The only reason I used both ways was to make sure I get the same results (which I did since they are identical).

Now when it comes to the INIT command, I'm starting to think that it has something to do with the Rx buffer not responding the way it should. This is because I don't seem to get anything back after the "INIT command send" even though I can see on the Terminal that the command is actually sent. The way I am waiting for a response is similar to the way I write a character to the Tx buffer meaning that I utilize the Line Status Register again, like so:

for (j = 0; jLSR & 0x01));buf[j] = LPC_UART0->RBR;}

According to the MCU's user manual (pg. 307 or see this image for the LSR only) and if I understand correctly, what the above code does is wait for the receiver FIFO to fill with one (or more characters) and then write them one by one to the buf[] array (I only need six characters though).

This is the exact same procedure I used to get an ACK and a SYNC back from the camera and it worked without problem. But after I send the INIT command, the program freezes and I can't seem to get anything back from the Rx FIFO. I even tried to reset the Rx FIFO before sending the INIT command but I still get nothing back.

[mkir]

Well there's been some progress since yesterday as I "accidentally" figured out what might be wrong when sending the INIT command.

Thinking about toggling a led every time there's something in the Tx and Rx buffer, so as to see if everything works as intended, I added a small delay after the While. And it turned out that this delay was crucial in order to get a valid response from the camera. So the INIT command looks like this now:

void uCamInit(void) { printf("\n\rSending out INIT command"); for (k=0; k<6; k++) {while (!(LPC_UART0->LSR &amp; 0x20));//LPC_GPIO2->FIOPIN ^= (1<<7); delay_ms(1000);LPC_UART0->THR = INIT[k];} printf("\n\rINIT command sent"); for (l = 0; l<6; l++) {while (!(LPC_UART0->LSR &amp;&amp; 0x01)); //LPC_GPIO2->FIOPIN ^= (1<<0); delay_ms(1000);buf[l] = LPC_UART0->RBR;chartohex(buf[l]);} printf("\n\rResponse received"); if (buf[0] == 0xAA &amp;&amp; buf[1] == 0x0E &amp;&amp; buf[2] == 0x01 &amp;&amp; buf[4] == 0x00 &amp;&amp; buf[5] == 0x00) printf("\n\rACK for INIT received"); else if (buf[0] == 0xAA &amp;&amp; buf[1] == 0x0F &amp;&amp; buf[2] == 0x00 &amp;&amp; buf[5] == 0x00) printf("\n\rNACK for INIT received"); }

I also managed to get an ACK back for the SNAPSHOT command, in the same way.

What I haven't had any luck with yet is the GET PICTURE command. The behavior I'm getting is similar to the one I got before adding the delay in the INIT command. That is the program freezes and I don't seem to get anything back from the Rx FIFO. The first thing I tried of course was again to add a small delay but it didn't seem to make any difference when it comes to GET PICTURE.

Assuming that the way I'm sending the commands works, is there something I'm missing in the process?

Thank you,

Manolis

[ESPsupport]

Hmm, a 1 second delay between transmitting and receiving each byte seems way wrong, yuo need to check your UART setup and the way you are using it.

Once you figure that out it will hopefully all start working.

[mkir]

Well I think it's somewhat less than 1 second due to the implementation of the delayms function but I understand what you mean nevertheless.

Seeing the way I initialize the UART though, I can't figure out where to start from. The minimal configuration I'm using which is the one that seems to work for now is this:

#include "lpc17xx.h" #include "uart.h"#include #define FOSC 12000000 /* Crystal Frequency */ #define FCCLK (FOSC * 8) /* System Frequency PINSEL0 |= (1 PINSEL0 |= (1 LCR = 0x83; /* UART Line Control Register Initialization = 10000011 */
/* 8-bit character length, 1 stop bit, no parity, disable break transmission, enable access to Divisor Latches */ usFdiv = (FPCLK / 16) / UART0_BPS; LPC_UART0->DLM = usFdiv / 256; LPC_UART0->DLL = usFdiv % 256; LPC_UART0->LCR = 0x03; /* Disable access to Divisor Latches after setting the Baudrate LPC_UART0->FCR = 0x07; /* FIFO Control Register - Enable and Reset the TX and RX FIFO */ }

I understand that you may not be familiar with this specific MCU architecture but I think that from your experience you can determine whether this initialization is correct (and "enough") or not. Is there any parameter I'm missing? Is my fundamental assumption that the FIFO works "on its own" once it's been initialized, correct?

What really troubles me as I've told you is the fact that the procedure for the first three commands (SYNC, INIT, SNAPSHOT) is exactly the same and works, even though it needs this delay. So why does it stop working only after GET PICTURE is sent? Also are this three commands enough for the GET PICTURE to work or do I need to explicitly set the other parameters as well (Baud Rate, Light, Package Size)? According to the datasheet, I think they are (I'm aiming for RAW files in the beginning). But I'm just asking in order to determine which of the other parameters is so important that maybe I should set it "by hand", so to speak.And I should also tell you that there' ve been one or two times that I did get an ACK back for the GET PICTURE command, using the method I'm using. But the image size returned from the camera was zero ( AA 0A 01 00 00 00) so I didn't really count that as a success.

I'm really sorry for asking you all these questions but I can't seem to find what I'm doing wrong or a way to make the camera work in a consistent manner.

Thank you again for your time!

Manolis

[ESPsupport]

Sorry, I've never played with a UART with a FIFO of that depth at the 'Metal' level before, however, what you're doing can't be completely wrong as you are getting somewhere.

Use the uCam demo software to talk to the camera using the options that you want to use and closely look at what goes in both directions according to it.

If you have a couple of 'spare' rs232 receive 'ports' you could connect them to both the TX and RX lines and use Docklight to monitor both simultaneously (you can do this with the 'free' vesion), that should give you a handle on what is really going on.

[mkir]

Ok. Thank you again for your suggestions and I will definitely look into Docklight! I haven't heard of it before and it seems really useful.

Best regards,

Manolis