Demo application hardware setup: UART2 PIC24FJ1024GB610 Explorer 16/32

tinchogleria wrote on Wednesday, July 12, 2017:

Hello!
I’ve been trying to find “[pin 2 and pin 3 of Explorer16 9way D socket] (http://www.freertos.org/portpic24_dspic.html)” because I have to connect those pins for the example to work and I have been completely defeated.
According to the MCU datasheet, UART2 is not mapped directly to specific pins, instead it is configurable to the available RPn / RPIn pins.
So far all fantastic, but I can not find in the source code what this configuration is.
I share the source code where the UART is configured, it is the file that I downloaded from freeRTOS.org.
Could someone shed some light on this?
I really appreciate the help of this forum.
Thanks in advance.

rtel wrote on Wednesday, July 12, 2017:

This connection is on the connector - assuming the Explorer 16 hardware
has not changed (it is an old demo) then you can just link the pins
externally.

If you go to the webpage you link to there is a picture of our hardware
set up at the top of the page. In the picture, on the bottom left
corner you will see the power plug. Next to the power plug you will see
the 9-way connector (the one you plug a serial cable into) mentioned in
your quote. If you look very carefully at that 9 way connector in the
photo, although barely visible, you will notice a little loop of wire
(probably a paperclip of staple) sticking out of the connector - that is
just pushed into the connector’s pin 2 and pin 3 to connect them together.

tinchogleria wrote on Thursday, July 13, 2017:

Thank you very much.
Now I realize the reason why I didn’t find it. The demo board has changed. The port24’s web page (link in my previous message) has a broken link to the microchip site with the details of the demo board used then.
I think the 9-way connector has been replaced by usb-serial connector. This is the demo board I’m using now: Explorer 16/32. (Click on the image at the right for zooming)
Perhaps, should I try to re-map de UART2 pins? What would you do?
Thanks again!

rtel wrote on Thursday, July 13, 2017:

Probably easiest to just remove the comtest from the demo. The comtest
was the part of the demo that was using the looped back uart (the bit of
wire sticking out the 9-way connector).

To remove the comtest from the project you have to do two things.

  1. Remove the line that creates the test tasks. That can be done in
    main.c by commenting out the line that calls vAltStartComTestTasks() or
    vStartComTestTasks().

  2. Remove the line that checks to see if the comtest tasks are still
    running. That can be done by removing/commenting out the if() block
    that calls xAreComTestTasksStillRunning().

tinchogleria wrote on Thursday, July 13, 2017:

I share you the function where the UART2 config happen, original from freeRTOS source code. I tried to follow the bits definition up to pic24fj1024gb610.h file, but honestly I can’t figured it out. I assume this is a valid UART2 configuration, otherwise some error or warning should pop-up. Am I right? Where, in this function, is mapped UART2 pins?

xComPortHandle xSerialPortInitMinimal( unsigned long ulWantedBaud, unsigned portBASE_TYPE uxQueueLength )
{
char cChar;

	/* Create the queues used by the com test task. */
	xRxedChars = xQueueCreate( uxQueueLength, ( unsigned portBASE_TYPE ) sizeof( signed char ) );
	xCharsForTx = xQueueCreate( uxQueueLength, ( unsigned portBASE_TYPE ) sizeof( signed char ) );

	/* Setup the UART. */
	U2MODEbits.BRGH		= serLOW_SPEED;
	U2MODEbits.STSEL	= serONE_STOP_BIT;
	U2MODEbits.PDSEL	= serEIGHT_DATA_BITS_NO_PARITY;
	U2MODEbits.RXINV	= serNORMAL_IDLE_STATE;
	U2MODEbits.ABAUD	= serAUTO_BAUD_OFF;
	U2MODEbits.LPBACK	= serLOOPBACK_OFF;
	U2MODEbits.WAKE		= serWAKE_UP_DISABLE;
	U2MODEbits.UEN		= serNO_HARDWARE_FLOW_CONTROL;
	U2MODEbits.IREN		= serNO_IRDA;
	U2MODEbits.USIDL	= serCONTINUE_IN_IDLE_MODE;
	U2MODEbits.UARTEN	= serUART_ENABLED;

	U2BRG = (unsigned short)(( (float)configCPU_CLOCK_HZ / ( (float)16 * (float)ulWantedBaud ) ) - (float)0.5);

	U2STAbits.URXISEL	= serINTERRUPT_ON_SINGLE_CHAR;
	U2STAbits.UTXEN		= serTX_ENABLE;
	U2STAbits.UTXINV	= serNORMAL_IDLE_STATE;
	U2STAbits.UTXISEL0	= serINTERRUPT_ON_SINGLE_CHAR;
	U2STAbits.UTXISEL1	= serINTERRUPT_ON_SINGLE_CHAR;

	/* It is assumed that this function is called prior to the scheduler being
	started.  Therefore interrupts must not be allowed to occur yet as they
	may attempt to perform a context switch. */
	portDISABLE_INTERRUPTS();

	IFS1bits.U2RXIF = serCLEAR_FLAG;
	IFS1bits.U2TXIF = serCLEAR_FLAG;
	IPC7bits.U2RXIP = configKERNEL_INTERRUPT_PRIORITY;
	IPC7bits.U2TXIP = configKERNEL_INTERRUPT_PRIORITY;
	IEC1bits.U2TXIE = serINTERRUPT_ENABLE;
	IEC1bits.U2RXIE = serINTERRUPT_ENABLE;

	/* Clear the Rx buffer. */
	while( U2STAbits.URXDA == serSET_FLAG )
	{
		cChar = U2RXREG;
	}

	xTxHasEnded = pdTRUE;

	return NULL;
}
/*-----------------------------------------------------------*/

tinchogleria wrote on Thursday, July 13, 2017:

My last message should was posted before your last answer. Sorry for that, I didn’t see your answer.
I did the changes you suggested me. Effectively task #2 is not running now, but task #4 sometimes fail.
I can not establish a period, but is frecuently. When everything is fine, I see “124ns max jitter” in my display. What could be causing this inconvenience?