Porting Tcp/ip To Boostc

[Dra 0]

Thanks Tom looking at rtc.c, I can see that timer 3 is being used to generate the clock. My chip 18f6722 does have a timer 3. " it look like the issue has something to do with the following define: -

"define RTC_INIT_TIMER pie2.TMR3IE=1; t3con.T3CKPS1=1; t3con.T3CKPS0=1; t3con.TMR3CS1=0; t3con.TMR3CS0=0; //code used to init the timer so it can run when RTC_ENABLE_TIMER is set to 1"

In particular the "TMR3CS1" of "t3con.TMR3CS1=0" what does it do? And with that since the other timer values don't generate a compiler error can I assume they will work correctly with my chip?

[tom 2007 0]

t3con.TMR3CS1 is for selecting the clock source. In your case I see there is only 1 clock select option: t3con.TMR3CS=0 for internal clock select.

 

I think this may work better in your case (please check):

#define RTC_INIT_TIMER pie2.TMR3IE=1; t3con.T3CKPS1=1; t3con.T3CKPS0=1; t3con.TMR3CS=0; t3con.RD16=1;

 

Also adjust these values according to your clock frequency:

#define RTC_CLOCK 48000000 //CPU clock freq fosc

#define RTC_TICKS_PER_SECOND 1500000 //timer count frequency =(fosc / 4) / 8 (timer prescaler)

[Dra 0]

Hi Tom. I got the code to compile. I made the changes in the config file. Troubleshooting through the code. I'm having issues with the SRAM.

My setup. can you provide the change needed to run my hardware. Thanks in advance.

18f6722

10mhz set to 4x-PLL

the ENJ28J60 is connected to the Hardware spi1

ENJ28J60 chip select connected to RD1

23K256 SRAM chip select connected to RD4

Edited September 28, 2012 by Dra

[JorgeF 0]

Hi

 

I supose that by "cable select" you mean "CS" as in "chip select", right?

 

 

Best regards

Jorge

Edited September 28, 2012 by JorgeF

[Dra 0]

correct

Edited September 28, 2012 by Dra

[tom 2007 0]

In config.h go to:

// - - - - - - - - - - - - - - - - - - - -

// serial ram configurations

// - - - - - - - - - - - - - - - - - - - -

#define sram_no_hold_pin //hold pin of 23K256 is attached to +3.3V

#define sram_tris_cs trisd.4

#define sram_tris_hold //(not used)

#define sram_cs portd.1=1;portd.4 //chip select (portd1.=1 makes sure the enc28j60 cs is high because only 1 device at the SPI bus can be selected at the same time)

#define sram_hold //hold active low (not used)

 

in stackconf.h go to:

//Configure ENC28J60

//Use ENC28J60 module

#define ETH_ENC28J60

#define enc_tris_cs trisd.1 //chip select

#define enc_tris_rs trisa.2 //reset device

#define enc_rs porta.2 //reset the device, attach porta.2 to the ENC28J60 reset pin

#define enc_cs portd.4=1;portd.1 //chip select (sets the sram cs=portd.4 to 1 and the enc28j60 cs at portd.1 to 1 or 0 depending on where it's used in the code)

 

 

If it doesn't work make sure the spi functions in spi.c are working (use an oscilloscope to see if any data is coming out of the SDO and SCK pins)

[Dra 0]

Thanks Tom.

I device got pass the

 

spi_init();

sram_init();

The device now lock up on the following:

serial_send_string("SPI & SRAM INIT OK, Performing memory test\r\n");

it prints out: -

SPI & SRAM INIT OK, Performing memory

The word "test" does not print. It does this consistently.

 

I made changes to the serial_int() to work with my system does this look right?

 

 

void serial_init(){

//pie1.RCIE=1; //enable interrupts

trisc.6=1; //enable the outputs/inputs

trisc.7=1;

txsta.BRGH=1;

baudcon.BRG16=1;

//spbrgh1=1249/256; //16bit brg @ 9600 baud

spbrgh1=1040/256;

//spbrg1=1249%256;

spbrg1= 1040%256;

txsta.SYNC=0;

rcsta.SPEN=1;

txsta.TXEN=1; //transmit enable

rcsta.CREN=1; //receive enable

//ipr1.RCIP=1; //high interrupt priority

}

[tom 2007 0]

I think the configuration is correct. Does the PIC continue doing other stuff after writing "SPI & SRAM INIT OK, Performing memory" or is it stuck?

 

1040 gives a baud rate of 9606,14 this is close to 9600 but not exact. Maybe the string is too long and things go out of sync (not sure)? Try writing a long string in the beginning of your program and see if that works. Do you get other characters where the "test" is supposed to be printed or just nothing?

[Dra 0]

Thank Tom.

As you suggested I tried placing a long string at the beginning of my code, and the same thing happened, the print out just stopped in middle of the text at about the same number of characters as before. And at that point the program stops. I place an LED to turn off after the print function and nothing happens.

[tom 2007 0]

What happens when you use the serial_send_data(unsigned char * data, unsigned char len) function:

serial_send_data("SPI & SRAM INIT OK, Performing memory test\r\n",44

) //where 44 is the number of characters in the string. Check if this will block the pic (if it does it must be a problem with the while (txsta.TRMT==0); or the "for loop" inside the serial_send_data() function).

Edited September 29, 2012 by tom 2007

[Dra 0]

Yes it does the same.

[Dra 0]

Hi Tom what are the functions for receiving values over serial port? Do use a getc, gets and what are the arguments.? Do you use streams, and how do you identify/setup the streams?

[JorgeF 0]

Hi

 

..........

1040 gives a baud rate of 9606,14 this is close to 9600 but not exact. Maybe the string is too long and things go out of sync (not sure)?

.........

This is not an issue to the TX side because it is the one generating the bit stream.

As for the RX side, receiving USARTs are suposed to reset their baud rate counters at each START bit (each character) so it should cope easily with such a small deviation.

 

Best regards

Jorge

Edited September 29, 2012 by JorgeF

[Dra 0]

In flow-code from time to time I would get an issue with the UART not working. I it was brought to my attention that clearing the buffer by doing 3 reads of the UART would clear the issue. And It did. I wonder if that could be an issue here. sp.h has functions to send data. Got any functions to receive data. I have used getc and gets do they work in SourceBoost?

[tom 2007 0]

You can try to disable receive mode if you think it's causing problems (it's not used in sp.h / sp.c): rcsta.CREN=0; //receive disable

 

If you want to read a received character use:

 
unsigned char data;
data = rcreg1;

To check if data is waiting in the rcreg you can use pir1.RC1IF.

[Dra 0]

Thanks.

I tried the above and explicitly setting the registers to serial 1 i.e txreg ->txreg1, txsta ->txsta1 etc...

I tried using a shorter string and still the same. Looking at the serial_init() and serial_send_data() is there anything that comes to mind, anything I can try that I have missed?

 

 

void serial_init(){

//pie1.RCIE=1; //enable interrupts

trisc.6=1; //enable the outputs/inputs

trisc.7=1;

txsta1.BRGH=1;

baudcon1.BRG16=1;

//spbrgh1=1249/256; //16bit brg @ 9600 baud

spbrgh1=1040/256;

//spbrg1=1249%256;

spbrg1= 1040%256;

txsta1.SYNC=0;

rcsta1.SPEN=1;

txsta1.TXEN=1; //transmit enable

rcsta1.CREN=1; //receive enable

ipr1.RCIP=1; //high interrupt priority

}

 

 

//sends an array of chars to the serial port

void serial_send_data(unsigned char * data, unsigned char len){

for (int i=0;i<len;i++){

while (txsta1.TRMT==0);

txreg1 = data;

}

}

[Dra 0]

I let this out. During one of the test I shortened the string but forgot to change the length argument it was still set to 44. Notice that after \r\n the serial continued to print. I would have expected such but what it printed I didn't. Have a look. Once the data is sent my thinking is that the buffer[location] should be cleared(that location in the buffer should have no value/is empty).

Below is what printed from this call, "serial_send_data("SPI & SRAM INIT OK, memory test\r\n",44); "

 

 

SPI & SRAM INIT OK, memory test

ory

 

why the "ory" after \r\n?

[tom 2007 0]

I think it could be a problem with your code in your interrupt routine. Can you check whats inside void interrupt(){}? Maybe the pic is stuck in this (try adding code that makes a led blink when it enters the interrupt). The rtc.c will enable the interrupt from some timer that is used for remembering the time.

 

Did you try putting rcsta1.CREN=0 ? To disable the receiver.

 

Another option is to start a new project with ONLY the sp.h/sp.c and try messing with that.

 

If the len parameter is bigger than the size of the buffer it will continue to read from the buffer. It will end up somewhere in the ram memory where stuff from other variables is stored that's why it says ory.

Edited September 30, 2012 by tom 2007

[Dra 0]

Hi Tom.

Just discovered the void interrupt(){} is not the code. From the beginning, getting the code to compile in the flow-code environment was a challenge. At some point the interrupt routine must have gotten chopped. It might have been over the issue that when I try to compile with the routine, flowcode returns and error, "void interrupt(){} already has a body". It seem the FC IDE automatically generates an empty interrupt(){}. I have to take this up with the guy a matrixmultimedia. Keep you posted. Thanks for your help.

[Dra 0]

Hi Tom. Looking through the code I don't see where the interrupt() function is being called. How does this work?

[JorgeF 0]

Hi

 

!?!?!?!?

 

An "interrupt" function is never called in code.

It is called by hardware, meaning it will be executed when the "mcu" gets an interrupt signal due to an event on a peripheral (ADC finished convertion, USART received char, ...) or from an external device via an interrupt pin (INT0, INT1, ...).

 

 

Best regards

Jorge

Edited September 30, 2012 by JorgeF

[tom 2007 0]

When the timer overflows (0xFFFF + 1 -> 0x0000) the pic will automatically stop and go to the interrupt() function. Then it will execute the code in it (increment time elapsed etc...). After that it will return to what it was doing before the timer overflow or other interrupt (ADC, INT0,...).

[Dra 0]

So this interrupt() fires for all interrupts, and it is the code in the function which checks which interrupt was fired?

 

Could you give some details on the below function. In this case, when does it take place and what does nop() do. Looking through the source boost data sheet I'm still not clear on this: Thanks in advance.

 

void interrupt_low(){

nop();

}

[JorgeF 0]

Hi

 

PIC18 devices interrupts can have or not have priorities.

At power on they default to no priorities, also known as PIC16 compatible mode, where all interrupts vector to the same address (0x0008).

If priorities are enabled, the PIC supports two priority levels, high (vector 0x0008) and low (vector 0x0018).

In this mode the different interrupt sources can be configured to be of high or low priotity.

PIC18F4420 datasheet - section 9.0

 

BoostC for PIC18 uses the predefined interrupt handling functions "interrupt" for high priority or no priority (vector 0x0008) and "interrupt_low" for low priority (vector 0x0018).

 

Is a common, and good, practice allways define the interrupt handlers, even when we do not use them, so the program doesn't crashes if an interrupt is fired for some unexpected reason (a glitch might happen during interrupt configuration commands sequence if it is less than perfect).

 

The "interrupt_low" function that you posted is a so-called empty ISR (NOP --> No Operation).

My guess when looking at it is that the program runs without interrupt priorities, so the low priority vector is unused.

 

 

Best regards

Jorge

Edited September 30, 2012 by JorgeF

[Dra 0]

Good day Tom and Jorge.

The guys at matrix helped me get the serial going.

Now the program gets stock in the following loop. What should be taking place and how can I go about troubleshooting it?

 

 

while (network_in_configmode()){ //wait until we have an IP from the DHCP server (you should add some code to skip this when it fails)

clear_wdt();

network_handle_tasks();

}

[tom 2007 0]

network_in_configmode() is a function that will check if an IP address was received from the DHCP server. Please connect your ENC28J60 to your router with an ethernet cable. If everything is configured properly your PIC should be able to get an IP address from the router (unless there is still something else wrong).

If you don't know what DHCP,... is it's probably time you start to learn how TCP, UDP, IP, DHCP, HTTP, DNS,... work.

http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol