UART Rx interrupt not being re-generated

Alright, I'm back to my original problem.  The UART interrupt continues for sometime, with me now reading all the FIFO each time, then just quits (after 252 iterations).  I've resolved the GIE issue, so it is not disabled

and the UART registers all say there should be interrupts coming

Once again, any ideas greatly appreciated.

Robert

A couple thoughts:

1. Can you add some verification in your ISR that the IIR.IPEND=1 (i.e. no interrupts pending) before you exit?
2. You have a "character timeout indication" pending.  I think you need to clear that out so that you can get more interrupts.  Are you handling that case in your ISR?  Can you verify per my first suggestion that it is being properly cleared?

Norman Wong said:

Not sure if I see the same as Brad but I agree with his suggestions. I think the IIR indicates a pending receiver line status interrupt. The error is receiver overrun. Apparently from not servicing the Rx interrupt.

Yep, your'e spot on.  INTID=3 (receiver line status).  I was looking at INTID=6, but messed up the fact that bit 0 of IIR is IPEND, not part of INTID.

I put in code to not leave the SWI handler until the IPEND is 1, and now I never leave it!

do
{
<process the various cases>

int_id = ( (uart_regs_t *)UART_1 )->IIR;

int_id &= UART_IIR_IPEND;

} while ( int_id == 0U );

Just curious. You use the structure uart_regs_t to access the UART registers. The IIR (read) and FCR(write) are the same structure member named IIR?

EDIT: Never mind. You just posted.

Here's my latest code.  I stripped down to barebones uart handler, and swi function (plus added in volatile).  I get the interrupt for some period of time ... 100-ish or 200-ish, then none.  I've added in the uart registers after.

For now, just for purposes of trying to get it working, in the Swi, I just read until DR or OE clear, plus the MSR ... since there seems there might be some link into the INTID of 0 I've been seeing, needing to read it.

I removed the IPEND check, since that just turned it into a polled method, versus int-based (plus it never left the loop monitoring IPEND, as mentioned previously).

int32_t

g_cnt_hwi_fxn_uart = 0U;

#pragma CODE_SECTION( "hwi_fxn" )

extern "C" void hwi_fxn_uart( void )

{

g_cnt_hwi_fxn_uart++;

( (volatile evt_reg_1 *)ADDR_EVTCLR1 )->EVTCLR1 = EVT_EF_46;

Swi_post( SWI_comms );

}

uint32_t

   g_cnt_swi_fxn_comms = 0U;

#define CHECK_IF_UART_RBR_DONE                          ( UART_LSR_DR | UART_LSR_OE )

extern "C" void swi_fxn_comms( void )

{

   g_cnt_swi_fxn_comms++;

   uint32_t

       t_0 = 0U;

   uint8_t

       c_buf;

   do

   {

       c_buf = ( (volatile uart_regs_t *)UART_1 )->RBR;

       t_0 = CHECK_IF_UART_RBR_DONE;

       t_0 = ( (volatile uart_regs_t *)UART_1 )->LSR;

       t_0 = ( ( (volatile uart_regs_t *)UART_1 )->LSR & CHECK_IF_UART_RBR_DONE );

   } while ( t_0 != 0U );

   uint16_t

       t_1 = ( (volatile uart_regs_t *)UART_1 )->MSR;

   return;

}

Norman Wong said:

Your last screen capture has IER = 0x0D = 0000 1101, EDSSI = 1, ELSI = 1, TBEI = 0, ERBI = 1. I think EDSSI should be 0. Even though autoflow is not enabled, not sure if any glitch on the flow control pins would cause a flow control interrupt. You should check to see that you are not pinmuxing the flow control pins.

Never had that set, just did in the fog of all this debugging

Norman Wong said:

I would suggest not using the emulator register display as that it itself causes reads of registers. For example using the display window will read the RBR twice in a row. The LSR changes as each RBR. Perhaps try using some more global counters to instrument it and break in and look at the counters when it hangs.

Ok, took out the emulator register display.  There's no real hang, just quits generating an HWI at some random number of iterations.

Norman Wong said:

Any reason why you are using a SWI rather than handling the UART interrupt right away?

Processing will be much more than the bare-bones debug code I'm using now/showed here.  SWI will lift it out of the HWI realm, which is already burdened by other high-intensity HWI processing (McASP-related).

Norman Wong said:

Seems like things went from partially working to not working at all. Maybe time to roll back to partially working.

After the changes above (and before them), I'm still in the 100 to 300 iteration, and no more.  That's about as good/partially working as it's ever been.

Norman Wong said:

You should remove the resolved mark off my post. That might get more eyes on your problem.

Not sure how to do that!

Norman Wong said:

That's all I got.

Norman Wong said:

You should check to see that you are not pinmuxing the flow control pins.

A quick follow up about this.  The flow control I think you're referring to are UART1_RTS and UART1_CTS.  I was multiplexing both of those to the McASP (AHCLKR on the UART1_RTS pin, and AHCLKX on the UART1_CTS pin).  In reality, for my target hardware, only AHCLKX is being used, to drive the MCLK on a codec.  The AHCLKR/UART1_RTS pin is a no-connect on my board.  So I removed it from the pin-mux.  AHCLKX/UART1_CTS needs to be remained mux'd to to McASP.

Does this make sense, and is it cause for concern?

Regards,

Robert

Norman Wong said:

You should be able to go back to my green bordered resolved post and click on some button to the effect of "Unresolve".

Only the original poster gets those button and I am not sure what they look like anymore. There might more buttons hiding under the "More" button. The interface has changed over the years.

Looked for that, but only found "flag as spam/abuse"
 

Norman Wong said:

The BIOSPSP 3 UART driver handles the interrupts directly in the handler. They appear to call a Swi_post() to trigger a tasklet. On the C6748, an SWI sometimes maps to the highest priority NMI. I assume that with BIOSPSP is it not. If you are using BIOSPSP, any reason why you don't use their UART driver?

I'm using SYS-BIOS, but not BIOSPSP, as far as I know.  Just created the interrupt in the bios .cfg like this

var hwi_8_params = new Hwi.Params();
hwi_8_params.instance.name = "hwi_name_uart";
hwi_8_params.arg = 0
Program.global.hwi_uart = Hwi.create( 8, "&hwi_fxn_uart", hwi_8_params );

then wrote my own handler (modeled after many I've been doing on the C67XX family over the years, etc). It shouldn't be that hard.  But I might look into the BIOSPSP for additional driver work.

Robert

This line
((volatile evt_reg_1 *)ADDR_EVTCLR1 )->EVTCLR1 = EVT_EF_46;
works if EVT_EF_46 has the value 46-32 or 14.

EDIT: Make that EVT_EF_46 = 1<<14.

Have not completely caught up with this thread and also trying to connect the dots between this post and the INITID 0 post from Robert.

i see some pinmux discussion here on UART and McASP - I dont know if it is in mix, but did want to highlight the note that is there in the TRM at the beginning of pinmux registers

Pin Multiplexing Control Registers (PINMUX0-PINMUX19)

Extensive use of pin multiplexing is used to accommodate the large number of peripheral functions in the smallest possible package. On the device, pin multiplexing can be controlled on a pin by pin basis. This is done by the pin multiplexing registers (PINMUX0-PINMUX19). Each pin that is multiplexed with several different functions has a corresponding 4-bit field in PINMUXn. Pin multiplexing selects which of several peripheral pin functions control the pins I/O buffer output data and output enable values only. Note that the input from each pin is always routed to all of the peripherals that share the pin; the PINMUX registers have no effect on input from a pin. Hardware does not attempt to ensure that the proper pin multiplexing is selected for the peripherals or that interface mode is being used

Mukul Bhatnagar said:

Have not completely caught up with this thread and also trying to connect the dots between this post and the INITID 0 post from Robert.

We could close out the other INTID 0 post, if this one could be marked as unresolved ... since this one is the catch-all for the problem now.

Mukul Bhatnagar said:

Pin multiplexing selects which of several peripheral pin functions control the pins I/O buffer output data and output enable values only. Note that the input from each pin is always routed to all of the peripherals that share the pin; 

Norman Wong said:

This line
((volatile evt_reg_1 *)ADDR_EVTCLR1 )->EVTCLR1 = EVT_EF_46;
works if EVT_EF_46 has the value 46-32 or 14.

EDIT: Make that EVT_EF_46 = 1<<14.

That's what I've been doing in my application as well ( 1 << 14 ).  Thanks for the psuedo-code.  

Robert

Norman Wong said:

Pin A3
- PRU0_R31[17] - Input
- AHCLKX - Input/Output - In this case used as output to codec clock
- USB_REFCLKIN - Input
- UART1_CTS - Input
- GP0[10] - Input/Output

So that means the signal out on AHCLKX can be seen as input on PRU0_R31[17], USB_REFCLKIN, UART1_CTS, and GP0[10] (assuming this is configured as an input). In this case, in theory, UART1_CTS should be toggling in tune with the AHCLKX clock.

If GP0[10] was configured as an output, that would mean there was two outputs tied together. Very bad.

No, that's not what it means.

If you configure Pin A3 as GP0[10], then that means PRU0_R31[17] (an input) will be able to "see" whatever is on the pin.  And related to this case, it also means the UART1_CTS pin (an input) of the UART will "see" what's on the pin.  So it is important that you configure flow control as disabled, because it would still be impacted by what's on the pin.

I wasn't clearing out the MCR, flow control registers (AFE, RTS), but MCR was always 0 anyways.  I've put in explicit clears of those bits now, as part of start-up configuration.

I got rid of the SWI, and am doing everything in the uart handler, and am getting further.  This code below appears to be running without stop, i.e. the interrupts are being constantly generated.

uint32_t

g_cnt_hwi_fxn_uart = 0U;

#pragma CODE_SECTION( "hwi_fxn" )
extern "C" void hwi_fxn_uart( void )
{
g_cnt_hwi_fxn_uart++;

uint16_t

t_0 = 0U;

uint8_t
c_buf;

do
{
c_buf = ( (volatile uart_regs_t *)UART_1 )->RBR;

t_0 = CHECK_IF_UART_RBR_DONE;

t_0 = ( (volatile uart_regs_t *)UART_1 )->LSR;

t_0 = ( ( (volatile uart_regs_t *)UART_1 )->LSR & CHECK_IF_UART_RBR_DONE );

} while ( t_0 != 0U );

}

Robert

P.S.  Is there a better way to cut and paste code here?, all the tabs and formatting gets lost ... makes for hard reading

Brad Griffis said:

Also, you should be leveraging the IIR register within the interrupt. Can you add some additional code to check that register?

Brad Griffis said:

No, that's not what it means.

If you configure Pin A3 as GP0[10], then that means PRU0_R31[17] (an input) will be able to "see" whatever is on the pin.  And related to this case, it also means the UART1_CTS pin (an input) of the UART will "see" what's on the pin.  So it is important that you configure flow control as disabled, because it would still be impacted by what's on the pin.

Okay. I think I understand. The statement

"the input from each pin is always routed to all of the peripherals that share the pin"

might need to be qualified that the pin is always routed to "input only" peripheral pins. Pins that are bidirectional be under mux control.

EDIT: Fix errors.

Robert56682 said:

P.S.  Is there a better way to cut and paste code here?, all the tabs and formatting gets lost ... makes for hard reading

- Click on the red button "Reply",
- Then "Insert Code, Attach Files and more..."
- On the tool bar there is an icon that with "</>". Hover text says "Syntaxhighlighter"
- Click in the composition text window to establish the insert point.
- Click on the "</>". Pops up another window. In that window, you can paste your code. Close the window.
- The inserted code will appear as normal text in your compose window. It will appear in "code style" when posted. I thought there used to be a "preview" button but I don't see it anymore.

uint16_t t_0 = 0U;
uint8_t  c_buf;
do
{
  c_buf = ( (volatile uart_regs_t *)UART_1 )->RBR;
  t_0 = CHECK_IF_UART_RBR_DONE;
  t_0 = ( (volatile uart_regs_t *)UART_1 )->LSR;
  t_0 = ( ( (volatile uart_regs_t *)UART_1 )->LSR & CHECK_IF_UART_RBR_DONE );
} while ( t_0 != 0U );

Comments:

- The line "t_0 = CHECK_IF_UART_RBR_DONE" doesn't seem to do anything.
- LSR is read twice. The error bits in LSR get cleared on LSR read. You will lose track of errors.
- RBR is read before LSR. The LSR error bits for the first byte are lost.
- RBR is read before LSR. If there is nothing in RBR, UART behavor is undefined.

The last comment could happen. With a SWI, you couild get a HWI wil you are running the SWI. The SWI runs again but the previous SWI has already drained the FIFO. The SWI reads the RBR and nothing is there. Might result is an error condition.

uint32_t
	g_cnt_hwi_fxn_uart = 0U;

#define UART_IIR_INTID_MASK					( UART_IIR_INTID_THRE | UART_IIR_INTID_RDA | UART_IIR_INTID_RLS | UART_IIR_INTID_CTI )

#define MAX_HWI_FXN_UART					8U

#pragma CODE_SECTION( "hwi_fxn" )
extern "C" void hwi_fxn_uart( void )
{
	g_cnt_hwi_fxn_uart++;

    uint8_t
        c_buf;

	uint8_t
		cnt_0 = 0U;
				
	uint16_t
		tmp_0 = ( (volatile uart_regs_t *)UART_1 )->MSR;

    do
    {
		uint16_t
			iir = ( (volatile uart_regs_t *)UART_1 )->IIR;

		if ( iir & UART_IIR_IPEND )
		{
			break;
		}

		uint16_t
			int_id = ( iir & UART_IIR_INTID );

		int_id >>= UART_IIR_INTID_SHIFT;

		switch( int_id )
		{
			case UART_IIR_INTID_MODSTAT:

				tmp_0 = ( (volatile uart_regs_t *)UART_1 )->MSR;

				break;

			case UART_IIR_INTID_THRE:
				
				( (volatile uart_regs_t *)UART_1 )->IER &= ~UART_LSR_THRE;

				break;

			case UART_IIR_INTID_RDA:
			case UART_IIR_INTID_CTI:
			case UART_IIR_INTID_RLS:

        		c_buf = ( (volatile uart_regs_t *)UART_1 )->RBR;

				break;

			default:
				break;
		}

		cnt_0++;

    } while ( cnt_0 != MAX_HWI_FXN_UART );
				
}

I've updated to the above, which is essentially what you had provided the other day.  It appears to be working, with logging of "c_buf" showing the expected modbus probe, and cnt_0 always a value of 1.  I'm cautiously optimistic that I can move forward now, with this as a basis.  I'll probably still examine the SWI angle, but maybe more on a collected buffer of data, not byte-by-byte.

Thanks much Norman/all,

Robert

P.S.  Inserting the code applied the same formatting to any associated response text like this, which then ran off the end of the text box window, etc.  So I ended up breaking the code/text into two different posts.

Norman Wong said:

    if (lsr & UAR_LSR_OE) g_cnt_oe++;

Quick follow-up ... don't you still want to read the character, in the OE case?

Robert

Apologies, you break on the DR == 0, not OE (so character does get read). Ok, will keep that optimization in mind, if ever felt needed.

Robert56682 said:

uint32_t
	g_cnt_hwi_fxn_uart = 0U;

#define UART_IIR_INTID_MASK					( UART_IIR_INTID_THRE | UART_IIR_INTID_RDA | UART_IIR_INTID_RLS | UART_IIR_INTID_CTI )

#define MAX_HWI_FXN_UART					8U

#pragma CODE_SECTION( "hwi_fxn" )
extern "C" void hwi_fxn_uart( void )
{
	g_cnt_hwi_fxn_uart++;

    uint8_t
        c_buf;

	uint8_t
		cnt_0 = 0U;
				
	uint16_t
		tmp_0 = ( (volatile uart_regs_t *)UART_1 )->MSR;

    do
    {
		uint16_t
			iir = ( (volatile uart_regs_t *)UART_1 )->IIR;

		if ( iir & UART_IIR_IPEND )
		{
			break;
		}

		uint16_t
			int_id = ( iir & UART_IIR_INTID );

		int_id >>= UART_IIR_INTID_SHIFT;

		switch( int_id )
		{
			case UART_IIR_INTID_MODSTAT:

				tmp_0 = ( (volatile uart_regs_t *)UART_1 )->MSR;

				break;

			case UART_IIR_INTID_THRE:
				
				( (volatile uart_regs_t *)UART_1 )->IER &= ~UART_LSR_THRE;

				break;

			case UART_IIR_INTID_RDA:
			case UART_IIR_INTID_CTI:
			case UART_IIR_INTID_RLS:

        		c_buf = ( (volatile uart_regs_t *)UART_1 )->RBR;

				break;

			default:
				break;
		}

		cnt_0++;

    } while ( cnt_0 != MAX_HWI_FXN_UART );
				
}

I think you should log an error in the case that you exit due to MAX_HWI_FXN_UART.  One thought that comes to mind is to swap the two pieces of code that I've highlighted (though I think their polarities also need to flip). That way you could call Log_printf or a function of your choosing prior to the "break" statement.

Norman Wong said:

Not quite understanding. For modbus, it is usually a message of back to back bytes. Meaning the delta between bytes would be zero. You could use a system tick counter to time between UART interrupts or messages. An automatic delta time is in the realm of FPGAs with custom IPs.

Yeah, thought so (beyond UART capability).  Reason is trying to take advantage of the FIFO, i.e. interrupt after 4, 8 or 14 bytes, instead of the byte-by-byte interrupt overhead.  In that case, the delta timing between bytes would be needed to distinguish packet boundaries, i.e. if I knew the delta was the poll/modbus rate between packets, I could parse and respond accordingly. 

Robert

There's my latest, which seems to be holding up well so far. It's a combo of things, including Norman's code and your suggestion about swapping the statements, to allow logging when exceeding MAX_HWI_FXN_UART (logging would go where the break statement is).

Robert

Just a follow-up, I've tried to run this overnight, but in the morning, I can see the target has reverted back to the code in flash, not what I'm running under emulation. However, there have been many changes since I last did overnight runs, including this change, and a complete SYS-BIOS and tools update, so it could be any of those things.

I'm re-running with a breakpoint at main, to try and catch and re-start, but I'm guessing whatever took it to flash code will take out the emulation, so I'll never hit that breakpoint.

Robert

Norman Wong said:

Maybe a power bump? Any VCRs blinking 12:00? Ueah...what's a VCR. Maybe a watchdog timer?

Ha, I had one of those things.  

I don't think power bump, but good call on a possible watchdog reset :)  It appears that I may have had one, that inadvertently got called.  I'll fix/disable it, and see.  Hopefully that's it.

Thanks,

Robert