18F25K80 and UART2 -- *** RESOLVED ***

[Sefi]

I have attached a simple program that works fine on UART channel 1 of an 18F25K80. However it doesnt work on UART channel 2.

I have tested this on an 18F46K80 which is a chip of the same family and the program works fine on both UART channels. I therefore assume that the problem is not with the PIC_CAL_UART.c file and that it must be a definition issue with the 18F25K80.

I have looked at the code generated and when using UART channel 2 the number appended to the constants still shows 1. is this the problem?

Code: Select all

#ifndef    MX_UART_REF1
    #define MX_UART_REF1
    #define gLCD_9_MX_UART_UREF            1
    #define MX_UART_CHANNEL_1        2
    #define MX_UART_TX_PIN_1        6
    #define MX_UART_TX_PORT_1        portb
    #define MX_UART_TX_TRIS_1        trisb
    #define MX_UART_RX_PIN_1        7
    #define MX_UART_RX_PORT_1        portb
    #define MX_UART_RX_TRIS_1        trisb
    #define MX_UART_FLOWEN_1        0
    #define MX_UART_CTS_PIN_1        0
    #define MX_UART_CTS_PORT_1        0
    #define MX_UART_RTS_PIN_1        0
    #define MX_UART_RTS_PORT_1        0
    #define MX_UART_BAUD_1            9600
    #define MX_UART_DBITS_1            8
    #define MX_UART_RETURN_1        0
    #define MX_UART_ECHO_1            0
    #define MX_UART_INT_1            0

Can anyone help with this please?

many thanks
Sefi

[Sefi]

Could this be the same problem as the following thread?

http://www.matrixmultimedia.com/mmforum ... rt2#p32535

Anyone from Matrix help please?

Many thanks
Sefi

[Benj]

Hi Sefi,

I don't think this is linked to the same problem as in v5 the code has now moved into the CAL file and as you say the CAL file is working for another device in the same family.

The UART channel is specified by the Channel definition.

#define MX_UART_CHANNEL_1 2

0 = SW
1 = UART1
2 = UART2

The numbers at the end of the define name simply allow for multiple layers of the same definitions allowing for the same code to be included multiple times to control multiple UARTs.

I will investigate this problem for you.

[Sefi]

Hi Ben,

Have you managed to get any further with issue as its holding up progress

Many thanks
Sefi

[Benj]

Hello Sefi,

Are you using the receive interrupt at all in your program.

If you are then there may be a potential fix for you by adding the following line of code in a C icon at the start of your program.

Code: Select all

st_bit(intcon, PEIE);

I would imagine this bug would have also caused issues with UART1 though so its probably not the problem your experiencing.

All the UART2 code seems ok at this end and the code is compiling. I will have another pass through the code for you but not noticed anything so far.

Some newer devices have an alt pin register which I came across recently, annoyingly this moves peripherals to non default pins on start up. I have had a quick look at the datasheet for your device and couldn't see anything like this register but I might have missed it.

[Sefi]

Hi Ben,

The program does not have any interrupts. I have attached it for your perusal. Its just a test program to draw a few coloured boxes on the gLCD for testing purposes only.

I have tried it with UART1 and it works as expected. When changing to UART2 it doesn't.

I have also attached a very simple C program using UART2 in MPLAB and down loaded that to the EB006. all it does is open UART2 on pins RB7 and RB6 and sends out the character 'A' on the TX pin at 19200 baud. I have tested this with a serial LCD and it works well. So I suspect there is something wrong with the definitions of the 18F25K80 device.

Many thanks
Sefi

[Sefi]

Hi Ben,

I have retested everything and contrary to what I had said earlier it doesn't actually work with the 18F46K80. Its exactly the same problem, (ie UART1 functions exactly as expected but UART2 doesnt).

I dont have any other chips that have 2 UARTs to check this. I have also looked through the code and couldnt see anything that is obvious.

Could you please look into this.

many thanks
Sefi

[Benj]

Hello Sefi,

Can I ask which hardware you are using to reprogram the K80 device? If your using an EB006 with a PICkit programmer then the ICD2/USB jumper in the ICD2 position is essentially disconnecting port pins RB6 and RB7 from the PortB D-type, could this be the cause of the issue?

I have a 26K80 device here but am currently having problems getting my PICkit to recognise it. I'll grab my PICkit 3 this afternoon and have a go with that.

[Sefi]

Hi Ben,

Yes that is exactly the set up I have. I am using an EB006 and a PICKit 3 programmer via the ICD2 jumper.

When down loading the program, the first time a return code of 2 is returned by the programmer. What I do to overcome this is to disconnect the PICKit physically from the EB006, press the reset button on the programmer so that the blue light goes out, reconnect to the EB006 and re-download the program. It always works on the second time.

Please try this and let me know if it works for you too.

many thanks
Sefi

[Benj]

Hello Sefi,

Right I have 2 18F26K80 devices here but unfortunately even the PICkit 3 will not recognise the devices

I will have a dig around and see what other devices we have available for testing.

[Benj]

Hello Sefi,

Right I have managed to program a 18F25K22 which has 2 UARTS and I can confirm there does seem to be an issue with UART2.

I will investigate.

[Benj]

Hello Sefi,

Right I thought there was a problem but after much playing around with the hardware I realised I had the USB/ICD2 jumper in the ICD2 position which meant that PortB pins 6 and 7 are not attached to the E-blocks port.

Moving the jumper back to the USB position after programming with the PICkit allowed the display to fire up correctly on UART2

[Sefi]

Hi Ben,

Thank you for the time you spent on this. I confirm that is the case and the issue is now resolved.

I am a little surprised that you disconnect pins RB6 and RB7 via the USB/ICSP jumper in the EB006 design. I think standard Microchip advice is that 2 x 10k resistors are put in to separate the components connected to these pins if ICSP is used. I have used this technique without any issues in the past and hence never really thought that I should check that.

Anyway many thanks for all your time spent in resolving this issue.

very best
Sefi