Uart Interrupt on RXINT0

[alanwms]

PIC24fj64GB002
Flowcode version 9.1.0.27 professional Version
Built March 29 2021

I setup an interrupt on serial-in data, and load string info into a variable called "serial_string"

That serial string gets all data as expected in simulation - but not working on my hardware.
I rearranged my program and now I poll with the same "serial_string" loading from (serial_string = Uart1::ReceiveString(10,15)
Working this outside of the interrupt gets my data.
You will probably request my program but I have rearranged everything now after spending 3 weeks of empirical changes trying to figure out why I can't get serial data using the interrupt.

I'm not sure how you can keep up with the multitudes of PIC chips and suspect that hardware has not been tested in every case. Could someone take a close look at this and let me know if the compiler is setting up the serial interrupt correctly?
I have attached my program which is polling.

[mnfisher]

Hi Alan,

If serial_handler is your interrupt routine - you are possibly trying to do too much in it.. It should probably just stuff the received character into a buffer and then return - leaving the 'main' code to handle the data.

Here - https://www.matrixtsl.com/mmforums/view ... ingerprint - the receive routine (on interrupt) - looks for a specific pattern and is (vaguely) 'similar' to what you are trying to do. Although it does some processing - it is light and all paths through are short..


Martin

[alanwms]

Thanks Martin.

Serial Handler is not the interrupt at this point. I have tried a single component in the interrupt to collect data understanding that we should be in and out of the routine. However, I could stay in that routine for a week if I disabled interrupts and re enabled them at the conclusion. Been there tried that too.
I'm pretty sure that the serial will not run. But I will be attempting to use the interrupt again for a last try.

[mnfisher]

Yes, I appreciate that it's not acting as an interrupt at present.

My thought was that if you were trying to use a Rx interrupt and receive chars in the handler - wait too long and characters might/will be missed.

Interrupts are generally disabled automagically on an interrupt occurring - (this is processor dependent - 'higher level' interrupts 'might' still occur) - but as a general rule, the quicker the interrupt routine the less likely it is to cause heartbreak.

Try to get a 'simple' receive to work on the hardware (just push the received char into a circular buffer (or an array)) ? This will show whether the hardware is 'capable' of what you are after (and hopefully be quick to code!)

See https://www.matrixtsl.com/mmforums/view ... rt+receive

Martin

[alanwms]

I will investigate that. Right now my interrupt consists of a single component which is supposed to get data into variable "serial_String"
It's coming back with nothing. I do know it's going in there when my characters arrive.
If I use the same component in a simple loop without interrupts, it works.

I have not been able to find the extra serial stiff (Circular buffer etc) I don't know where this stuff is..?

[alanwms]

So I put the serial interrupt in, and still no info is going into the serial_string.
I put my scope on the serial input pin to the PIC24fj64GB200 with one channel on the data, and the other on the ACtive low pin for the driver.
Data is getting to the chip, and the interrupt is not working properly.
Thanks for your demo. I would speculate that the interrupt for this particular chip is not running properly.
Can someone verify this for me?

Scope.jpg (154.74 KiB) Viewed 4188 times

Interrupt.jpg (11.24 KiB) Viewed 4188 times

The system works well with the simulator.

[LeighM]

Hi Alan,

I don't currently have any hardware to test this myself.
So if you wouldn't mind just trying something...
First we need to check if the interrupt is working,
for which I would suggest a very simple interrupt function where you call a single ReceiveChar() and toggle an output.
i.e. output low, ReceiveChar(), output high (aka flash a LED)
Check this occurs for each serial character with your oscilloscope.

If that works, then use ReceiveChar() to place that character into a buffer (Circular Buffer component is ideal for this)
You can also do short/simple things here such as test for a CR character, e.g. to indicate command or string received, and set a flag.
In the main loop check for the flag, when it occurs process the buffer contents.
(nb. I've not looked at your protocol to see if this is the actual method, it's just a typical scenario)
There are also ways of doing this by probing the contents of the circular buffer.

nb. Calling string receive in the interrupt is not recommended.

If it turns out that step 1, the interrupt, does not work then please let us know

Hope that helps

[alanwms]

Thanks Leigh.

Actually, I have put an xor for an LED in the interrupt routine. The LED is affected by this. So I believe that the interrupt is working.

SO I think we are down to using a string in the interrupt. I don't know where the circular buffer component is, and I'm not sure if I know how to use it either.

Thanks for the focus.

[LeighM]

Thanks for letting me know.
The Circular Buffer component can be found under Storage
There should be quite a few posts regarding various usage scenarios of this component on the old Forum.
Get back to us if you need any particular help.

[alanwms]

Thanks Leigh.

Here is what I have so far with testing-
I removed serial stuff from the interrupt and replaced it with a simple LED "off" output. In the main, with a small delay I turn that LED "on". It should blink off and back on again.
What actually happens is that the very first time I send a string, it blinks off. After that, it will not blink off - So it only runs the first time. I poked around in the project options and the only think I did was to disable the WDT - No change.

Thanks for the focus.