what is your hardware? Could it be that you have no pull-up on MCLR ?

on the first build of some code that works just fine in the 7.3 beta version i get this : 0 361 Bad function absolute address '___RealsysVT[0]' Bad function absolute address '___RealsysVT[0]', any suggestion/idea what may be the origin?

ok, worked out the direct PPS configuration, by using the Uartx_remappable_init and writing directly into the appropriate PPS registers it all works ok , i noticed this is the way to go as the PPS library wastes a horrible amount of ROM ( not far from 1K5 !) Perhaps you should focus on explaining ho...

Filip, thanks for the reply , i had figured out these pin assignments in between ( took me a while as i used them for something else) , do not think this is a convenient solution though, there is a default RX2 on RB7 according to the datasheet, to me it would seem logical to leave that at least in p...

it turns out this function starts calling __Lib_UART_Remappable_K42_83_UART2_MapDefaultPins , as far as i see in the datasheet there is a default RX1 and RX2 pin however the TX1 and TX2 both need remapping, the setting of RB2 as input makes no sense here, what btw would be the Default pins to which ...

I found the UART2_INIT to set the TRISB2_bit , i do not see any reason for this so suppose it to be by accident

if of any use i would like to state that this is a VERY GOOD suggestion, please make sure it will be implemented, thanks in advance!

Not directly related to this beta version, i spotted several issues around TMR2 on the 18F27K42 , i have the habit of using the Timer Calculator and i had the strangest effects until i carefully read the datasheet of this chip and it turns out to be rather different . First thing is that we need to ...

Janni, that helps, indeed after adding any library to the project it links ok, what is however the importance of the priority level in the declaration of the ISR ?I suppose the priority level is determined by the individual IP bit's or is this significant for the linker? I also notice that in the so...

my first test is very simple to reproduce, take for example led blink example and change to 18F47K42, when IVT is enabled it compiles but no longer reports RAM/ROM usage and does not generate DBG file, behaviour in MikroBasic seems similar. I also see a hint that i do not understand : Hint: interrup...

one of the interesting features of the 18FxxK42 is the multi vector interrupt so this was the first i looked into, for some reason the compiler does not report any generated code once the IVT enabled setting is active, assembly listing seems to be correct but no .DBG file is generated , software deb...

the uart can generate interrupts by itself, it does not need any timer for that.
Simply study the datasheet to see how you enable the Uart interrupt.
The recursion or cross-calling error only occurs when you call any function in both main and interrupt.

why do you want the uart reception to be inside a timer-interrupt? As far as i see you do not need the timer interrupt at all but you should enable the Uart interrupt after calling the Uartx_Init() All the configuration you do in this section TXSTA1.BRGH := 0; // low speed baud rate TXSTA1.SYNC := 0...

you better show the complete interrupt as you have it now, i did not understand calling UART1_Data_Ready after reading RCREG1, not sure what will be the returnvalue of this function will be. As such there is no need for it as you already know there is a character received, after all this triggered t...

is there any reason in your application to put the UART interrupt handler inside a timer interrupt? I also would suggest to initialize all interrupts before you enable them by setting the GIE_bit, your code starts by setting this and possibly that is the very last thing your code does, it is also go...